TL;DR: Global organisations faced £1.23 billion in KYC/AML penalties in H1 2025. TD Bank's £3 billion fine was not really about money laundering. It was about a verification system that could not answer basic questions when regulators asked. This is a breakdown of what KYB regulations actually demand at the system level, where most implementations break, and the architecture decisions that hold up under scrutiny.

We have spent six years building compliance infrastructure, and the thing I have learned is that regulations do not care about your architecture. They care about outcomes. You can have clean code and still fail an audit if your system cannot retrieve evidence when someone asks for it.

That is exactly what happened to TD Bank.

The incident that defines the requirement

TD Bank's £3 billion penalty came with operational restrictions, leadership changes, and decade-long compliance monitoring. When regulators asked about beneficial ownership structures, the bank's fragmented KYB processes could not provide coherent answers. The data existed somewhere. They just could not assemble it into a story that held together.

That is not an exotic failure. When you dig into the £1.23 billion in global KYC/AML penalties from H1 2025, the pattern is boringly consistent. Organisations either did not collect the right data, did not verify it properly, or could not retrieve it when asked. None of these are hard problems on their own. They become hard when you treat KYB as a series of disconnected checks instead of one coherent system.

So if you are building verification infrastructure, your real design constraint is this: every component you build needs to produce an auditable, coherent record of how you verified a business entity. Everything else flows from that.

The four obligations every framework checks

Whether you are working under EU AMLD5 and AMLD6, the US Corporate Transparency Act, or the UK's Money Laundering Regulations 2017, the substance converges on four things. The naming varies. The obligations do not.

The interesting engineering happens in how these interact, not in any single one.

CIP is a data quality problem, not a collection problem

Most teams build CIP as an upload form. Certificate of incorporation, business registration, proof of address, done. The hard part is not collecting documents. It is validating them.

Here is a data point that should worry anyone building these systems. Kenyan KYB checks reveal that 3% of CR12 documents contain mismatched shareholder or director data versus Business Registration Service records. Three percent sounds like a rounding error until you do the volume maths. Process 10,000 business verifications a year and 300 of them carry documents that do not match the registry. If your validation relies on an analyst spotting a discrepancy in a PDF, you will miss most of them.

This is not a Kenya thing. Every jurisdiction has data quality issues in its business registries. Your system needs to cross-reference uploaded documents against official registry sources programmatically, comparing each field (director names, shareholder percentages, registered address) and flagging mismatches by type: spelling, outdated, conflicting, or missing.

One field that is not optional: document age. Most jurisdictions enforce a 3-month limit for proof of address. If your system happily accepts a utility bill from eight months ago, you have a compliance gap baked into your schema. Track the document age in days and enforce the limit at validation time, not as an afterthought.

The UK is trying to close some of these gaps. Under the Economic Crime and Corporate Transparency Act 2023, from 18 November 2025 Companies House mandates ID verification for new and existing directors and persons with significant control. Existing entities have 12 months to comply. That helps domestically. It does nothing for cross-border verification, where you are pulling from registries with wildly different data quality standards.

The UBO bottleneck is where systems collapse under volume

Here is the number that reframes the whole problem. Manual UBO retrieval takes 24 to 30 days. With AI-powered automation, the same process completes in 2 to 3 minutes.

That is not a typo. 30 days versus 3 minutes.

The delay is not laziness. It is chasing documents across multiple registries, waiting on responses from foreign jurisdictions, and manually tracing ownership chains. When a business has a multi-layered holding structure spanning three countries, an analyst can spend weeks tracing UBOs back to natural persons. That is genuinely hard work, and it does not scale.

The automated path does the same work differently. It pulls registry data via API, cross-references against multiple sources in parallel, flags discrepancies for human review, and auto-approves clean cases. The verification timeline then spreads across a spectrum: automated approvals in minutes, manual reviews in 1 to 3 business days, and complex cases extending longer.

What determines where a case lands is predictable: jurisdiction transparency, ownership complexity, document availability, and whether the entity operates in a high-risk sector. If you can classify those four factors early, you can route most cases automatically and reserve human analysts for the genuinely hard ownership graphs.

The architectural mistake here is storing only the final result. You need the full ownership graph, not just the natural persons at the end of it. AMLD6 adds personal criminal liability for compliance officers who get this wrong. When a compliance head can face prosecution, your system had better be defensible, not just functional. A defensible system shows its working.

Where the branching logic actually lives

The CDD layer is where most implementations get lazy. Collecting documents is mechanical. Assessing risk is a decision tree, and decision trees are where bugs hide.

The loop back from ongoing monitoring into risk reassessment is the part most teams skip. They build CDD as a one-shot onboarding event. AMLD5 says otherwise. The directive mandates periodic UBO reviews and data gap assessments beyond initial onboarding. A UBO who was clean at onboarding can appear on a sanctions list three months later. Your system has to handle that without a human remembering to check.

The compliance teams who understand this build event-driven architectures rather than batch processes. An ownership change triggers a reassessment automatically. It does not wait for a quarterly review cycle. The research backs the tiering: low-risk businesses refresh every 12 to 36 months, medium-risk every 6 to 12 months, and high-risk move to continuous, event-driven monitoring.

One more thing to build configurable from day one: risk thresholds by country and industry. Financial services face stricter requirements than crypto exchanges applying KYB to institutional clients, though the gap is narrowing. The EU's MiCA regulation, effective 2026, extends KYB obligations to virtual asset service providers under the FATF Travel Rule. Hardcode your risk rules and you are signing up for a refactor the moment a regulator moves.

The honest assessment of why this is hard

I will be straight about this. The hard part is not any single verification step. It is coordinating CIP, CDD, sanctions screening, and recordkeeping across multiple vendors and data sources in one coherent workflow. Most teams stitch five provider APIs together with custom glue code that nobody wants to maintain, and the audit trail fragments across all of them.

That fragmentation is exactly what caught TD Bank out. Each check ran fine in isolation. The system could not assemble them into a coherent answer.

A "Head of Compliance at a UK challenger bank" put it to us recently: "We could pass every individual check and still fail the audit, because the evidence lived in five different places and none of them agreed on what a customer was."

One thing to take away today

If you build nothing else this quarter, build retrieval. The organisations that avoid the TD Bank outcome are not the ones with the most expensive tools. They are the ones whose system can answer any question a regulator asks, quickly, accurately, and with a full audit trail. If your first verification of an entity takes 30 days and your second takes just as long because you cannot find the first one, you do not have a screening problem. You have an architecture problem.

Key takeaways

• KYB failures are structural, not exotic. The £1.23 billion in H1 2025 penalties traces back to data not collected, not verified, or not retrievable.
• Validate documents against registries programmatically. A 3% mismatch rate on CR12 documents means 300 bad records per 10,000 verifications.
• Manual UBO retrieval takes 24 to 30 days. Automated retrieval takes 2 to 3 minutes. Route by jurisdiction, complexity, document availability, and sector.
• Build perpetual KYB as event-driven, not batch. AMLD5 mandates ongoing review, and AMLD6 adds personal criminal liability for compliance officers.
• Retrieval is the real test. If you cannot assemble a coherent audit trail on demand, every other check is wasted effort.

FAQ

What are the core KYB compliance requirements?
KYB compliance requires four things: a Customer Identification Programme that verifies incorporation and ownership documents, Customer Due Diligence that scores risk by industry and geography, sanctions and AML screening against OFAC, UN, and EU lists, and recordkeeping that produces a retrievable audit trail. UBOs holding 25% or more ownership or control must be identified and verified.

How long does UBO verification take?
Manual UBO retrieval takes 24 to 30 days because it involves chasing documents across registries and tracing ownership chains by hand. AI-powered automation completes the same process in 2 to 3 minutes for clean cases, with manual reviews taking 1 to 3 business days and complex multi-jurisdiction structures extending longer.

What is the UBO ownership threshold under AMLD5 and AMLD6?
EU AMLD5 and AMLD6 both require identifying individuals with 25% or more ownership or control of a business entity. AMLD6 additionally introduces personal criminal liability for compliance officers, which raises the bar for how defensible your verification logic needs to be.

Why did TD Bank receive a £3 billion fine?
TD Bank's £3 billion penalty stemmed from a fragmented KYB system that could not answer basic questions about beneficial ownership when regulators asked. The failure was structural: the checks may have run, but the evidence could not be assembled into a coherent, retrievable record.

Does KYB need to be ongoing or is onboarding enough?
KYB must be ongoing. AMLD5 mandates periodic UBO reviews and data gap assessments beyond initial onboarding. Low-risk businesses refresh every 12 to 36 months, medium-risk every 6 to 12 months, and high-risk entities require continuous, event-driven monitoring triggered by sanctions updates or ownership changes.

---

We built Zenoo to solve this orchestration problem. Instead of stitching five provider APIs together with glue code nobody wants to maintain, you configure the full verification flow in one place, the compliance logic stays consistent, and the audit trail stays complete. If you are building compliance flows and this resonates, it might save you the same pain. See it at zenoo.com. 30 minutes. Your data. No slides.

Stuart Watkins is CEO of Zenoo, the compliance orchestration platform that connects identity verification, screening, and risk decisioning in a single configurable workflow.