ID Capture in Onboarding: The Obligation Starts at the Photograph

Loan origination, account opening and customer onboarding all begin the same way: a document is photographed, fields are extracted, and a record is created. The extraction is the easy part and the part everyone specifies. What follows it — proving the check happened, noticing the document has expired, and eventually deleting the copy — is where the obligations live, and none of it is visible on the day the system goes live.

Validate at capture, because later is too late

Three checks belong at the point of capture rather than in a downstream review, because all three are cheap to enforce then and expensive to correct afterwards.

The first is internal consistency: a document number that fails its own format, a date of birth inconsistent with an issue date, a value whose check character does not compute. The second is expiry — trivially checkable arithmetic that is routinely deferred, so an expired document enters the record and is discovered by an auditor rather than by the system. The third is that the extracted fields match what the customer stated, where they stated anything, because a mismatch between a typed name and a read name is a signal worth surfacing immediately rather than reconciling in a month.

None of these establish that the document is genuine. That is a separate discipline involving security features, and conflating validation with authentication is a common and consequential confusion — a perfectly extracted, internally consistent, unexpired forgery passes every check above.

The evidence question: what did you check, and when

A regulated onboarding process has to be reconstructable. Two years later somebody may ask what was verified for this customer, on what date, against which document, and by whom or by what. Answering that requires the check to have been recorded as an event, not merely to have influenced an outcome.

In practice this is where automation creates an exposure that a manual process did not have, and it is the mirror image of the problem in PPE monitoring: the system knows things, and a system that knew a document was expiring and did nothing is harder to defend than a clerk who did not notice. Record the extraction, the confidence, the validation results, the thresholds in force at the time, and any human override with its reason. Retention periods for those records are set by your own regulator and sector rather than by general data-protection law, and are worth confirming with them rather than inferring.

Expiry is a scheduled obligation, not a capture-time check

An identity document valid at onboarding expires during the relationship. Most systems handle this badly: expiry is validated once, at capture, and then the stored date is never looked at again. Years later the customer file contains a document that lapsed long ago and nobody was told.

The fix is unglamorous and cheap — the extracted expiry date should create a scheduled obligation, so the file surfaces itself before it lapses rather than after. This is a small amount of work at build time and it is the single most common gap in otherwise well-built onboarding systems, because it only becomes visible on a timescale longer than the project.

Hold as little as the process allows

Identity documents are personal data under Oman's Personal Data Protection Law, issued by Royal Decree 6/2022 and enforceable since February 2026, which expects a stated purpose, a retention period and controlled access — and controls transfers outside the country, making the processing location a compliance attribute rather than an infrastructure detail.

The design question worth asking is what you actually need to keep. Once the fields are extracted and validated and the evidence recorded, the image itself may not need to be retained indefinitely — or may need to be, if your regulator requires the source document. Those two answers lead to different architectures, and the mistake is not choosing wrong; it is never deciding, so the images accumulate forever by default because deleting feels riskier than keeping.

One further caution worth stating plainly: if the flow adds a selfie match against the document photograph, that is biometric processing, and under Article 5 of the PDPL it is prohibited without a Ministry permit — the same constraint that governs facial attendance systems. Reading a document is not biometric processing; comparing a face to it is, and the two get specified in the same sentence far too casually.