Document AI products are good at extraction and they stop there, handing you a structured object. A bank does not need data, it needs a record — and five things have to happen in between: classify, map, validate, route the exceptions, and prove it. None of them ship in a product, because all of them depend on your core, your rules and your regulator. The question that most deserves an answer before go-live is the one nobody writes down: when a field is read wrong and an account opens on it, what was the control?
There is a well-funded market selling document extraction to banks — KYC360, Veryfi, Kanverse, WorkFusion, KlearStack, Affinda, Mindee and a dozen more. The products are genuinely capable, the demos are impressive, and the accuracy figures are mostly real within the terms they were measured on.
They also all stop at the same place. The output is a structured object representing what the system believes the document said. Everything that turns that into a customer record on a core banking system is yours, and it is the larger half of the work.
Where the product ends
01 — Classify, because intake is mixed
You cannot validate fields until you know what document you are looking at, and real intake is messy: a passport, a utility bill and a bank statement arriving in one batch, sometimes combined in a single PDF, often photographed at an angle.
Commentary from the document AI field makes this point bluntly — many implementations automate routing while leaving the extraction layer untouched, and the real bottleneck is extraction accuracy together with document classification. Classification is the step that decides whether extraction has any chance at all, and it is the step most often assumed rather than built.
02 — Map, and expect semantic mismatch
This is rarely a field-count problem. It is a meaning problem.
A document carries a full name as printed. A core may hold given name, middle name and surname separately, with length limits and a character set the printed name violates. Dates arrive in the document's format and the core insists on its own. Addresses are the worst case: free text on a utility bill has to become whatever structured shape the core enforces, in a country where addresses may not have the components the schema expects.
Every mismatch needs a rule, and every rule needs a decision about what happens when the input does not fit. Those are business decisions wearing technical clothing, and they need an owner who can make them. The general shape of this problem is the one we described in core banking integration — it is the same difficulty arriving through a different door.
03 — Validate and screen
Extracted values have to be checked against business rules, cross-checked between documents where the same fact appears twice, and run through sanctions and PEP screening before anything is created. A name that extracts cleanly and matches a watchlist is a very different outcome from one that does not, and the pipeline has to know the difference before an account exists rather than after.
04 — Route the exceptions, and treat the queue as a product
Low-confidence values go to a human. That sentence hides an entire application: who works the queue, what they see alongside the uncertain field, how fast they must respond, what they are permitted to change, and what the customer's application does while it waits.
It also hides a measurement trap. A system that defers a large share of fields can report excellent accuracy on the ones it answered while handing most of the work back to operations. Accuracy and deferral rate are only meaningful together — we went into why in field-level accuracy. Teams that build the extraction and leave the exception queue for later usually find it becomes the bottleneck the whole programme was meant to remove.
05 — Prove it
You need to be able to reconstruct, for any field on a customer record, which document image it came from, what the system read, how confident it was, whether a human changed it, and who.
Regulators are specific about the adjacent evidence. The CBUAE's digital identification guidance tells institutions to keep a copy of the Emirates ID and its digital verification record. India's RBI requires V-CIP data and recordings to be stored in systems located in India, with the activity log and the operator's credentials preserved. Those obligations shape storage, retention and residency, and they are much cheaper to design in than to retrofit — as we covered for India and the UAE.
The question nobody writes down
When a date of birth is read wrong and an account opens on it, who was accountable?
The answer is always the bank. Vendor contracts place responsibility for the record on the institution, and regulators concur — the RBI's position on video-based identification is that responsibility for customer identification rests with the regulated entity even where AI performs the checks. Meanwhile the operational process quietly assumes the system is right, because it usually is.
That gap is where the risk actually lives. The design question is not "how accurate is the model" but "which fields get a second pair of eyes regardless of confidence, and on what basis". For most banks the answer is a short list — identity number, date of birth, name as it will be screened — and writing that list is a half-day exercise that materially changes the risk profile of the whole programme.
It is also, conveniently, the kind of control an auditor can understand and test, which is not true of a confidence threshold.
Questions we get asked
Why isn't extraction enough on its own?
Because extraction produces data and a bank needs a record. Before that object becomes a customer record you must know which document it was, map every value onto the core's fields and formats, validate and screen it, decide what happens to uncertain values, and keep evidence. None of that is generic enough to ship in a product.
Why is mapping harder than it sounds?
Semantic mismatch, not field count. A printed full name versus separate given/middle/surname with length and character limits. Document date formats versus the core's. Free-text addresses versus an enforced structure. Each needs a rule, and each rule needs a decision about what happens when the input doesn't fit.
Why does classification come first?
Because you can't validate fields until you know the document, and real intake is mixed — passport, utility bill and statement in one batch, sometimes one PDF, often photographed sideways. Field commentary is blunt: many implementations automate routing but leave extraction untouched, and the bottleneck is accuracy plus classification.
What happens to low-confidence extractions?
They go to a queue, and the queue is a product someone must design — who works it, what they see, how fast, what they may change, and what the application does meanwhile. Note the trap: a system deferring heavily can report great accuracy while handing the work back to operations.
What has to be kept for audit?
Enough to reconstruct any field: which image, what was read, confidence, whether a human changed it and who. The CBUAE wants the Emirates ID copy and its digital verification record; the RBI wants V-CIP data stored in India with the activity log and operator credentials preserved. Design it alongside the pipeline.
Who's accountable for a mis-read field?
The bank, always. Vendor contracts say so and regulators agree — the RBI holds that responsibility for identification rests with the regulated entity even where AI performs the checks. So the design question isn't model accuracy, it's which fields get a second pair of eyes regardless of confidence.
We build the integration layer between onboarding and the core — the mapping, the exception queue and the evidence trail rather than the extraction model itself. If you are evaluating a document AI product, the useful question to put to them is where their scope ends, and then who is doing everything after it.