Eleven million transactions a day, and the product was the floor
The users of this platform were not the bank's customers. They were the model developers hunting money laundering, and what they needed was ground that did not move.
A large Dutch bank
A data-driven transaction monitoring capability screens more than eleven million transactions every day for money laundering and terrorist financing. The product owned here was not a detection model. It was the IT and data science foundation every other model owner and model developer built their detection on.
The challenge
Most descriptions of financial crime detection talk about the models. The models are the visible part. They are also the part that cannot exist without something underneath them that is boring, fast and dependable.
When a detection capability grows from start-up to scale-up, the failure mode is predictable. Each model team builds its own pipeline, its own feature handling, its own path to production. It works, briefly. Then there are six variants of the same thing, six ways to break, and no single answer to a regulator asking how a decision was reached.
The harder product question is who the customer is. Here it was internal: the model owners and developers. A platform product whose users sit inside your own organisation still has to be adopted, and internal users cannot be sold to. They can only be convinced, by the foundation being better than the one they would have built themselves.
What we did
Own the foundation, not the detections
Product ownership of the IT and data science base used by other model owners and model developers to build and run detection for financial and economic crime.
Build for eleven million a day
A processing capability handling more than eleven million transactions daily, where volume is not a peak to survive but the ordinary condition every design decision has to assume.
Carry it from start-up to scale-up
The transition where informal delivery stops working. Shared standards, a defined path to production and clear ownership, introduced while the capability was still growing rather than after it stalled.
Regulated by design
Detection of money laundering and terrorist financing is supervised work. Traceability and defensibility are properties of the platform, not documents produced about it afterwards.
How it works
One base, many model owners
A shared foundation for data engineering and machine learning, so model teams spend their time on detection logic instead of on rebuilding plumbing.
Volume as a design constant
Eleven million transactions a day is the baseline, not the stress test. It sets the architecture rather than being handled by it.
Defensible by construction
In supervised work, how a result was produced matters as much as the result. That has to be built in, not reconstructed later.
Azure, Databricks and Azure ML
Cloud data platform and machine learning tooling as the base layer for model development and production scoring.
Kafka, Airflow and Data Factory
Streaming and orchestration carrying transaction data through the pipeline on a schedule the business depends on.
Terraform and PySpark
Infrastructure defined as code, transformation written in PySpark. The environment is reproducible rather than remembered.
Technologies
The result
The capability screens more than eleven million transactions a day for money laundering and terrorist financing, and the model teams building that detection work on a shared foundation rather than on six private ones.
The measure of a platform product like this is unglamorous: how much of what a model developer does is detection work, and how much is infrastructure they should never have had to touch. Moving that ratio is the whole job.
Only figures already stated publicly appear here. Detection rates, model performance, alert volumes and anything describing the bank's own operations are not published and will not be.
The organisation is described by business area rather than named. The transaction volume is the only figure published, and it is already public in the role description this case is written from. No detection logic, model performance, alert volumes, thresholds, internal architecture or colleague names are published. Nothing here describes how financial crime detection can be evaded.
Related work
Nobody could say which subscriptions were compliant
A global tenant, hundreds of applications moving to Azure, and no single view of whether any of it met the standard.
The platform was built. Teams still could not get onto it
A managed cloud platform, finished and waiting, and workload teams queueing to onboard onto it. The constraint was never the technology.
We read seven months of quotes and found we were building the wrong thing
The roadmap was built on what was easy to read. Not on what the business actually sells.