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

Part 1

This is part 2 of the 3-part series on How Banks Can Collaborate on Fraud Data Without Sharing Raw Transactions, where we discuss 7 specific use cases, namely:

1. Detecting mule-account networks
2. Preventing APP fraud before settlement
3. Cross-border payment fraud
4. Synthetic identity and application fraud
5. Card, merchant, and chargeback fraud
6. Scam intelligence from outside banking
7. Shared model development and validation

Enterprise use case 1: Detecting mule-account networks

Money mules receive and transfer funds on behalf of criminals. A single bank may detect unusual activity in one account but fail to see that the beneficiary, device, telephone number, address, or controlling entity is connected to accounts elsewhere.

Through protected linkage, participating banks could compare selected risk signals without contributing complete transaction ledgers.

A shared workflow might identify that:

• one device has opened accounts at five institutions;
• several beneficiaries are linked through a protected address;
• funds from unrelated victims converge on a group of connected accounts;
• an account closed by one institution reappears through the same identifiers at another;
• a suspected organizer controls several businesses banking with different providers.

This could reduce direct fraud losses and help banks block or investigate accounts before they receive additional victim payments.

It also has regulatory and operational value. Better network identification can produce more focused investigations and more complete reports, while reducing the number of analysts repeatedly examining the same fragmented pattern.

Enterprise use case 2: Preventing APP fraud before settlement

Authorized Push Payment fraud is particularly difficult because the customer instructs the bank to make the payment. Traditional transaction rules may see a properly authenticated instruction rather than an unauthorized transfer.

The receiving institution may nevertheless possess important context: the beneficiary account may be newly opened, connected to previous scam reports, associated with rapid fund dispersion, or linked to identifiers already seen elsewhere.

A privacy-preserving pre-payment check could ask narrowly defined questions:

• Has another participant recently classified this beneficiary as high risk?
• Is the account linked to a protected identifier associated with confirmed fraud?
• Has the same device or entity received payments from multiple unrelated victims?
• Does the beneficiary sit within a known mule-account network?
• Is the destination exhibiting behavior consistent with rapid pass-through activity?

The response need not contain the other bank’s transaction history. It could be a risk score, match status, reason code, or instruction to apply enhanced review.

This has become more financially relevant in the United Kingdom because mandatory APP-fraud reimbursement rules apply to qualifying payments made from October 7, 2024. The reimbursement cost is generally divided equally between the sending and receiving payment firms, creating a direct incentive for both sides to improve prevention.

The Payment Systems Regulator reported that more than £74 million was reimbursed to sending firms by receiving institutions between October 2024 and June 2025.

For a receiving bank, better detection is therefore no longer solely a compliance or reputational benefit. It can directly reduce reimbursement expense.

Enterprise use case 3: Cross-border payment fraud

International payments create further fragmentation. Correspondent banks, originating institutions, intermediary banks, beneficiary institutions, and payment networks may each hold a different part of the transaction chain.

Swift demonstrated the potential of privacy-preserving collaboration in experiments involving 13 international banks and ten million test transactions. According to Swift, the trials doubled real-time fraud detection and used Privacy-Enhancing Technologies to let institutions collaborate while maintaining end-to-end privacy and security. One tested capability allowed banks to verify intelligence about suspicious accounts in real time.

A production implementation could support:

• cross-border beneficiary screening;
• detection of repeated fraud infrastructure across countries;
• identification of linked accounts at multiple institutions;
• comparison of protected scam indicators;
• faster intervention before funds move through additional jurisdictions;
• coordinated responses to international fraud campaigns.

Banks could potentially avoid more fraudulent transfers while reducing dependence on slow, case-by-case requests after the payment has already completed.

Enterprise use case 4: Synthetic identity and application fraud

Synthetic identities combine genuine and fabricated identity attributes. One institution may see a plausible applicant, while other institutions hold applications using the same telephone number, device, address, identity fragment, or employer information under different names.

PPDL can allow banks, lenders, card issuers, and fintech platforms to check for protected overlaps during onboarding.

For example, an institution might learn that:

• a device is associated with several recently created identities;
• one telephone number appears across multiple applications;
• identity elements are reused in inconsistent combinations;
• a company officer is connected to a cluster of suspicious businesses;
• an address has been used in an unusual volume of recent applications.

The institution does not necessarily need to know every applicant held by every other participant. It needs a reliable signal that the current application is part of a broader pattern.

Commercial benefits include lower credit losses, fewer charge-offs, reduced manual verification, and more accurate acceptance decisions. A better cross-market signal may also allow banks to approve legitimate applicants that overly cautious internal rules would otherwise reject.

PPDL can therefore improve both loss prevention and revenue conversion.

Enterprise use case 5: Card, merchant, and chargeback fraud

Merchant acquirers, issuers, payment gateways, card networks, and marketplaces observe different stages of a card transaction.

An issuer sees the cardholder and authorization history. An acquirer sees the merchant relationship. A marketplace may see the seller account and fulfillment data. A gateway sees device and session signals.

Privacy-preserving linkage can help determine whether:

• the same protected merchant appears in multiple institutions’ investigations;
• a device is linked to accounts across several payment providers;
• related sellers generate similar chargeback patterns;
• cards issued by several banks are being tested through the same infrastructure;
• apparently separate merchants share hidden ownership or settlement accounts.

The financial impact extends beyond reimbursed fraud. Better merchant-risk detection can reduce chargebacks, scheme penalties, investigation expense, and losses associated with merchants that disappear before reserves can be recovered.

It may also improve merchant acquisition. Providers with better collaborative risk signals can confidently onboard legitimate smaller merchants rather than rejecting entire risk categories.

Enterprise use case 6: Scam intelligence from outside banking

A large share of payment scams begins outside the financial system.

UK Finance reported that 66 percent of UK APP-fraud cases in 2025 originated online, while 17 percent began through telecommunications channels.

This means banks alone do not hold all the useful prevention data.

Telecom operators may identify SIM swaps, spoofed calls, abnormal messaging, or compromised numbers. Online platforms may recognize fraudulent advertisements, impersonation accounts, and investment-scam campaigns. Cryptocurrency services may observe the next destination of stolen funds.

A multi-sector privacy-preserving environment could permit narrowly defined linkage among protected telephone numbers, account identifiers, devices, advertiser records, and destination wallets.

A bank might receive a signal that the customer is transferring money to an account connected to a recently identified investment-scam campaign—without the telecom company or online platform disclosing its entire user database.

This creates opportunities for cross-sector fraud utilities, paid risk-intelligence services, and consortium-based prevention infrastructure.

Enterprise use case 7: Shared model development and validation

Data linkage can also improve fraud models.

A bank’s model learns only from fraud that the bank has identified. That creates blind spots, especially for new institutions, smaller fintechs, and fraud types that migrate between providers.

Protected collaboration can create richer labels and network features. Participants could jointly train or validate models without exposing raw transactions or proprietary detection logic.

A large bank could benefit from broader network coverage. A smaller provider could gain access to consortium-level signals that it could not generate from its own volume. A fraud-technology vendor could evaluate its model against protected multi-bank data without taking possession of customer records.

Potential commercial models include:

• consortium subscription fees;
• usage-based fraud scoring;
• model-validation services;
• protected industry benchmarks;
• managed investigation analytics;
• revenue sharing for contributed intelligence.

The shared infrastructure itself can therefore become a revenue-generating data product rather than only an internal compliance cost.

In the following and final part of this series we will explore the pragmatic steps financial institutions can take to mitigate the privacy risk of fraud control.

Part 1