Banks invest heavily in fighting crime. Most of that money goes into detection and monitoring, the systems that watch transactions right across the chain, and most of it is well spent. The trouble is not the spending. It is that too much of the action still happens at the back end, after the money has already moved. Investigations, suspicious activity reports, fund recovery, the slow forensic work of reconstructing what happened after it happened. That work is necessary, but it is where the least value is created, because by the time you are doing it, the money has already gone.
The value is at the front of the crime chain. Think about the order in which financial crime actually unfolds. An account is opened or taken over, a victim is talked into paying, an instruction is sent to a mule account, the funds move on through the network, and only at the very end does anyone sit down to reconstruct what was lost. Blocking a mule account before it is ever active is worth more than freezing funds while they are moving, which is worth more than investigating a loss once the money is overseas and unrecoverable. The earlier you can intervene, the more you save and the less damage ever reaches your customers. That is not a controversial idea. The hard part has always been getting the right signal early enough to act on it.
Good detection is not the problem
I want to be clear about something, because it matters. Many banks already do an excellent job of detecting fraud. Their monitoring is sophisticated, their models are well tuned, and their analysts are sharp. When I talk to these teams, I am not telling them their detection is broken. It usually is not.
The limit they run into is not the quality of their systems. It is the reach of their data. A bank's monitoring can only see what a bank can see, which is its own customers and its own transactions. A mule account that looks perfectly ordinary inside your walls looks that way because the evidence that would expose it sits at three other institutions. The takeover pattern you cannot quite confirm has already been seen by a peer down the road. The risky recipient your customer is about to pay is known to be risky, just not by you.
So even the best in-house stack hits a ceiling, and the ceiling is set by the data it is allowed to look at. You can keep refining the model, but you cannot refine your way to information you do not hold.
We do not replace your stack, we supercharge it
This is exactly where we add value, and it is worth being precise about how. We are not asking a bank to rip out the detection it has invested years in building. We feed that detection the signals it cannot generate on its own.
Confirmed mule indicators drawn from how an identity behaved at onboarding across the network. Shared behavioural and cyber risk signals that flag a takeover earlier than any single institution would catch it. Recipient-risk signals that tell you the account your customer is about to pay has already caused harm elsewhere. These come from the wider network of banks, and crucially they arrive without any institution's raw data ever being exposed, because the computation happens over encrypted data that no party, including us, can read.
The effect is simple to describe. Same models, sharper inputs. Your existing system keeps doing what it does well, but now it can see further than your own perimeter, so it can hone-in on the cases that matter and let the rest go.
Take a simple case. A new customer clears your onboarding without a hitch, because nothing in your own records says otherwise. What your systems cannot see is that the same identity was flagged and offboarded as a mule at two other banks only weeks earlier. Add that single indicator to your stack and the account never goes active, and the dozens of fraudulent transfers it would have funneled simply never happen. Nothing about your model changed. It just stopped being blind to something the rest of the network already knew.
What that does to the numbers
Start with detection. When institutions pool their signals through privacy-preserving computation, the improvement is not marginal. In trials run by Swift across thirteen banks and ten million transactions, a model working from the shared picture was twice as effective at catching known fraud as one limited to a single bank's data. More fraud caught earlier means less fraud damage landing on the bank, and it means the loss you prevent at the front never becomes an investigation, a report and a clawback attempt at the back.
Then there is the noise. As much as ninety to ninety-five percent of the alerts thrown off by traditional transaction monitoring turn out to be false positives, each one costing an analyst the better part of an hour to clear, and each wrongly flagged customer a legitimate person whose payment you have just delayed or whose account you have frozen. That is where most of a team's time, and a fair amount of customer goodwill, disappears. A signal from the wider network changes the maths, because it can confirm a genuinely suspicious case or clear one that only looked suspicious from inside your own data. Your analysts spend their hours on real risk instead of chasing alerts that were never going anywhere.
Higher detection, lower losses, and far less time burned on false alarms. Those are not soft benefits. They show up directly in what fraud costs the bank to run.
Where to play
The back of the chain will always need attention, and it always get it, partly because confirmed-case data is the easiest data to work with. But it is reactive by its nature. You are documenting and recovering, not preventing. The leverage is in moving signal forward, into the stages where an intervention stops the loss rather than recording it.
That is the place we have chosen to play, and it is where the economics actually shift. You have already built detection that works. We make it see what it has been blind to, push the moment of intervention earlier in the chain, and turn a network of banks that each saw a fragment into one that sees the whole pattern in time to act. That is what supercharging your detection really means, and it is where the value has been waiting the whole time.