A UK credit broker processing 80 new customer applications a month was losing 22% of them during KYC. Not because those applicants failed the checks — because the process averaged 5.2 working days from submission to approval. Application submitted Monday. Documents emailed Thursday. Compliance officer review Friday. Approval letter sent the following Tuesday. By then, a third of applicants had gone elsewhere. The documents were fine. The pipeline processing them was the problem: five manual handoff points, two shared inboxes, one compliance officer handling 80 cases on top of ongoing regulatory reporting. We rebuilt it. Standard CDD cases now complete in under four hours.
What UK FCA customer due diligence actually requires: document types, verification standards, and AML thresholds at different risk tiers
The Money Laundering, Terrorist Financing and Transfer of Funds Regulations 2017 require FCA-regulated firms to apply Customer Due Diligence before establishing a business relationship. JMLSG Part I Chapter 5 sets out what "verify identity" means at each risk tier: Standard CDD for most retail customers (photo ID plus proof of address dated within 90 days); Enhanced Due Diligence for higher-risk customers (adds source of funds and documented sign-off); and Simplified Due Diligence, permitted only for certain low-risk products. The automation design consequence: the pipeline must determine which tier applies before it processes any documents. A case that receives standard CDD when EDD was required is a regulatory failure, not a process one.
| Risk Tier | Photo ID | Proof of Address | PEP Screen | EDD Required |
|---|---|---|---|---|
| SDD (low risk) | Optional | No | Basic | No |
| Standard CDD | Yes | Yes — 90-day window | Full name match | No |
| EDD (high risk) | Yes | Yes + Source of Funds | Real-time API | Yes — human sign-off |
Identity document extraction: passport, driving licence, and proof-of-address OCR with automated field validation
OCR on passports and UK driving licences sounds like a solved problem. It is not, once you account for smartphone photos taken at an angle, laminate glare on licence cards, expired documents the customer has not noticed, and name format differences between the Machine Readable Zone and the biographical data page.
The pipeline runs a vision model classification pass before OCR to identify document type and assess image quality. Images scoring below 0.72 on the quality metric get rejected immediately with a specific reason returned to the applicant: "Image quality insufficient — photograph in natural light, avoid reflections on glossy surfaces."
For UK passport extraction, the MRZ is reliable for surname and date of birth. The vision model cross-validates against the biographical data page. Discrepancies — "O'Brien" on the bio page versus "OBRIEN" in the MRZ — trigger a refer rather than a fail. Proof-of-address is harder: we extract issuer name, issue date, applicant name, and address, then validate the date against a rolling 90-day window. Around 7% of proof-of-address submissions fail the date check. For the document type classification approach, see document classification with vision models. The extraction infrastructure is closely related to the pipeline in our Invoice OCR case study, adapted here for identity documents.
# UK driving licence field validation
import re
from datetime import date
def validate_driving_licence(fields: dict) -> dict:
result = {"pass": True, "flags": []}
expiry = fields.get("expiry_date")
if expiry and expiry < date.today():
result["pass"] = False
result["flags"].append("DOCUMENT_EXPIRED")
# UK licence number: up to 5-char surname stem + 6-digit DOB encoding + check digits
licence_num = fields.get("licence_number", "")
pattern = r"^[A-Z]{1,5}[0-9]{6}[A-Z]{2}[0-9]{2}[A-Z]$"
if not re.match(pattern, licence_num.upper()):
result["flags"].append("LICENCE_NUMBER_FORMAT_MISMATCH")
mrz_name = fields.get("mrz_surname", "")
bio_name = fields.get("bio_surname", "")
if mrz_name and bio_name:
if normalise_name(mrz_name) != normalise_name(bio_name):
result["pass"] = False
result["flags"].append("NAME_FIELD_DISCREPANCY")
return result
AML screening integration: connecting Dow Jones Risk, LexisNexis, and Comply Advantage via API without a compliance team rewrite
Three providers handle most UK SME-scale AML screening: Comply Advantage, Dow Jones Risk & Compliance, and LexisNexis Bridger Insight. Comply Advantage is the right starting point for most builds — fast onboarding, lower cost per search, structured JSON responses, and configurable match sensitivity. Dow Jones RiskCenter has broader PEP dataset depth at higher unit cost, used by larger regulated entities. LexisNexis Bridger is strongest for ongoing monitoring of an existing book, not point-in-time onboarding.
For this broker we used Comply Advantage at onboarding and LexisNexis for periodic rescreening. Every search returns NO_MATCH, POSSIBLE_MATCH, or MATCH. The POSSIBLE_MATCH cases — fuzzy name hits with a shared birth year — are what need routing logic.
Match threshold configuration is where mistakes happen. Set it too low and false positives flood the human queue. Set it too high and genuine hits pass through. We landed at a threshold producing roughly 4% POSSIBLE_MATCH rate on this portfolio — about 3 referrals per month on 80 applications, which is manageable for one compliance officer.
PEP and sanctions list checking: the real-time pass, refer, and fail routing that replaces manual triage
PEP status and sanctions hits are legally distinct. A sanctions match is a hard stop with mandatory OFSI reporting obligations. A PEP match triggers Enhanced Due Diligence — not rejection.
Document extracted → AML screening API
├── NO_MATCH → automated pass → continue to decision
├── POSSIBLE_MATCH → human review queue (8-min median review time)
└── MATCH
├── Sanctions list hit → HARD STOP
│ └── Freeze application + MLRO notification queued
└── PEP classification only → EDD workflow
└── Collect source of funds, compliance officer sign-off required
The FCA's financial sanctions guidance sets specific timeframes for OFSI reporting after identifying a match. The pipeline logs the hit, suspends the application, and queues the MLRO notification — it does not return a routine rejection reason to the customer, because OFSI reporting obligations constrain what the firm can communicate about a frozen relationship.
One case from this deployment: a customer matching a minor PEP — a local councillor in a secondary category. The pipeline correctly routed to EDD rather than rejection. The compliance officer cleared it in 11 minutes with a documented risk assessment. Without the routing distinction between PEP and sanctions, this would have been an incorrect rejection.
Document quality scoring and automatic rejection: filtering blurry scans and expired documents before a compliance officer sees them
The most common KYC automation failure we have reviewed — including one that subsequently failed an FCA audit — had this pattern: the pipeline accepted poor-quality images, passed them downstream, and the compliance officer manually rejected them. The bottleneck moved one step. It did not disappear.
We apply quality scoring and automatic rejection before any case reaches a human.
| Rejection reason | Type | Rate on this portfolio |
|---|---|---|
| Image blurry or out of focus | Auto reject | 9% |
| Document expired | Auto reject | 7% |
| Proof of address older than 90 days | Auto reject | 7% |
| Document partially cropped | Auto reject | 5% |
| Document type not on accepted list | Auto reject | 3% |
| Name or DoB discrepancy between document fields | Refer to human | 4% |
First-submission failure rate is around 35%. That reflects what was already failing manually at step 3 of a 5-step process — catching it at step 1 gets specific feedback to the applicant earlier. Each automatic rejection returns an actionable reason: "Image blurry" with a retake guide; "Document expired" with a list of alternatives. Applicants who receive specific rejection reasons resubmit within 4 hours at a 78% rate; generic rejections produce a 31% resubmit rate. See OCR with human-in-the-loop for the broader rejection-routing pattern.
Human review queue design: what your compliance officer sees when automated checks refer a case and how long they spend on each
Around 8% of applications reach the human review queue: POSSIBLE_MATCH AML cases, name discrepancy refers, and edge cases the quality model flagged but could not resolve.
We built a single review screen surfacing:
- Document images front and back, with extracted field values overlaid
- The specific flag that triggered referral ("Name discrepancy: MRZ 'OBRIEN' vs bio page 'O'Brien'")
- AML match details: matching entity name, confidence score, and PEP/sanctions classification
- Full application form data in one panel
Median review time dropped from 34 minutes to 8 minutes per case. Not because the compliance officer is cutting corners — because they are not hunting through shared folders to find context before they can start thinking. The queue shows case age, and anything over 2 hours triggers an escalation flag. The SLA target here is a decision within 4 hours of document submission; for referred cases the compliance officer clears the queue twice a day in two 25-minute blocks.
Audit trail requirements under FCA SYSC 9 and UK AML regulations: what to log, how to store it, and how long to retain it
FCA SYSC 9.1 requires records sufficient to demonstrate compliance. The Money Laundering Regulations 2017 set a 5-year retention period from the end of the business relationship — not from the onboarding date.
Every pipeline step writes to the audit log: document received (server-side timestamp, never client-supplied); OCR extraction result with model version and per-field confidence scores; quality scoring decision with threshold version applied; AML API call — provider, request hash, response code, match details, threshold version; routing decision with rule set version number; and human review actions including reviewer ID, timestamp, decision, and notes.
Log entries write to an append-only Postgres table — a trigger blocks UPDATE and DELETE on the audit relation. Records replicate to S3 with Object Lock on a 5-year WORM policy, scoped per customer with expiry calculated from relationship end date. Store original document images alongside extraction results: without the originals, you cannot demonstrate what the system actually saw. For related DSAR obligations and retention considerations, see GDPR DSAR automation for UK SMEs.
What changed in 2025–2026: FCA digital identity framework consultation and eIDAS-equivalent guidance for UK firms
The FCA closed its consultation on the UK digital identity framework in late 2024 and published final guidance in early 2026. The framework establishes equivalence criteria for DIATF (Digital Identity and Attributes Trust Framework) certified providers — meaning firms can accept a certified digital identity credential as meeting standard CDD requirements without fresh document capture.
A customer already verified with a DIATF-certified provider (Yoti and Post Office EasyID cover most consumer use cases) can consent to sharing that credential via API. Early adopters report 60% fewer document resubmission events. The practical implication for new builds: design the pipeline to accept both a DIATF credential path and a traditional document upload. Most retail applicants do not hold a DIATF credential yet — build the bridge alongside the existing flow, routing DIATF-verified applicants directly to AML screening and bypassing document extraction.
On eIDAS: UK guidance published in 2026 confirms that EU eIDAS Level of Assurance High assertions are acceptable for CDD purposes for EU-resident applicants, removing a previous grey area that was sending cross-border onboarding to manual review by default.
Good / Bad / Ugly: three KYC automation approaches and the regulatory gap each one exposed on review
Good: API-first screening with explicit routing logic
The setup described above — AML screening via API, routing rules versioned in source control, a human review queue with full case context, and an append-only audit log. Automated decisions where the rule is clear; human review where it is not. This build passed an FCA visit 6 months after go-live with no material findings.
Bad: Outsourced KYC with a black-box portal
A mortgage broker we audited had outsourced KYC to a third-party portal that returned pass/fail decisions with a reference number. The audit log contained the reference and outcome — no extraction results, no AML match details, no routing logic. When an applicant disputed a rejection, the broker could not explain it. JMLSG guidance is explicit: outsourcing CDD does not transfer the regulatory obligation. The firm retains responsibility and must be able to reconstruct every decision. This firm could not, and the audit finding reflected it.
Ugly: Automated pipeline with no human escalation path
A lending fintech set their AML match threshold conservatively enough that a small fraction of POSSIBLE_MATCH cases were auto-declined without human review. One declined customer had a PEP relative — a category-B indirect match. No EDD decision existed because EDD had never run. The customer complained to the Financial Ombudsman. The outcome went against the firm. Every automated KYC pipeline must have a human escalation path for EDD triggers. Auto-declining a possible PEP match without documented EDD is not a configuration choice — it is a compliance gap.