In October 2024 the UK’s Financial Conduct Authority fined Starling Bank almost £29 million. The bank had grown from about 43,000 customers in 2017 to 3.6 million in 2023, and the regulator’s summary was blunt: “measures to tackle financial crime did not keep pace with its growth.”
Nine months later it fined Monzo just over £21 million. Monzo had gone from around 600,000 customers in 2018 to over 5.8 million in 2022, and the wording was almost the same: its controls “failed to keep pace with its customer and product growth.”
I run a software agency, not a compliance function, and nothing here is legal advice. Both banks have since worked on it: the FCA says Starling has set up programmes to remediate and Monzo has completed its own change programme. But I read those two announcements as engineering stories, because the failure they describe is one founders plan for everywhere except here. Nobody launches a product assuming the database will cope with any load. Plenty launch assuming that a control which passed a partner bank’s review is finished.
Growth changes what a control has to do
With a few thousand customers, a control is partly a person. Someone reads the odd case, notices the strange address, remembers the customer who came up last week. With millions, nobody reads anything by default. The control becomes whatever the software does when no one is looking, plus whatever a review team can get through in a day.
That makes financial crime controls a scaling problem as much as a legal one. A check has a load curve, a review queue has a throughput, and both can be estimated before they are needed. I usually argue for cutting admin panels and dashboards from a first version, until there is data to manage. The screen where a person reviews a flagged customer is where I would stop cutting in a regulated product, because that queue is part of the product from the first day it holds money, even if the first version is plain.
A check nobody tests is only a belief
The detail in the Starling announcement that should worry any technical founder is the timeline. In January 2023 the bank became aware that its automated system had, since 2017, been screening customers against only “a fraction of the full list” of people subject to financial sanctions. The FCA’s announcement does not explain how that went unnoticed, and I will not guess.
What I can say is that quiet failure is the normal kind. On the apps and sites I have built or rescued, the things that break first rarely announce themselves: a third-party API or SDK changes, a feature silently stops, and nobody is watching. Most of the time users find it, because something they wanted stopped working. A screening or monitoring check is worse. When it fails, no customer complains. Sign-up simply gets smoother.
So a control needs the same treatment as a payment flow. Push a known bad case through it on a schedule and raise an alarm if it is not caught. Watch the size and the last update date of every list a check depends on. If a list that had thousands of entries yesterday has far fewer today, or has not changed in months, someone should hear about it that morning rather than at the next audit.
A restriction has to live in one place
Both banks were also placed under a requirement not to open new accounts for high-risk customers. Starling opened over 54,000 accounts for 49,000 such customers between September 2021 and November 2023. Monzo repeatedly failed to comply with its requirement between August 2020 and June 2022. Again, the announcements do not describe the mechanics, so I take only the general question from them.
If a regulator or a partner bank told you tomorrow to stop onboarding one type of customer, how many places in your system would have to change? A growing fintech tends to collect routes to an account: the mobile app, the web flow, a referral programme, a partner API, a support agent with an override. If the rule sits in a policy document and each route carries its own copy of the logic, the rule will hold on some routes and leak on others.
The design that survives this is dull. Every route calls one decision point, the rule lives there, and each decision is logged. Changing the rule is then one change, and proving that it held is one query.
Bad data should meet some resistance
The most memorable line in either announcement is about Monzo, which the FCA says onboarded customers on “limited, and in some cases, obviously implausible information – such as customers using well known London landmarks as an address.”
It is funny until you picture the product meeting where it could have happened. Every field a growth team removes improves the sign-up numbers, and an identity provider confirming a document says nothing about whether the rest of the form makes sense. In a meeting like that, nobody decides to accept a landmark as a home address, and nobody is asked to refuse one either.
Simple rules catch a lot of this: addresses checked against reference data, repeated addresses and devices flagged, well-known places on a blocklist. As volumes grow there will be pressure to hand the whole problem to an AI model. I tell clients not to add an AI feature when a rule or a filter would do, or when wrong answers are expensive, and financial outputs are on that list. Rules also have the advantage of being explainable when someone asks why an account was approved.
The record is a product surface too
Whoever reviews your controls will ask what you checked, against which version of the data, who decided and when. That record is very hard to rebuild later. It is cheap to write at the moment of the decision, and it should be designed the way any other feature is.
The same habit applies to the customer side. On Truevo, a mobile and web app we built for small business owners in Britain and Ireland, an owner can follow each store’s daily purchases, refunds and captures as they sync from terminals and cards. That is a business tool rather than a compliance one, but the principle carries: when money moves, someone must be able to see exactly what happened without asking an engineer. These pieces also belong in the plan from the start, and founders scoping a first release may find use in a breakdown of what drives the budget for a regulated fintech build.
Five questions before the next growth push
Before the next marketing budget goes live, a founder can put these to the team:
- If customers grew tenfold next year, which checks would still run on their own, and who would work the alerts?
- When did we last push a known bad case through each check, and would anyone be told if it were missed?
- If we had to stop onboarding one type of customer tomorrow, how many places would change, and how would we prove the rule held?
- For any account, can we show what we checked, against which data, and who decided?
- Who owns the trade-off between sign-up conversion and data quality, and does that person sit in the room when growth targets are set?
None of these needs a large compliance team to answer, and a weak answer now costs far less than the same answer at ten times the customers. The pressure is also moving from guidance to dates. In the EU, the Anti-Money Laundering Regulation applies directly from 10 July 2027, so firms selling there have a fixed point to plan against. The fintechs that handle this well will be the ones that treated their controls as part of the product while there was still time to build them calmly.
About the author
Artemii Tkachuk is the founder and CEO of IvorySoft, a software development agency that has built mobile, web and AI products for startups and small businesses, fintech among them, since 2018. The company also builds and runs its own products, ThauRed and My Baby is Hero.
