Fintech, dissected: KYC, accounts and ongoing monitoring

So far in this series I’ve covered who you’ll need to launch and the one document they’ll all ask for. Today I want to start opening up the machine itself, because most founders have never seen inside it. This is the first in a set of pieces dissecting the fintech stack one organ at a time, and we’re starting with three things at once.

KYC. Accounts. Ongoing monitoring.

Why three in one article? Because founders treat them as three separate vendor decisions, three boxes to tick, three integrations on the project plan, but they’re not. They’re one connected spine.

KYC decides who gets in. The account holds what they do. Ongoing monitoring watches everything after the yes, and feeds what it finds back to the start.

Buy them as three separate products and you’ll end up with three working components that don’t work together. Your sponsor won’t review the individual products, they’ll review the system you’ve built.

KYC: the decision about who gets in

Strip away the acronym and KYC is one question: are we confident enough about who this person is, and how risky they are, to let their money in?

A real check is a stack of smaller checks. Document verification with liveness and biometrics, proving the person presenting the passport is the person trying to onboard. Data verification which is matching their name, date of birth and address against independent sources. Screening against sanctions lists, PEP lists and adverse media followed by a risk score that rolls all of it up into a decision: approve, reject, or send to a human for manual review.

Here’s what I tell every founder who spends weeks comparing KYC vendors: most of them solve broadly the same problem, and the platform you pick matters far less than how you configure it. Think match thresholds, how fuzzy a name match can be, which combination of verified data points counts as a pass and which risk factors trigger manual review. That configuration is what your sponsor’s compliance team actually scrutinises, because it’s where your sponsor’s risk appetite is translated into decisions.

And remember it’s their appetite you’re building to, not yours. You’re operating under their licence, so their tolerance is your ceiling. The most dangerous state in fintech onboarding is a KYC config that’s technically working, passing customers all day, while quietly sitting outside what your sponsor would sign off if they looked closely. There’s a war story about exactly that coming later in this series. It involves a matching rule that said yes when it should have said no, and the uncomfortable question of who owned the gap.

For now, one takeaway: your KYC config is a policy document written in settings. Someone in your business should be able to explain every threshold in it, and why.

Accounts: what “opening an account” actually creates

To a founder, opening an account looks like an API call that returns an account number. What it actually creates is three things, and only one of them is visible.

First, a ledger entry. The record of what this specific customer holds, updated in real time, that everything else in your stack reads from. When a card authorisation checks a balance, it checks this. When monitoring looks at behaviour, it looks at movements across this.

Second, a bank-side structure. Under a sponsored model this is typically a vIBAN issued in your customer’s name, sitting over a pooled, safeguarded client money account held by your sponsor at the bank. The bank sees one safeguarded balance, your platform needs to see the customer level breakdown. The per-customer breakdown lives on the platform ledger, and reconciliation runs total-to-total between the two. If you read the flow of funds piece last week, this is the same truth from the other side.

Third, an obligation. The moment real money lands against that account, safeguarding duties attach to it. Segregation, daily reconciliation, records that would let an administrator work out whose money is whose. None of that is visible in the API response, and all of it is now your operational reality.

Why does this belong in a compliance article? Because your account structure decides what the rest of the spine can see. Whether flows to a third party leave one-to-one from a customer’s vIBAN or pooled one-to-many from a collection account isn’t just a payments choice. It determines what your transaction monitoring can actually observe. Design the accounts casually and you can blind your own monitoring without noticing.

Ongoing monitoring: everything after the yes

KYC is a moment. Monitoring is forever.

Once a customer is in, someone has to watch what they do, and that watching has two layers.

Rules: if a customer receives more than X in Y days, if funds arrive from a high-risk corridor, if an account that’s been dormant for months suddenly moves everything out, if a customer becomes sanctioned, raise an alert. And increasingly, models that score behaviour against patterns rather than fixed thresholds.

Every alert lands in a queue. A human works that queue: investigating, documenting, closing as a false positive or escalating. This is the part founders consistently forget to budget, and it’s why I keep saying compliance is a team, not a feature. The tooling generates the alerts. It does not investigate them.

And the same ceiling applies here as in KYC. Your monitoring rules aren’t calibrated to your appetite; they’re calibrated to your sponsor’s. The thresholds, the corridors you treat as high-risk, the volume triggers, even down to the frequency of your team’s reviews, all of it flows from what the regulated entity carrying your programme is prepared to tolerate. Set your rules in isolation and you’ll find out during a sponsor review, which is the expensive way to find out.

The joints are the whole point

Now the part that almost nobody writes about: how the three connect. This is where good programmes separate from box-ticking ones.

The KYC risk score should set the monitoring intensity. A customer who came in high-risk should be watched more closely: tighter thresholds, more frequent screening, earlier review dates. If every customer gets identical monitoring regardless of their onboarding risk, your risk score is decoration.

Monitoring findings should flow back into customer risk. Alerts, even closed ones, are information. A customer whose behaviour keeps brushing against your thresholds without valid rationale should see their risk score rise, which should trigger enhanced due diligence, a re-check, or an exit. If your TM system and your KYC system never talk, that loop doesn’t exist.

And the account structure feeds both. The joints only work if the account design gives monitoring visibility of real counterparties and real flows, and if the ledger gives both systems one consistent view of each customer.

That’s the spine. Information runs up and down it. Each vertebra can be individually healthy while the spine as a whole doesn’t hold, and a sponsor’s review is designed precisely to find out whether it holds.

What good looks like

When I see a programme that’s got this right, the tell is boring. I ask why a threshold is set where it’s set, and someone just answers. They know because they wrote it down when they made the decision, and they made the decision by reading their sponsor’s risk appetite, not by accepting whatever the vendor shipped as a default.

The other tell: the customer has one risk score. When the monitoring queue closes a few alerts on the same customer in a month, that score moves. When the score moves, the next review date moves with it. Nobody invented anything new, they just connected the systems they’d already bought.

If you’re mid-build, do the unglamorous version of this now. Write down why each threshold is what it is. Point your alerts at your risk scores. It costs a few days at the start. Doing it later, mid sponsor review, costs a quarter, and you’ll be doing it while someone watches.

And if you’re reading this with a creeping suspicion that your three boxes have never actually spoken to each other, message me.