Form pre-population from ID extraction

Pre-population is a write into the application record. Treat it as one. Do not extract structured fields from an identity document until the capture has passed the checks that decide whether the image is a live person presenting an unaltered document.

If liveness or tamper has failed, stop. Do not OCR a failed capture "just in case." Do not queue a retry extract on the same file while the applicant is still on a failed path. The next action is recapture or a human path, not a quieter second read.

Identity vendors in this class (Onfido, Jumio) and core platforms that host the application (Temenos) share the same operating rule: the document image is not an input to form-fill until the session has not failed tamper. Extraction after a pass is a convenience. Extraction after a fail is a contaminated write.

Pair this gate with liveness and deepfake detection. Extraction does not replace that check. A high-confidence read of a name line does not rehabilitate a failed liveness result, and it should not reopen the extract path.

The extract model should return name, date of birth, and document number when those strings are readable on the captured ID. That is the contract. If a field is unreadable, blurry, cropped, or contradictory across sides of the document, leave it empty.

Empty stays empty. Do not invent a postcode. Do not complete an address line from a partial street name plus a model prior. Do not fill a middle name from the machine-readable zone when the visual zone is unreadable and the two disagree. A blank on the confirmation screen is a prompt. A guessed value is a false record that later looks like customer data.

Map extracted values onto the application schema with an explicit field list. Legal name, date of birth, and document number are in scope. Nothing else is in scope for this step. Nationality, place of birth, and address appear on some documents and are the fields where models fill gaps when the image is thin. Keep them off the auto-write list unless policy later adds them with the same empty-stays-empty rule and the same confirm step.

If the applicant already answered a question in chat, do not overwrite that answer with OCR unless the confirmation screen shows both values and the applicant chooses. Silent overwrite of a conversational lead qualification answer is a failure that looks like speed: the chat captured a preferred name or a corrected spelling, then the ID extract put the MRZ string on top, and nobody saw the change until quality review.

If the visual zone and the MRZ disagree on a character in the document number, do not pick a winner. Leave the field empty or surface both strings on confirm. Picking a winner is inventing a value you did not read cleanly.

An applicant presents a passport after liveness and tamper have not failed. The visual zone is sharp on the name line and date of birth. The document number is readable. The machine-readable zone agrees on those three fields. There is no address on the passport, so there is no postcode to extract.

The extract service writes legal name, date of birth, and document number, each tagged with source document, capture ID, and extractor version. Address line 1, city, and postcode remain empty. The confirmation screen shows the three filled values and the empty address block. The applicant types the address. Submit of that slice stays blocked until they confirm the extracted trio.

A broken version of the same session invents a postcode from a language-model completion that "knows" postcodes for a city mentioned in chat, or completes an address line because the form schema marked it required. The form looks finished. The applicant taps continue. Ops later cannot tell whether the postcode came from the document, the applicant, or the model. That is the failure this control is written to prevent.

Every write from extraction needs a provenance record ops can read without opening a vendor console. At minimum record which capture produced the value, which extractor produced it, which document side or zone it came from, a readable or unreadable flag, and the timestamp of the write.

Show that provenance to the applicant in plain language. "Read from your passport photo" is enough on the confirmation card. Keep the capture ID and extractor version in the case file for later review, and for compliance flag auto-resolution when a downstream check asks where a name came from.

Do not merge extracted fields into the application as if the applicant typed them. If your core, including Temenos-class application stores, only has one slot per field, add a parallel provenance object. Collapsing OCR output and applicant input into a single string loses the confirm step in the data model even when the UI still shows a checkbox.

Low confidence is not a license to write a guess. Route unreadable fields to empty and let confirmation collect them. High confidence is still not KYC. It is a typed string from a picture of a document that already passed tamper.

Speed is the outcome, with a visible confirm step. Pre-fill exists so the applicant spends time checking, not retyping. It does not exist so the journey can skip the check.

The confirmation screen lists every field the extractor attempted. Filled values appear as filled. Empty values appear as empty. The applicant can edit any of them. Submit of the slice that contains those fields stays disabled until confirm is explicit. Do not pre-tick the control.

If they edit a value, store the edit as applicant-sourced and keep the original extract in provenance. Do not hide the edit from later KYC steps. A name the applicant corrected is a signal for review, not a nuisance to flatten.

Do not auto-advance on a timer. Do not treat a tap on "next" in a carousel as confirmation of fields that were off-screen. Keep the extracted block in view before confirm is offered, or split confirm per section. Do not confirm what the applicant has not seen.

Empty fields on this screen are working as designed. Coaching copy can say the ID did not yield an address, and ask the applicant to enter it. Do not replace that copy with a model-completed address that the applicant is then asked to "confirm" as if they had seen it on the card.

OCR of name, date of birth, and document number is a data-entry aid. It is not identity verification complete, not screening complete, and not onboarding complete. Treating a successful extract as a passed KYC gate is a failure that shows up as a short journey: the file looks rich, so orchestration skips a step.

Keep extraction as an input to agentic KYC orchestration, not a terminal state in that graph. Orchestration still owns watchlist, documentary completeness, and four-eye rules. A clean extract can shorten the form. It cannot close the case.

If a later step needs the applicant to understand a disclosure, do not bury it under a pre-filled form. Route that work to regulatory disclosure plain-language summary rather than assuming a fast form implies an informed applicant.

Ops review should answer four questions on any pre-populated file: whether tamper failed, which fields extraction wrote, which of those the applicant confirmed or changed, and which fields stayed empty because they were unreadable. If any answer is missing, the pre-fill path is not safe to run. When those answers are present, the journey can be fast without pretending a picture of an ID is a finished onboarding file.