If you’re building anything in financial services, KYC and AML aren’t features you add later. They’re constraints that shape your whole architecture. Here’s how I think about them building Y-tech Bank.
KYC (Know Your Customer) is verifying that users are who they claim to be. In EU/UK banking that means identity document verification, a biometric liveness check, address verification, sanctions screening against EU/UK/UN lists, and PEP (politically exposed persons) screening.
AML (Anti-Money Laundering) is the ongoing monitoring for suspicious activity: transaction monitoring rules, customer risk scoring that updates continuously, suspicious activity reports filed with financial intelligence units, and enhanced due diligence for higher-risk customers.
The regulatory ground is moving under you, which matters for how you build.
Most AML explainers still reference the old directive-based framework. That’s out of date. The EU adopted a new AML package in 2024: the AMLR (Regulation 2024/1624), AMLD6 (Directive 2024/1640), and AMLA — a new central supervisor in Frankfurt, operational since July 2025.
The structural change is the same one happening across EU financial regulation right now: the substantive rules moved from a directive (transposed 27 different ways) into a regulation that applies directly and identically in every member state. Full application is 10 July 2027, with AMLA publishing 23 technical standards through 2026.
Why this is an architecture problem, not a legal one: if you’re building now, you’re building for a rulebook that becomes uniform across the EU in 2027. Designing around today’s national variations is designing for a world that’s ending. And one specific note for anyone doing what I’m doing: AMLA’s supervisory expectations are expected to include scrutiny of automated compliance systems. If your transaction monitoring is AI-driven, it has to be auditable and explainable. Not eventually. By design.
The architecture decision that matters most: the temptation in an MVP is to stub out KYC/AML with a simple integration and “do it properly later.” That creates serious technical debt, because these requirements touch your data model at a fundamental level. Customer risk scores need to be accessible across the whole app. Transaction monitoring needs to run in real time, not in nightly batches. Your audit trail — every compliance decision, every report, every screening result — has to be immutable and queryable. Skip this at the start and you’re refactoring everything later, with compliance gaps that are hard to close.
How I’m building it: onboarding runs identity verification through a specialist provider, then an initial risk score, which writes to a persistent customer risk profile with versioned, immutable history. A continuous monitoring layer handles transaction rules, behavioural anomaly detection, and daily sanctions/PEP re-screening. Flagged activity goes to automated holds or a human review queue, and everything writes to an append-only audit log.
Key decisions:
Immutable audit trail from day one — regulators will ask for it, and retrofitting one is worse than building it.
Risk score as a first-class data entity with its own version history, not a derived calculation you recompute on demand.
Third-party verification, own decisioning — a specialist handles document and liveness checks, but the risk logic stays in-house. That logic is the thing you’ll be asked to explain.
Real-time transaction monitoring rather than batch. Re-screening can be batched. Monitoring can’t — and with SEPA Instant mandatory, the whole compliance decision now has to clear inside a 10-second window. Batch architecture is simply not compatible with instant settlement.
Evaluating KYC providers for EU/UK — Sumsub, Onfido, Jumio, IDnow are the main ones — look at country and document coverage (27+ for EU), false-positive rate (too many false declines means lost customers), API and webhook quality, pricing model against your expected volume, and their own certifications (ISO 27001, SOC 2, experience with FCA/BaFin clients).
Honest time estimate: a compliance-ready KYC/AML system — not a stub, something you’d show a regulator — takes longer than most founders plan. Budget 3–4 months for a solid initial build, plus ongoing maintenance as rules change and your monitoring evolves with real data.
And the honest caveat: I’m pre-licence. This is the architecture, and the reasoning behind it, from someone designing it now rather than someone who’s already been examined on it. If you’ve been through the other side of that, I’d genuinely like to hear where this thinking breaks.
It’s not glamorous. It’s what separates products that can become licensed banks from interesting prototypes.
—
Y-tech Bank — pre-seed, EU & UK. ytechbank.com
Top comments (0)