Privacy-Enhancing Technologies for Cross-Institution Finance Data
Learning From Data You Are Not Allowed to See
Two banks each hold half the picture of a fraud network. A dozen lenders each see a fragment of a customer's borrowing. Every institution in a market wants to know whether its loss rate is unusual, and none will disclose its numbers. In each case there is a question that can only be answered across institutions, and a set of legal, competitive, and ethical reasons why the data cannot simply be pooled.
Privacy enhancing technologies finance collaborations use exist to answer that class of question. The engineering is genuinely impressive and it is also the easier half of the problem, because most of these initiatives fail on governance rather than on mathematics.
What are institutions actually trying to do together?
Six recurring questions, each with a different shape.
| Collaboration goal | The question being asked | Data that must not be disclosed |
|---|---|---|
| Financial crime network detection | Do these entities connect across our institutions? | Customer identities and transaction detail |
| Shared fraud signals | Has this device, account, or identity been seen elsewhere? | Which institution saw it and in what context |
| Credit and affordability | What is this customer's total exposure? | Individual lender positions |
| Peer benchmarking | Where do we sit against the market? | Each participant's actual figures |
| Model training on wider populations | Can we train on more data than we hold? | The training records themselves |
| Shared verification | Have others already verified this fact? | The underlying evidence |
The shapes matter because they call for different techniques. A yes or no on overlap is a different computation from a model trained across parties, and treating them as one problem is the most common early mistake.
Which technologies are in the toolkit?
Seven, with very different capabilities, costs, and maturity.
| Technique | What it gives | Practical cost | Best fit |
|---|---|---|---|
| Private set intersection | Finds common elements without revealing non-members | Low | Overlap questions, shared identifiers |
| Secure multiparty computation | Joint computation with no party seeing others' inputs | High, network-bound | Aggregates and joint scoring among few parties |
| Homomorphic encryption | Computation directly on encrypted data | Very high for general computation | Narrow, high-value computations |
| Federated learning | Model training where data stays local | Moderate, communication-heavy | Model training across many participants |
| Differential privacy | Bounded disclosure from released outputs | Low to moderate, costs accuracy | Protecting outputs and statistics |
| Trusted execution environments | Computation isolated in hardware | Low overhead, hardware trust required | Pooled processing with a hardware trust anchor |
| Synthetic data | Shareable data that belonged to nobody | Moderate, validation-heavy | Development, testing, some analysis |
Two of these have enough depth to warrant separate treatment. Hardware-based isolation is covered in confidential computing for financial workloads, and generation and validation of artificial datasets in synthetic data for financial services.
Why does the use case determine the technique rather than the reverse?
Because each technique answers a different question, and the interesting technologies attract selection on their own merits.
The failure pattern is recognisable: an institution decides to do something with homomorphic encryption, spends a year building it, and discovers the question it needed to answer was an overlap check that private set intersection solves in a fraction of the effort. Start from the question, establish the minimum disclosure that answers it, and choose the cheapest technique that meets that bound. Where a simpler method suffices, the added complexity buys nothing except difficulty in explaining the system to a regulator.
Have you defined the question before choosing the privacy technology?
What does the evidence show is achievable?
Meaningful uplift on detection problems, demonstrated rather than theorised.
The BIS Innovation Hub's Project Aurora, published 31 May 2023, applied privacy-enhancing technologies and network analysis across institutions and reported up to three times more complex schemes detected and up to eighty per cent fewer false positives compared with siloed rules-based approaches. A second phase open call ran to 18 August 2025. Those two figures are worth holding onto because they point at different benefits: the detection improvement is what gets a programme funded, and the false positive reduction is usually what makes it economically worthwhile, since alert investigation is the dominant operational cost in most financial crime functions.
The fraud-specific version of this, including consortium design and participation incentives, is developed in federated fraud data sharing, and the identity fabrication patterns that most need cross-institution visibility are covered in synthetic identity fraud detection.
What does none of this solve?
Output disclosure, collusion, and the legal question of whether you may do it at all.
| Residual risk | Why the technique does not remove it |
|---|---|
| Information in the output | The answer itself carries information about the inputs |
| Repeated querying | A sequence of permitted queries can isolate an individual |
| Membership inference | A trained model can reveal whether a record was in its training set |
| Collusion between participants | Protocols assume a threshold of honest parties |
| Input poisoning | Nothing verifies that a participant's contributed data is truthful |
| Lawful basis | Cryptography does not create a legal ground for processing |
The last row is the one that stops programmes. A privacy-preserving design strengthens a legal position considerably and does not by itself establish one, and the analysis differs by jurisdiction, which is the terrain of privacy compliance across jurisdictions.
Why does a privacy-preserving computation still disclose something?
Because the point of the computation is to produce an answer, and answers carry information.
If a query returns the average exposure of customers matching a narrow set of criteria, and the analyst can narrow the criteria repeatedly, the average eventually describes one person. No property of the underlying protocol prevents that, because each individual query was legitimate. Protecting against it requires controls on the outputs rather than on the computation: minimum aggregation thresholds, limits on query volume and specificity, noise calibrated to a privacy budget, and logging of every query with the identity behind it. Institutions that treat the cryptography as the whole answer typically have no controls at this layer at all.
The FCA's work on synthetic data validation, published 12 June 2023 and updated 3 June 2026 following a roundtable with the FCA, the ICO, and the Alan Turing Institute, makes a related point that generalises across these techniques: the use case is central, utility can be measured broadly through statistical similarity or narrowly through model performance, and privacy is best approached as a risk-based question that accepts some inherent residual risk rather than claiming its elimination.
How do you handle the governance?
As a formal arrangement with a named body, not as a technical integration.
Participants must agree the lawful basis for each processing activity, the purposes for which results may be used and the purposes for which they may not, who may pose queries and how many, what happens to derived models and insights, how disputes are resolved, who bears liability if the arrangement causes harm, and what happens when a participant leaves or a new one joins. Then someone has to operate that agreement, which means a governing body with real authority rather than a working group. The consortium structures and their pitfalls are examined in multi-party data sharing consortium design.
Why is governance harder than the cryptography?
Because the maths is settled and the incentives are not.
The technical questions have known answers with known trade-offs. The questions that stall collaborations are different: whether a large participant will contribute data that benefits smaller competitors, how to prevent free riding by parties that query more than they contribute, whether commercially sensitive patterns leak through aggregate results, and who is accountable when a shared model produces a bad outcome for a customer. Those are negotiations, they take longer than the build, and starting them after the technology is chosen is why so many pilots never reach production.
Who governs the arrangement once the technology works?
What are the cost realities?
They differ by orders of magnitude, which makes technique selection a budget decision.
Private set intersection over identifiers is inexpensive and can run at real scale. Federated learning is workable but communication-heavy, and its practical constraints are coordination and participant availability rather than computation. Secure multiparty computation is sensitive to the number of parties and to network round trips, which makes it well suited to a handful of participants computing an aggregate and poorly suited to many parties running complex logic. General-purpose homomorphic encryption remains expensive enough that it should be reserved for narrow, high-value computations rather than adopted as a platform. Trusted execution environments impose modest overhead and shift the question to whether all participants accept the hardware vendor as a trust anchor, which is a governance question wearing a technical costume.
The practical sequence that works: answer as much as possible with private set intersection and protected aggregates, add federated approaches when models rather than statistics are needed, and reserve the heavier cryptography for the specific computations where nothing else meets the disclosure bound.
How should a collaboration start?
Two participants, one narrow question, a measured baseline, and a decision point.
Pick the question with the clearest value and the least sensitivity. Involve two willing participants rather than an industry consortium, because bilateral agreements are achievable and multilateral ones take years. Establish what each party can already achieve alone, so the uplift is measurable rather than assumed, and measure the collaborative result against that baseline honestly, including the false positive effect. Then set a decision point at which the arrangement either expands or stops. Pilots without a defined decision point tend to continue indefinitely, consuming attention and producing neither production capability nor a clear negative conclusion.
How should the programme be sequenced?
Question, legal basis, bilateral pilot, output controls, then expansion.
| Phase | Duration | Deliverable |
|---|---|---|
| Use case definition | 1 month | The question, the minimum disclosure that answers it, the value if answered |
| Legal and regulatory assessment | 2 to 3 months | Lawful basis per jurisdiction, purpose limits, engagement with supervisors |
| Technique selection | 1 month | Cheapest technique meeting the disclosure bound, with the rejected options recorded |
| Bilateral pilot | 3 to 4 months | Two participants, measured against a single-institution baseline |
| Output privacy controls | 2 months | Aggregation thresholds, query limits, privacy budget, full query logging |
| Governance formalisation | 3 to 6 months | Agreement, governing body, joining and leaving terms, liability |
| Production hardening | 3 months | Availability, key management, monitoring, lineage of derived results |
| Expansion | Ongoing | Additional participants under the existing agreement |
Legal assessment runs early and in parallel because it can invalidate the whole design, and finding that out after the build is the most expensive possible ordering.
Which metrics matter?
Detection or accuracy uplift against baseline, false positive change, query privacy budget consumption, participant contribution balance, and time from question to answer.
Report uplift against what each participant achieves alone, since that is the only number that justifies the arrangement. Report the false positive effect separately, because that is where the operational saving sits. Track privacy budget consumption and aggregation threshold breaches as the disclosure control measures. Report contribution against consumption per participant, which is the metric that surfaces free riding before it becomes a dispute. And measure the elapsed time from a participant posing a question to receiving an answer, because a collaboration that takes six weeks to answer anything will not be used regardless of how well it protects privacy. Traceability of what was computed and released matters throughout, which is the discipline covered in data lineage and audit trail design.
These techniques genuinely allow institutions to learn things they cannot learn alone. The constraint on adoption has never really been the mathematics, and programmes that spend their first year on the cryptography and their second on the agreements have the order backwards.
Frequently Asked Questions
What are institutions actually trying to do together?
Detect networks that cross institutional boundaries, benchmark against peers, train models on wider populations, and confirm shared facts, all without disclosing customer data to each other.
Why does the use case determine the technology rather than the reverse?
Because each technique answers a different shape of question, and selecting a technology first produces expensive engineering that does not answer the question anyone asked.
What does the evidence show is achievable?
BIS Innovation Hub work applying privacy-enhancing technologies and network analysis across institutions reported up to three times more complex schemes detected and up to eighty per cent fewer false positives than siloed rules-based approaches.
Why does a privacy-preserving computation still disclose something?
Because the output itself carries information, and a sequence of legitimate queries can reveal individual records even when the computation never exposed the underlying data.
Why is governance harder than the cryptography?
Because the technology decides what is computable while participants must still agree lawful basis, purpose limits, liability, query rights, and what happens when someone leaves.
Is output from these techniques automatically anonymous?
No. Privacy protection has to be assessed on the outputs as released, and a risk-based approach accepts that some residual risk remains rather than claiming its absence.
What are the realistic performance costs?
They vary by orders of magnitude across techniques, so start with the cheapest method that answers the question and escalate only where the simpler approach genuinely fails.
How should a collaboration start?
With two participants, one narrow question, a classical baseline to measure against, and a defined decision point on whether the uplift justifies expanding.
