Inside a Modern Verification Stack

Pipeline shape

A modern stack sequences capture, document checks, biometrics, and risk signals, then returns a clear outcome.

Each stage feeds the next. Poor capture makes document checks unreliable, an unreliable document makes the face match meaningless, and risk signals only add value when the other layers have done their job. Thinking about the stack as a pipeline, rather than a list of features, makes it easier to see where a failure starts.

A typical sequence looks like this:

1. Capture the document and a live image of the person.
2. Check the document is genuine and read its data.
3. Confirm the person is live and matches the document portrait.
4. Add risk signals from the device, session and data.
5. Combine everything into a decision and send it to your backend.

Capture

Most verification failures start with a bad photo: glare across the data page, a blurred portrait, a cropped corner. Good capture guides the user in real time, detects the document edges, rejects frames that are too dark or out of focus and only takes the picture when the image is usable.

Device choice matters too. Many users start on a desktop, where webcams are poor and NFC is unavailable. A QR handoff lets them continue on their phone and return to the original session when finished. That single step often does more for completion rates than any change to the checks themselves.

Document layer

Document verification answers one question: is this a real, unaltered document issued by the authority it claims? It usually combines three methods.

The chip is the strongest of the three, because the data is cryptographically signed by the issuing state. Where it is available, it is worth using. Where it is not, visual and MRZ checks remain the baseline, and the flow should fall back gracefully rather than fail.

Biometric layer

The biometric layer answers a different question: is the person in front of the camera the holder of this document?

Face matching compares the live image with the document portrait, or with the chip photo, which is usually cleaner. Liveness detection checks that the image comes from a live person who is present now, not a printed photo, a screen replay or a mask. That covers presentation attacks. Injection attacks, where a fake video stream is fed directly into the app or browser, need separate defences at the device and session level.

These two checks only work together. A face match without liveness can be beaten with a photo. Liveness without a face match proves someone is real, but not that they are the right person. Our article on face matching and liveness goes deeper into how the two interact.

Risk signals and orchestration

Each layer answers a different question. Orchestration decides which checks run for which risk tier.

Risk signals add context the document and face cannot provide: an emulator or virtual camera, a session that has been replayed, the same face appearing on several accounts, or data that does not fit together. None of them should decide on their own, but they shift how much you trust the rest.

Orchestration turns this into policy. Running every check on every user is expensive and adds friction. Running too few lets fraud through. A common approach is to tier by risk:

• Low risk: document check, face match and liveness.
• Medium risk: add NFC chip reading where available and stricter thresholds.
• High risk: add manual review of edge cases and repeat checks on sensitive actions.

The tier can depend on the product, the transaction value, the market or signals collected earlier in the session. Read the anatomy of identity fraud for the attack patterns these tiers are meant to address.

Results and integration

The output should be a decision your backend can act on, not a pile of raw scores. A useful result includes the overall outcome, the checks that ran, the reason for any failure and a timestamp.

Conceptually, integration has two parts. Your frontend starts a session and hands the user into the flow. When the flow ends, a webhook notifies your backend, which fetches the result and updates the account. Treat webhooks as a trigger, not the source of truth: verify their signature, handle retries and make processing idempotent so a duplicate call does not create a duplicate account.

Operating in production

Monitoring thresholds, failure modes, and user drop-off keeps assurance high without burning conversion.

Once live, the stack needs the same attention as any other production system. Track:

• Drop-off by step. If many users leave at capture, the problem is guidance or device support, not fraud.
• Failure reasons. A rise in document rejections from one country often points to a capture issue or an unsupported document version.
• Manual review volume. If it keeps growing, thresholds may be too strict or the tiers too broad.
• Threshold changes. Treat them like code changes: log them, review them and measure the effect.

secuveri covers documents from 46 countries, with NFC chip reading where available, face matching, liveness detection and fraud signals. You choose which checks run in each flow, and the flow can be white-labelled to match your product.