Customer onboarding document checks: compare ID, address and bank statements

Decide what each document is meant to establish

A customer uploads an identity document, an address document and a bank statement. The names look similar, the PDFs open and the application is almost complete. Before approving it, the reviewer needs a more precise question: which claim does each file support, and which checks still depend on an issuer or another trusted source?

The following is a suggested review workflow for teams handling customer onboarding. It is not a universal list of documents every customer should provide. Your service, jurisdiction and documented policy determine what you may collect and what evidence you need. Ask only for material relevant to that purpose.

Separate consistency, authenticity and the person applying

NIST's Digital Identity Guidelines distinguish checking evidence, checking identity attributes and establishing that the applicant is the rightful owner of that evidence. Use that distinction to keep your review honest: agreement between uploaded files answers a narrower question than verification of a person's identity.

For example, the same name in three files is a consistency finding. It does not demonstrate that three independent organisations issued genuine records. Equally, an address difference is an unresolved detail until you have checked its meaning and timing. Record what agrees, what differs and what is still unknown as separate findings.

NIST provides a digital-identity framework, rather than a certification for this checklist or for DeepfakePolicy. Regulated EU financial institutions should also consider the EBA's remote-onboarding guidelines within their own applicable compliance programme. An automated comparison cannot replace that programme.

Make extracted values traceable to the source

Start with an inventory: filename, document role, available pages, visible issue date and any missing or unreadable area. Keep the submitted copy separate from a reviewer-created crop, annotation or conversion. If your case system records a file hash, use it to distinguish versions; a hash identifies bytes, not whether their contents are true.

For each important field, record the value as shown, its file and page, and any interpretation used for comparison. Preserve the original spelling alongside a normalised version. Do not silently convert an uncertain character, infer a missing apartment number or choose a date convention simply because it makes the documents match.

A field that cannot be read should remain unreadable. A page that was not supplied should remain missing. Those states need different follow-up actions from a clear discrepancy between two readable values.

• Name: compare the complete available name, allowing for documented naming and transliteration differences.
• Address: compare street, number, unit, postcode and country separately where available.
• Dates: label issue date, statement period, document expiry and submission date explicitly.
• Account details: distinguish a holder name from an account reference and from a payment recipient.
• Scope: record missing pages, redactions and unsupported files before drawing conclusions.

Work through a fictional onboarding bundle

This example is fictional. It is an editorial exercise, not a customer case or the output of a live DeepfakePolicy check. Assume a reviewer receives an application, an identity-document copy, an address document and page one of a bank statement. The submitted account reference is omitted here because it is unnecessary to explain the method.

The customer declares a current address of 24 Cedar Lane, flat 2. The address document supports that wording; the statement shows 18 Cedar Lane. The reviewer has found a difference, but the bundle alone does not establish whether it reflects a move, an outdated bank record, a different customer or an altered file.

• Read the related guide to bank statements in rental applications

Give ordinary differences a fair review path

Before calling a difference suspicious, consider whether the fields describe the same thing. A bank's correspondence address may differ from the address being declared now. An abbreviated holder name may omit information visible elsewhere. A local date format can be ambiguous. None of these possibilities should be accepted automatically; each should produce a focused question.

Use a consistent exception process. Keep the original finding, record the customer's explanation, identify any additional evidence and show who accepted or rejected the explanation. Another reviewer should be able to understand the resolution without reconstructing a private conversation.

Avoid making customers repeat the entire submission when one narrow gap remains. Where your policy permits an alternative evidence route, explain it clearly. A reviewer can be thorough while keeping the request proportionate and understandable.

Write a follow-up request that resolves the actual gap

A useful request describes the observation and the required next step. For the fictional address example: 'The address document shows 24 Cedar Lane, while the statement shows 18 Cedar Lane. Please confirm which is current and provide the evidence listed in our address policy. Use the secure upload route and include only the information requested.'

That wording gives the customer something concrete to answer. It avoids turning an automated flag into an accusation. If the concern is missing pages, request those pages and explain why they are needed. If the issue is a possibly altered document, follow your approved verification or fraud-escalation process instead of suggesting that another screenshot will settle it.

When an issuer check is necessary, use an approved, independently established channel. Contact details printed on the disputed file are part of the material being assessed. Record what the check actually confirmed and any remaining limits.

Use document review and Cross-check for different questions

A document-level review concerns the submitted file itself. A comparison concerns the relationship between files and the description supplied with them. Keep those findings separate: a bundle may contain matching information while still needing authenticity checks, and an authentic document may contain an outdated detail.

DeepfakePolicy's Cross-check workflow can help review supplied evidence for matches, discrepancies and insufficient evidence, with source references for review. Read the cited source and page before acting. It does not contact the issuing bank or registry, prove identity, certify liveness or decide whether a customer is eligible for your service.

For this use case, describe the specific fields to compare and include only the necessary supporting material through an authorised workflow. Check current supported formats, processing terms and retention information before uploading identity or financial records. Keep the final onboarding decision in your own controlled process.

• Review the scope of Document Fraud checks
• Explore Cross-check examples and limitations
• Read business data-processing terms

Keep a useful decision record and limit unnecessary copies

Record the claim being checked, the evidence reviewed, the unresolved questions, any issuer or independent validation, and the authorised decision-maker's conclusion. Keep the recorded automated findings distinct from later reviewer notes. A result that says 'insufficient evidence' is a review outcome to resolve, not an approval or a fraud verdict.

For organisations subject to the GDPR, Article 5 includes purpose limitation, data minimisation, accuracy, storage limitation and security principles. Apply those principles to both original documents and extracted values. Define who can access the material, which copies are needed, how long they are kept and how corrections or deletion are handled under the applicable requirements.

Before closing the case, ask whether another reviewer can answer three questions: what did we observe, how did we resolve the important gaps, and who was authorised to act? If the record cannot answer them, a reassuring score or three matching names will not make it complete.