TL;DR: Global organisations faced £1.23 billion in KYC/AML penalties in H1 2025. TD Bank's £3 billion fine exposed what happens when KYB systems cannot answer basic questions about beneficial ownership. This article breaks down what regulators actually require, where most implementations fall short, and how to structure verification workflows that hold up under scrutiny.
TD Bank's £3 billion penalty was not just about money laundering. It was about a compliance system that could not answer basic questions about customer relationships. When regulators asked about beneficial ownership structures, the bank's fragmented KYB processes could not provide coherent answers.
That is not a one-off. £1.23 billion in global KYC/AML penalties landed in H1 2025 alone. And when you dig into the enforcement actions, the pattern is consistent: the failures are not exotic. They are structural. Organisations either did not collect the right data, did not verify it properly, or could not retrieve it when asked.
If you are building KYB verification systems, this matters. Regulations do not care about your architecture. They care about outcomes. So let us walk through what they actually demand.
The four pillars regulators actually check
Every KYB framework, whether it is EU AMLD5/6, the US Corporate Transparency Act, or the UK's Money Laundering Regulations 2017, boils down to four core obligations. The naming varies. The substance does not.
1. Customer Identification Programme (CIP)
You need to collect and verify foundational business documents: certificate of incorporation, business registration, ownership structure documents, and UBO details for anyone with 25% or more ownership or control.
The implementation question for developers is: what does your data model look like?
interface BusinessEntity {
registeredName: string;
registrationNumber: string;
jurisdictionCode: string; // ISO 3166-1 alpha-2
incorporationDate: string; // ISO 8601
registeredAddress: Address;
ubos: UltimateBeneficialOwner[];
documents: VerificationDocument[];
}
interface UltimateBeneficialOwner {
fullName: string;
dateOfBirth: string;
nationality: string;
ownershipPercentage: number; // Must capture >= 25% threshold
controlType: 'direct_ownership' | 'indirect_ownership' | 'voting_rights' | 'other_control';
verificationStatus: 'pending' | 'verified' | 'flagged' | 'expired';
lastVerifiedAt: string; // ISO 8601
}
interface VerificationDocument {
type: 'certificate_of_incorporation' | 'business_registration' | 'proof_of_address' | 'ubo_declaration' | 'cr12' | 'shareholder_register';
issuedAt: string;
expiresAt: string | null;
documentAgeInDays: number; // Proof of address: enforce 3-month limit
verificationResult: DocumentVerificationResult;
}
interface DocumentVerificationResult {
status: 'match' | 'mismatch' | 'unverifiable';
crossReferencedAgainst: string; // e.g., 'Companies House', 'BRS Kenya'
discrepancies: string[];
verifiedAt: string;
}
The documentAgeInDays field is not optional. Most jurisdictions enforce a 3-month document age limit for proof of address. If your system accepts a utility bill from eight months ago, you have a compliance gap.
2. Customer Due Diligence (CDD)
CDD goes beyond collecting documents. You are assessing risk based on industry, geography, UBO nationality, and source of funds. This is where most implementations get lazy.
A risk scoring function needs to account for multiple dimensions:
type RiskLevel = 'low' | 'medium' | 'high' | 'prohibited';
interface RiskAssessment {
entityRisk: RiskLevel;
jurisdictionRisk: RiskLevel;
industryRisk: RiskLevel;
uboRisk: RiskLevel;
compositeScore: number; // 0-100
requiresEDD: boolean;
factors: RiskFactor[];
}
interface RiskFactor {
category: 'jurisdiction' | 'industry' | 'ownership_opacity' | 'pep_exposure' | 'adverse_media' | 'sanctions_proximity';
description: string;
weight: number;
source: string; // Which data provider or registry flagged this
}
function requiresEnhancedDueDiligence(assessment: RiskAssessment): boolean {
return (
assessment.compositeScore > 70 ||
assessment.uboRisk === 'high' ||
assessment.jurisdictionRisk === 'high' ||
assessment.factors.some(f => f.category === 'pep_exposure')
);
}
The EU's AMLD6 adds personal criminal liability for compliance officers. That changes the conversation. When a compliance head can face prosecution, your risk scoring system had better be defensible, not just functional.
3. Sanctions and AML screening
Every business entity and every UBO must be screened against OFAC, UN, and EU sanctions lists at a minimum. This is non-negotiable across every jurisdiction we work in.
The technical challenge is not the initial screen. It is the ongoing monitoring. A UBO who was clean at onboarding can appear on a sanctions list three months later. Your system needs to handle that.
interface ScreeningResult {
entityId: string;
screenedAt: string;
listsChecked: ('OFAC_SDN' | 'UN_CONSOLIDATED' | 'EU_SANCTIONS' | 'UK_SANCTIONS' | 'PEP_LISTS')[];
matches: ScreeningMatch[];
nextScheduledScreen: string; // Perpetual KYB requires this
}
interface ScreeningMatch {
listSource: string;
matchedName: string;
matchScore: number; // Fuzzy match confidence
matchType: 'exact' | 'fuzzy' | 'alias';
requiresManualReview: boolean;
}
4. Recordkeeping and audit readiness
This is the one that caught TD Bank out. You can run every check perfectly and still fail compliance if you cannot retrieve the evidence when regulators ask for it.
Accessible verification records for audits are not just a compliance requirement. They enable faster subsequent verifications and reduced operational overhead. If your first verification of a business entity takes 30 days but your second takes just as long because you cannot find the first one, you have an architecture problem.
The UBO verification bottleneck
Here is where theory meets painful reality. 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 comes from chasing documents across multiple registries, waiting for responses from foreign jurisdictions, and manually cross-referencing 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.
The automation path looks like this: pull registry data via API, cross-reference against multiple sources in parallel, flag discrepancies for human review, and auto-approve clean cases. The verification timeline spectrum runs from automated approvals in minutes, to manual reviews in 1 to 3 business days, to complex cases extending longer.
The factors that determine where a case falls on that spectrum are predictable: jurisdiction transparency, ownership complexity, document availability, and whether the entity operates in a high-risk sector.
The document accuracy problem nobody talks about
Here is a data point that should worry anyone building verification systems: Kenyan KYB checks reveal that 3% of CR12 documents contain mismatched shareholder or director data versus Business Registration Service records.
3% sounds small until you consider volume. If you are processing 10,000 business verifications a year, 300 of them have documents that do not match registry data. Your system needs to catch that programmatically, not rely on an analyst spotting the discrepancy in a PDF.
interface DocumentCrossReference {
documentSource: string; // e.g., 'uploaded_cr12'
registrySource: string; // e.g., 'brs_kenya'
fieldsCompared: FieldComparison[];
overallMatch: boolean;
mismatchCount: number;
}
interface FieldComparison {
fieldName: string; // e.g., 'director_name', 'shareholder_percentage'
documentValue: string;
registryValue: string;
matches: boolean;
discrepancyType?: 'spelling' | 'outdated' | 'conflicting' | 'missing';
}
This is not a Kenya-specific problem. Every jurisdiction has data quality issues in its business registries. The UK's Economic Crime and Corporate Transparency Act 2023 is trying to address this. 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 is a step forward. But it does not solve the problem for cross-border verification, where you are pulling from registries with wildly different data quality standards.
AMLD5's hidden complexity
Most teams treat KYB as an onboarding event. Run the checks, collect the documents, approve the entity, move on. AMLD5 says otherwise.
The directive mandates periodic UBO reviews and data gap assessments beyond initial onboarding. This means your system needs to handle perpetual KYB: monitoring for ownership changes, watchlist additions, and registry updates on an ongoing basis.
The compliance officers who understand this are the ones building event-driven architectures rather than batch processes. A UBO ownership change should trigger a re-assessment automatically, not wait for a quarterly review cycle.
Industry-specific requirements
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 (VASPs) under the FATF Travel Rule.
The practical difference is mostly about enhanced due diligence thresholds and source-of-funds verification depth. Financial services regulators expect more granular ownership tracing. Crypto regulators are still building their enforcement muscle, but the direction of travel is clear.
Where most implementations break down
The real challenge is not any single verification step. It is coordinating CIP, CDD, sanctions screening, and recordkeeping across multiple vendors and data sources in a single coherent workflow.
We built Zenoo to solve exactly this orchestration problem. Instead of stitching together five different provider APIs with custom glue code that nobody wants to maintain, you configure the full verification flow in one place. The compliance logic stays consistent, the audit trail stays complete, and your team spends time on genuine risk decisions instead of fighting integration bugs.
If you are building compliance flows and this resonates, check out zenoo.com. 30 minutes. Your data. No slides.
The real cost of getting this wrong
TD Bank's £3 billion fine came with operational restrictions, leadership changes, and decade-long compliance monitoring. That is not just a financial penalty. It is a business constraint that affects every strategic decision for years.
The organisations that avoid this outcome are not the ones with the most expensive compliance tools. They are the ones with verification systems that can answer any question a regulator asks, quickly, accurately, and with a full audit trail.
That is the bar. Everything else is noise.
Stuart Watkins is CEO of Zenoo, the compliance orchestration platform that connects identity verification, screening, and risk decisioning in a single configurable workflow.
