Every conversation I have with a bank about fighting fincrime together arrives, sooner or later, at GDPR. It is the right place to arrive. What I have learned is that most people are asking the wrong question about it. They ask whether they are allowed to share data with another institution. The law has largely answered that. Article 75 of the Anti-Money Laundering Regulation and the incoming Payment Services Regulation now make collaboration not just permitted but, in payments, required. The real question is the one underneath: how do you work on each other's personal data while balancing compliance across GDPR and regulatory obligations? Once you sit with that question honestly, your options narrow to one.

The useful data is the sensitive data

To intervene anywhere worth intervening, you need personal data. Spotting a mule account at onboarding takes names, identifiers and confirmed mule indicators held at other banks. Catching an account takeover takes behavioral and device signals. Stopping a payment to a high-risk recipient takes recipient-risk information that lives inside someone else's institution. None of this is anonymous, and none of it can be made anonymous without breaking it. Strip the identifying detail away and you lose the precision that made the data worth sharing. Aggregate it and the signal disappears into an average. You cannot sanitise your way out of the privacy problem, because the data that protects customers is the same data that identifies them.

That is the trap most approaches never escape. They treat privacy as something you apply to the data before sharing it, when the data only works if it stays intact.

Two ways to call something compliant

There are really two paths to a system a regulator will accept, and only one of them survives the whole length of the fraud chain.

The first path is to share the data directly and justify it. You rely on a legal basis, the "strictly necessary" test in Article 75, proportionality, legitimate interest, and you wrap it in governance: credentialled access, audit trails, four-eye approval, contracts between members. This is lawful. It is genuinely useful, especially late in the chain, when a suspicion has already formed, and two institutions need to compare notes on a named suspect or recover funds that have started to move. I have no quarrel with it as far as it goes. But notice what it does. The data still leaves your walls. It still lands, readable, in another party's hands. Pseudonymising it first does not change its status, because under GDPR personal data that can still be linked back to a person remains personal data. And every new country can mean reworking the permissions, transfer checks, and governance needed to move or expose that data. It is compliance by permission and paperwork.

The second path is to never expose the data at all. Secure multi-party computation lets several banks compute a shared answer over their combined records while each bank's raw data stays encrypted and invisible to everyone else. Encrypted inputs go in, the insight comes out, and no participant ever sees another's underlying data. Here data-minimisation and privacy by design are not arguments you make to a regulator after the fact. They are properties of the system itself.

Why the end of the chain is not enough

Look at where value is actually created in KYC, Fraud and AML. It is created early. Blocking a mule account before it goes active is worth more than freezing funds after they have started moving, which is worth more than investigating a loss after the money is gone. The retrospective, confirmed-case stage at the very end is exactly where the share-and-justify model is easiest, because you are dealing with established suspects and a clear basis. It is also where the damage is already done.

Moving your defense upstream means computing across live, full personal datasets continuously, for every customer and every payment, not only the ones already under suspicion. You cannot do that by passing data around. No legal basis stretches comfortably over the proactive screening of millions of innocent customers' records at other banks. This is the precise point where multi-party computation stops being one option among several and becomes the only one that holds GDPR intact from account opening all the way through to investigation.

It is also worth being plain about the alternatives in the privacy toolbox. Federated learning and homomorphic encryption are real, but they either leave room for data to leak or are too heavy and inflexible for large-scale analysis at the speed a payment needs. For collaborating on personal data at the scale of a banking network, multi-party computation is the technique that is both private and practical.

Strict regulator, lenient regulator, it no longer decides for you

Here is the consequence that matters most for a bank weighing whether to join. Because no personal data ever leaves your control or is revealed to anyone, connecting to a shared network does not require your regulator to bless a disclosure. There is no disclosure to bless. The cross-border transfer question, which is the single hardest part of the share-and-justify model and the thing most institutions name as their top compliance worry, simply does not arise.

So, it stops mattering whether your national regulator is strict, permissive, or has said nothing at all. Every individual bank can evaluate the risks and control what their exposure risks are. You are in control and can choose based on your regulatory requirements.

The wall was never the law

GDPR was never the wall. The wall was the assumption that protecting data and using it together were opposites, so a bank had to pick one. Computing on data you cannot see removes that choice, and it removes it at every step where the money can still be stopped rather than only at the end where it is counted. When the data is personal and the goal is to intervene early, the answer is not a better legal argument. It is a system where the question never has to be asked. That is why, for us, it has to be secure multi-party computation.

Join our Webinar

On July 2, see inside Europe's first live open inter-bank fraud network.

Join Florian Schmitz (DSGV), Nick Goodall (spotixx) and Ian Wachters (Roseman Labs) for a 45-minute deep dive into Europe's first live inter-bank fraud information sharing network- currently running between three major German banks. 

 In this session, you'll learn:

• How three banks tackled data security, GDPR and operational barriers

• Significant fraud damage reduction, what it looks like in practice

• Why #MPC is the only GDPR-safe solution that keeps you in control of your data

• What it takes to join the growing network

📆 Thursday, 2 July | 🕙 13:00 - 13:45 CEST

 👉  Register HERE