Banks that build their own compliance systems tend to get better results than banks that buy one off the shelf, and the two functions built to watch the same customers, fraud and anti-money laundering, still rarely work together. Sven Stumbauer, a partner at Forward Global, explains why both come down to what a bank's hierarchy will accept.
Sven Stumbauer has spent two decades advising banks on financial crime, including a stretch as a US bank regulator. On The Conductors, the AI Against Financial Crime podcast, he described a decision that comes up inside almost every bank and has little to do with which system actually catches more laundering: what a board is willing to defend to a regulator.
In the early years of transaction monitoring, banks that built their own systems generally out-performed banks that bought one off the shelf. A system trained on a bank's own data does not need that data reshaped to fit a vendor's ingestion format. Commercial platforms typically ask for a data staging area first, and many banks, grown through decades of mergers and acquisitions, are still running core systems that date back to the 1980s. Fitting that data into a shape a vendor's platform can use is, in Stumbauer's account, one of the biggest obstacles to a serious AI rollout today.
When an enforcement action names a bank's monitoring system as inadequate, the board's response is rarely to ask which system fits the bank. It asks which system is the industry leader, commits to a rollout that can run two years, and calls the investment done. Whether the system suits the bank's own data and customer base becomes a secondary question.
Stumbauer has had clients running two parallel monitoring systems at once, one cheap and one expensive. The expensive one existed because a head office in another country had already told regulators it would be deployed, so the local team had to use it and work through its output regardless of fit. The choice often favors what is easiest to defend to regulators over what performs best. Stumbauer summed up the outcome in one line:
“So now you have it, now you use it, now you deal with the output.”
The same politics show up between banks. After one of the top three at a bank faces an enforcement action, competitors often call to ask what system it is using, then buy that system themselves, on the theory that using what a regulator has already accepted keeps them safe. Two real variables sit behind the build-or-buy choice, in Stumbauer's view: the size of the bank, since larger banks have more data and more resources to build with, and the rise of modular, API-connected tools, which let a bank buy some pieces and build others rather than committing to one path for the whole system.
The industry has talked about merging fraud and anti-money laundering, sometimes called FRAML, for about 15 years. In practice, Stumbauer says it rarely happens. The two teams look for similar patterns and need a similar skill set. Often, they even run similar systems, and a customer caught in a fraud scheme should, by the anti-money laundering rules themselves, get flagged there too. What keeps the teams apart is the same organizational incentive behind the build-or-buy politics: status inside the bank's hierarchy. Fraud teams and anti-money laundering teams sometimes do not talk to each other at all, and a regulator can end up telling a bank that its fraud side has been filing suspicious activity notifications on a customer its anti-money laundering side considers clean, inside the same institution.
Both patterns trace back to the same thing. The bank's org chart decides more than the bank's risk model does.
Discover customer stories, case studies, and insights.
