KYC and KYB automation

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 KYC and KYB automation cannot start with generic OCR

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.

KYC and KYB automation is 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

KYC and KYB automation diverge here: 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.

Choosing KYC software, and what the comparisons leave out

Most evaluations of KYC software compare document coverage and per-check price, because those are the two numbers vendors publish. Neither predicts what the system will cost you to run. The figure that does is the straight-through rate on your own applicant mix: the share clearing without a reviewer. Everything a KYC verification software licence saves you is given back in salary when that number is low.

Ask any KYC provider for it, measured on documents like yours rather than on their benchmark set. The best KYC providers will give you a range and explain what moves it. The rest will answer with an accuracy figure, which is a different question and a more flattering one.

Two further things the comparisons skip. KYC pricing is quoted per check, so your KYC cost per customer depends on retry rates as much as on the headline number, and a system with poor capture guidance bills you twice for the same applicant. And automated KYC coverage degrades at the edges of a vendor's document library, which means the relevant question is not how many document types are supported but how the system performs on the specific ones your applicants actually hold.

Automated identity verification as an API, not a product

Where onboarding already exists and only the verification step is missing, the deliverable is an identity verification API rather than a platform. One call in, a structured decision out: extracted fields, per-field confidence, a face-match score, a document authenticity verdict and a recommended action.

That shape matters because it keeps the decision logic yours. A know your customer API that returns a pass or fail has made a policy choice on your behalf; one that returns scores and evidence lets your compliance function set the thresholds, which is where that judgement belongs. Our automated identity verification work is built the second way, and the threshold configuration is handed over with the system.

The same applies to an ID verification API serving several products at once. Different risk appetites for a consumer signup and a corporate account mean different cut-offs against identical extraction, and that is a configuration question rather than a second integration.

KYB solutions are a different build, not KYC with more fields

Know your business verification starts where KYC ends. A certificate of incorporation, articles, a registry extract and a shareholding structure, from which you have to establish who actually controls the entity. The extraction machinery is shared; nothing else is.

Beneficial ownership is the whole difficulty. It sits behind holding companies, nominee directors and cross-border structures, and the document naming it is frequently several layers up a chain the applicant did not disclose. KYB checks therefore have to traverse rather than read: resolve the entity, pull its registry record, identify its corporate shareholders, and repeat until you reach natural persons. Every one of those persons then runs through the individual pipeline.

Reconciliation is the second problem. Company names disagree between the certificate, the registry and the application form, in ways that are usually innocent and occasionally not. KYB data quality varies enormously by jurisdiction, and a KYB verification build that assumes registry coverage it does not have will fail quietly in exactly the markets you expand into next.

Expect a lower straight-through rate on KYB than KYC and treat that as correct. The structures that fall out are the ones nobody should clear automatically. KYB compliance requirements also differ by regulator in ways KYC requirements largely do not, so the rule set is a configuration surface rather than a constant.

Document fraud detection sits inside verification, not beside it

A genuine document belonging to someone else and a forged document are different failures with different countermeasures, and KYC fraud detection has to address both. Authenticity checks look at security features, font and spacing consistency, checksum validation on the document number, and whether the image shows a document or a photograph of a screen. The face match addresses the other half.

The signal teams most often miss is at the image level rather than the content level. Recompression artefacts, inconsistent noise across a region, and edges that do not match the rest of the document are what a manipulated field looks like, and none of them appear in extracted text. A pipeline that reads fields accurately and never inspects the pixels will pass a well-made forgery with high confidence.

We build this as a scored signal alongside extraction rather than as a separate gate, so a reviewer sees the authenticity evidence next to the fields it relates to. Treating it as a separate product means two queues and two thresholds that nobody reconciles.

Where verification ends and monitoring begins

KYC and KYB automation covers a point in time. Compliance does not stop there, 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.

KYC and KYB automation, 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