KYC and KYB automation development

What you get

• Document classification and localisation before extraction, so compute is spent only where it pays
• Image normalisation — deskew, perspective correction, glare suppression — where most accuracy is actually won
• Field-level OCR validated against per-document-type format rules and checksums
• Facial recognition matching the document portrait to a submitted selfie, with a threshold your compliance team owns
• Per-field confidence scoring, with low-confidence cases escalated rather than passed
• Served as a typed API, so onboarding calls one endpoint
• Edge-deployable classification for latency- or cost-sensitive deployments

• PaddleOCR
• DeepFace
• YOLOv8n
• OpenCV
• FastAPI

Why generic OCR fails on identity documents

Passports, national IDs and driving licences from different countries share no layout, no field order and no fonts. Run a general OCR pass over that and you get confident nonsense — which in a compliance workflow is materially worse than getting nothing, because nothing gets escalated and nonsense gets recorded.

The fix is to classify before you read. Identify the document type and locate it in the frame first, and an open-ended reading problem becomes bounded extraction against a known template. This is also where the compute savings come from: a cheap classifier gates the expensive extraction, so the heavy pipeline never runs on frames without a usable document. That single decision is what produced the 70% compute reduction on our FinTech build.

Preprocessing decides your accuracy

Real submissions arrive skewed, glare-blown, cropped, motion-blurred and shot at whatever resolution the applicant's phone defaulted to. Teams reliably underestimate this and reach for a better model when the actual problem is the input.

Deskewing, perspective correction, glare suppression and contrast normalisation before a single character is read will move accuracy further than swapping OCR engines. A correctly rectified image under even lighting is a dramatically easier input than anything an untrained user produces unassisted.

Validation, not just extraction

Extracted fields should be checked against what the document type guarantees: checksum rules on document numbers, plausible date ranges on expiry and birth, character sets per issuing country, cross-field consistency. A misread that violates a format rule becomes a caught error instead of a silent corruption of the customer record.

This is the difference between an OCR demo and a compliance system. The demo reports accuracy; the system reports which specific extractions it does not trust.

Face matching is a score, not a verdict

Comparing the document portrait against a submitted selfie produces a similarity score. Where the accept threshold sits is a policy decision with a real false-accept versus false-reject trade-off attached, and that decision belongs to your compliance team rather than buried in a constant in the code.

We build the threshold as configuration, log the score on every decision, and make the trade-off visible so it can be tuned against observed outcomes rather than guessed at once during implementation.

KYB: verifying the business, not just the person

Onboarding a company is a different problem from onboarding a person, and teams usually discover that after the individual pipeline is finished. Know Your Business work starts with a certificate of incorporation, articles, proof of address and a registry record, then has to establish who actually controls the entity. That ownership question is the whole difficulty: beneficial ownership sits behind holding companies, nominee directors and cross-border structures, and the document that names it is often several layers up.

The extraction machinery is the same one described above, pointed at different documents. What is genuinely new is reconciliation. Company names disagree between the certificate, the registry and the application form, in ways that are usually innocent and occasionally not. Registry data arrives in a different format per jurisdiction. And a beneficial owner identified on paper then has to run through the individual identity pipeline, which means the two systems have to hand work to each other rather than sit side by side.

We build it as one flow: classify and extract the corporate documents, pull and reconcile the registry record where an API exists, resolve the ownership chain to the individuals at the end of it, run each of those through identity verification, and escalate the structures nobody should be clearing automatically. The straight-through rate is lower than for individual onboarding and that is correct, because the cases that fall out are the ones worth a person.

Where verification ends and monitoring begins

Onboarding is a point in time. Compliance is not, and the boundary between the two is where scope arguments happen. Ongoing monitoring covers sanctions and watchlist rescreening, changes to a company's registry record, periodic refresh of expiring documents, and transaction patterns that do not match the profile established at onboarding.

We build the parts that are engineering: the scheduled rescreening, the registry change detection, the document expiry tracking, the case queue, and the audit trail that reconstructs why a decision was made and by whom. We do not build the risk model or the rules that decide what is suspicious, because those belong to your compliance function and to the regulator you answer to. A vendor who offers to write them for you is selling something you should read carefully.

Build versus buy against Sumsub, AU10TIX and Onfido

Vendors give you compliance coverage, a support contract and coverage of document types you would otherwise build yourself. That is genuinely valuable and for many companies it is the right call.

The economics tip toward building when verification volume is high enough that per-check pricing dominates your unit costs, when your document mix includes types vendors deprioritise, when you need thresholds and escalation rules a vendor will not expose, or when data residency requirements rule out sending identity documents to a third party. Our FinTech client hit the first and third of those, and the build paid for itself against the manual-review cost alone.

Keeping a human in the loop

Automation removed roughly the routine 90% of the review queue on our production build. It did not remove the reviewer from the cases that genuinely need judgement, and that is the design decision that made the system acceptable to compliance in the first place.

Every field carries confidence, and low-confidence extractions escalate rather than pass. A system that automates everything including the cases it should not is not a cost saving — it is a liability with a lower headcount.

Automated document verification, end to end

Automated document verification is four stages, and skipping any one of them is how projects fail. Classify the document so you know which template and which field expectations apply. Extract the fields. Validate them against checksums, expiry rules and the MRZ. Then score the whole result so the uncertain cases route to a human instead of passing silently.

AI document verification differs from the rules-based checks that came before it mainly in the first and last stages. A rules engine needs to be told what document it is looking at and returns pass or fail; a model can classify an unfamiliar document type and return a calibrated confidence instead of a verdict. That confidence is what lets you automate the routine 90% while keeping the ambiguous cases in front of a reviewer who can see why the system was unsure.

Proof, from delivered work

• Ace Money Transfer · FinTech

  KYC onboarding, fully automated

  €40k annual cost removed · 98% field-detection accuracy · 70% less compute vs. baseline

  Read the case study →

Frequently asked