Federated Fraud Data Sharing Without Exposing Customer Data
Sharing Fraud Signals Between Banks While Keeping Customer Data In House
Every fraud team knows the shape of the problem. A mule account receives funds from four institutions in one morning, and each of those institutions sees a single unremarkable payment. The pattern is obvious from above and invisible from inside any one bank, which is why detection built purely on internal data has a ceiling that no additional modelling will lift.
The obstacle to crossing that boundary has never really been technical. It is that sharing customer data between competing institutions raises privacy, liability, and competition questions that are slower to resolve than any engineering task. What has changed is that the technology now allows useful signals to move without the underlying customer data moving with them, which reframes the conversation from whether to share data to what exactly needs to cross the boundary.
Why does fraud intelligence need to cross institutional boundaries?
Because fraud networks operate across institutions while detection operates inside them.
The asymmetry is structural. A fraudster deliberately distributes activity across banks to stay below every individual threshold, and each institution's view is a fragment. The BIS Innovation Hub's Project Aurora, reported in May 2023, tested exactly this proposition and found that privacy-enhancing technologies combined with network analysis across institutions detected potentially up to three times more complex schemes, such as mule and layering activity, while reducing false positives by up to eighty percent compared with the current siloed and rules-based approach. That last figure matters as much as the first: collaboration improves precision, not just recall, because context resolves ambiguity.
What can a single institution never see on its own?
Onward movement, cross-institution clustering, and whether a counterparty is already known elsewhere.
You cannot see where funds went after leaving your customer's account, how many other banks sent value to the same beneficiary this morning, whether the device behind an application has appeared at three other institutions this week, or whether an account you are about to open belongs to a network already confirmed as fraudulent. Each of those is decisive information available somewhere in the system and nowhere in your data warehouse.
Why does precision improve rather than degrade?
Because most false positives come from missing context, and context is exactly what the other institution holds.
An unusual payment to a new payee looks risky in isolation. If the receiving account has a long, ordinary history at another bank, the risk falls sharply. Sharing therefore lets you release genuine payments with more confidence as well as stop fraudulent ones, which is the argument that wins over commercial stakeholders who otherwise see fraud investment as pure friction.
Is your detection ceiling set by the data you do not have rather than the models you run?
Talk to Digiqt about a fraud data sharing feasibility review
What are you actually trying to share?
Markers, patterns, relationship signals, and model improvements, almost never raw customer records.
| What is shared | Example | Privacy sensitivity | Usual mechanism |
|---|---|---|---|
| Confirmed bad markers | Account or instrument confirmed as receiving fraud proceeds | Medium, refers to identifiable accounts | Hashed identifier exchange |
| Typology patterns | A described scam pattern with indicative features | Low | Structured bulletins or feeds |
| Graph relationship signals | Device or contact attribute seen across institutions | High | Privacy-preserving set intersection |
| Aggregate risk scores | A score or band for a counterparty on request | Medium | Query API with strict controls |
| Model improvements | Updated parameters learned from local data | Low if properly constructed | Federated learning |
| Raw customer records | Full transaction and identity data | Very high | Rarely justified, usually avoidable |
Working through that table is the first design task, because most institutions discover that eighty percent of the value they want comes from the first two rows, which are also the easiest to justify legally.
Which architectures are available?
Five practical patterns, from simple hashed exchange to federated learning, with increasing capability and complexity.
| Pattern | What crosses the boundary | Strength | Cost and complexity |
|---|---|---|---|
| Central utility | Data submitted to a shared operator | Rich analysis, single view | High legal and governance load |
| Hashed identifier exchange | Salted hashes of account or contact identifiers | Simple, fast, well understood | Low |
| Private set intersection | Cryptographically protected overlap only | Reveals only shared elements | Medium |
| Secure multiparty computation | Computation results, never inputs | Strong guarantees, flexible queries | High, and performance limited |
| Federated learning | Model updates, never records | Learns patterns across institutions | Medium to high, needs coordination |
| Trusted execution environments | Data processed in an attested enclave | Practical for richer joint analysis | Medium, depends on hardware trust |
When is hashed identifier exchange sufficient?
Whenever the question is simply whether a counterparty is already known to be bad.
That question carries a large share of the practical value and needs nothing exotic: a shared salting scheme, a query interface, rate limits, and audit. It resolves the mule account problem in the case that matters most, where another institution has already confirmed fraud on an account you are about to pay. Start here rather than with the most sophisticated option, because it can be live in months while a multiparty computation programme is still in legal review.
When do you need federated learning?
When the value lies in patterns nobody has labelled yet rather than in confirmed lists.
Federated learning improves a shared model using each participant's local data without that data leaving its institution, which fits fraud well because the useful patterns are distributed and the labels are held privately. It requires coordination on features, model versioning, update validation, and defence against a participant contributing poisoned updates, so the operational overhead is real. Aurora's finding rests on this class of technique, and the practical lesson is that the privacy technology is no longer the hard part.
Where do trusted execution environments fit?
Where you need richer joint analysis than set intersection allows but cannot justify a central data pool.
An attested enclave lets participants compute over combined data with technical guarantees about what the operator can see, which suits graph construction across institutions. The trade is that you are trusting hardware and attestation rather than a legal agreement alone, and your risk function will want to understand that shift. It is a reasonable middle path, and it should be evaluated against a central utility on governance grounds rather than purely on technical ones. The consortium design questions this raises are covered in this guide to multi-party data sharing and consortium models.
What must be settled before any data moves?
Lawful basis, purpose limitation, liability, residency, retention, and correction rights.
This is the phase that determines whether the programme happens, and engineering cannot proceed past design without it. Establish the lawful basis for sharing in every jurisdiction involved, define purpose limitation narrowly enough to be defensible and broadly enough to be useful, agree liability where a shared marker turns out to be wrong, settle where data may be processed, set retention per signal type, and define how a customer wrongly marked gets corrected across every participant. Multi-jurisdiction operation multiplies each of these, as set out in this guide to privacy compliance across jurisdictions, and consent and provenance need to be tracked at the record level for exactly the reasons described in consent, provenance and sensitive data.
Who governs the consortium?
A defined body with membership criteria, contribution obligations, dispute resolution, and exit terms.
Governance failure kills more of these initiatives than technology does. Agree membership criteria and the standard each participant must meet, contribution obligations so the scheme does not become a few contributors subsidising many consumers, a process for challenging and removing incorrect markers with a service level attached, dispute resolution, and exit terms covering what happens to contributed signals when a member leaves. Write the exit terms early, because they are much harder to negotiate once the scheme is valuable.
Have you settled liability for a shared marker that turns out to be wrong?
How do you prevent the system being abused?
Rate limits, purpose binding, reciprocity, per-participant audit, and monitoring of consumption patterns.
A fraud intelligence network is itself an information disclosure surface, and it must be designed defensively. Bind every query to a stated purpose and a real transaction or application, rate limit per participant and per subject, log every query with the requesting institution recorded, and monitor query-to-contribution ratios so a member consuming heavily without reporting anything becomes visible. Watch for enumeration patterns exactly as you would on any lookup service, and give the governance body the ability to throttle or suspend a participant. Treat abuse monitoring as a launch requirement rather than a later addition, because retrofitting it to a live scheme means explaining to members why you did not have it.
How do you keep shared signals useful?
By decaying them, requiring confirmation to refresh, and measuring precision by signal age and type.
Fraud markers age badly. An account confirmed as a mule three weeks ago may have been closed, remediated, or returned to a genuine customer, and treating that marker as permanent generates false positives that erode trust in the whole scheme. Apply time-based decay, require re-confirmation to refresh a marker, and measure precision separately by signal age and signal type so participants can weight what they receive. Then close the loop: when a participant acts on a shared signal and finds it wrong, that outcome must flow back and adjust the marker, which is the discipline that separates a living network from a stale blocklist.
What does a workable reference architecture look like?
Local detection, a contribution gateway, a shared exchange layer, and local consumption, with nothing raw leaving the institution.
Keep detection local and let each institution decide what qualifies as a confirmed signal. Put a contribution gateway between your systems and the exchange that enforces what may leave, applies hashing or protection, strips anything unnecessary, and logs every outbound item for audit. Run the exchange as the agreed mechanism, whether hashed lookup, set intersection, enclave, or federated learning coordinator. Then consume signals locally as features in your own models rather than as automatic decisions, so a shared marker informs your score instead of overriding your judgment. That last point matters for accountability: your decisions remain yours to explain, which connects directly to the graph-based internal detection described in using graph databases to uncover fraud networks and to the linkage work in synthetic identity fraud detection.
How should delivery be phased?
Legal first, then hashed exchange, then relationship signals, then federated learning.
| Phase | Duration | Deliverable |
|---|---|---|
| Legal and governance foundation | 3 to 6 months | Lawful basis, purpose limitation, liability, correction process, member agreement |
| Contribution gateway | 2 to 3 months | Outbound control, protection, logging, audit |
| Hashed marker exchange | 2 to 3 months | Query and contribution APIs, rate limits, abuse monitoring, decay |
| Local consumption as features | 1 to 2 months | Shared signals feeding internal scores, not automatic decisions |
| Relationship signal sharing | 3 to 4 months | Private set intersection or enclave-based attribute overlap |
| Federated learning | 4 to 6 months | Shared model, update validation, poisoning defences, version governance |
The legal phase runs longest and cannot be parallelised away, so start it before the architecture is finalised and let its outcome shape the technical choice rather than the reverse. Institutions that build first and seek approval later usually discover the approval requires a different architecture.
Which metrics prove the sharing is worth it?
Detection lift attributable to shared signals, precision by signal type, contribution balance, and query response time.
Measure lift specifically: cases detected or prevented that internal signals alone would have missed, which requires holding out shared features in evaluation. Report precision per signal type and age so members can calibrate trust. Track contribution balance across members, because a scheme where a few institutions contribute everything will collapse. Watch query response time, since a lookup too slow for a payment path will be bypassed. And record correction turnaround, meaning how long a wrong marker takes to be removed everywhere, as that number is what protects genuine customers and it is the one participants will be asked about publicly.
Fraud is one of the few areas in banking where competitors have entirely aligned interests, and the technology to act on that alignment is now well proven. What remains is unglamorous: agreeing what may cross the boundary, building a gateway that enforces it, and running the scheme so that signals stay fresh and members stay honest.
Frequently Asked Questions
Why does fraud intelligence have to cross institutional boundaries?
Because fraud networks do. Money moves between banks, so any single institution sees fragments of a pattern that is only coherent when the fragments are combined.
Is there evidence that collaborative detection actually works better?
Yes. The BIS Innovation Hub's Project Aurora found privacy-enhancing technologies with network analysis detected potentially up to three times more complex schemes and cut false positives by up to eighty percent versus siloed rules.
What should actually be shared between institutions?
Confirmed account and instrument markers, typology patterns, graph relationship signals, and model improvements. Raw customer records almost never need to move.
When is hashed identifier exchange enough?
When you only need to ask whether a counterparty is already known as fraudulent. It is simple, fast, and adequate for a large share of practical value.
When do you need federated learning instead?
When the value is in patterns rather than in known-bad lists, since federated learning improves a shared model from local data without that data leaving each institution.
How do you stop a participant fishing for information?
Rate limits, query purpose binding, reciprocity requirements, per-participant audit, and monitoring of query-to-report ratios that reveal a member consuming without contributing.
What must be settled before any data moves?
Lawful basis, purpose limitation, participant liability, data residency, retention, and the process for correcting a wrong marker. These are slower than the engineering and gate it.
How do you keep shared signals useful over time?
Decay them. Fraud markers age quickly, so apply time-based weighting, require confirmation to refresh, and measure precision by signal age rather than treating all markers equally.
