How Banks Can Collaborate on Fraud Data Without Sharing Raw Transactions - 3 of 3

Part 1 | Part 2

This is the final part of the 3-part series, presenting practical implementations of privacy-preserving multi-party collaboration technology.

Why an anonymizing Data Clean Room is useful

A conventional fraud consortium may still require a central operator to receive readable identifiers and transaction records.

An anonymizing Data Clean Room changes the trust model.

Selected identifiers can be transformed at each data owner before data enters the collaboration environment. Protected records can then be linked and analyzed under controlled rules. Depending on the cryptographic architecture, SQL analytics, network analysis, and machine-learning workflows can be performed without giving the platform operator or participating banks unrestricted access to plaintext inputs.

This approach can provide several advantages:

• Data minimization: Participants contribute only the identifiers, attributes, time windows, or risk indicators needed for the approved use case.
• Neutrality: No participating bank needs to become the central custodian of competitors’ raw data.
• Purpose limitation: Projects can be restricted to specific fraud questions, calculations, and outputs.
• Commercial confidentiality: A bank does not need to disclose its complete customer base, transaction volumes, internal alerts, or proprietary model logic.
• Scalability: New participants can join a common infrastructure instead of establishing a separate bilateral exchange with every existing member.
• Governance: Access, approved queries, retention periods, output thresholds, and audit requirements can be defined at project level.

The technology does not automatically make a project lawful, eliminate all reidentification risk, or replace governance and security controls. It supplies a technical mechanism through which banks can enforce a more limited and defensible form of collaboration.

Turning privacy-preserving collaboration into a business case

The strongest business case begins with a measurable fraud problem, not with the cryptography.

A bank or consortium should establish a baseline covering:

• gross fraud losses;
• reimbursement payments;
• prevented fraud;
• false-positive rates;
• manual investigation hours;
• average time to identify a linked account;
• funds recovered after fraud;
• customer abandonment caused by unnecessary controls;
• account-opening losses;
• chargebacks and scheme costs;
• regulatory reporting effort.

The collaboration should then target a narrow question, such as whether protected cross-bank beneficiary intelligence can reduce APP-fraud payments to known mule networks.

The economic value can be modeled as:

Prevented losses + avoided reimbursements + recovered funds + operational savings + additional legitimate revenue − collaboration costs.

Suppose a group of banks collectively incurs €200 million in annual losses across a defined fraud category. If protected cross-institutional analysis reduces those losses by only 5 percent, the direct benefit is €10 million before considering lower investigation costs, improved recovery, or fewer customer complaints.

The relevant hurdle is not whether the platform catches every fraud. It is whether the incremental fraud detected across institutional boundaries exceeds the cost of participation.

Recommendation: Start with a focused consortium pilot

A commercially credible pilot should involve a small number of institutions, one fraud pattern, and a limited set of protected data fields.

For example:

• three banks contribute protected beneficiary identifiers from confirmed APP-fraud cases;
• the platform links repeated identifiers and associated accounts;
• participating banks screen new high-risk transfers against the protected network;
• outputs are limited to match indicators and defined risk reasons;
• performance is compared with the banks’ existing controls.

The pilot measures incremental fraud detected, false positives, review time, payments stopped, funds recovered, and reimbursement expense avoided.

It also tests the non-technical requirements: legal basis, governance, data quality, identifier normalization, dispute handling, permitted uses, contribution incentives, and procedures for correcting inaccurate intelligence.

Banks do not need more raw data. They need a safer network view.

Financial institutions already possess sophisticated fraud defenses. Their limitation is that criminals operate across the boundaries those defenses are built around.

PPDL (Privacy-Preserving Data Linkage) and Multi-Party Privacy-Preserving Data Analysis offer a way to close that visibility gap without creating a central repository of every participant’s raw transactions.

They allow banks to identify shared entities, detect coordinated behavior, verify risk intelligence, and build network-level fraud indicators while restricting what each party can see.

The strategic question is no longer:

“Which bank owns the transaction data?”

It is:

“Can the institutions calculate the fraud signal together without disclosing the underlying transactions?”

For banks, payment firms, fraud-technology vendors, and consortium operators, the answer can translate directly into lower losses, reduced reimbursement costs, fewer false positives, more efficient investigations, better customer protection, and new revenue-generating risk services.

Fraud already collaborates across institutions.

The financial sector’s defenses must be able to do the same, without sacrificing the privacy and commercial confidentiality that the system is expected to protect.

Part 1 | Part 2