Not every pass is equal: using assurance levels in onboarding decisions

Treat the three passes as three different strengths of evidence, and decide before launch what each one is allowed to do. A chip pass rests on data the issuing state signed. A gov_db pass rests on the government's own record. A document pass rests on how a document looked in a photograph. All three can be genuine customers, and all three should be onboarded, but they should not get the same limits by default.

The practical rule is: route on the assurance level together with the photo the face was matched against, give each tier an explicit policy, and give customers a way to move up a tier instead of failing them.

What does each assurance level mean?

In Myaza Trust Identity Verification, every passing verification carries an assuranceLevel, described in the Countries and ID types documentation:

The ordering reflects where the evidence comes from. NIST's identity proofing guideline, SP 800-63A-4 (opens in a new tab) (July 2025), uses a similar ladder: its strongest evidence category requires validation "through the cryptographic verification of the evidence contents and the issuing source", including "a trust chain back to a trust anchor". That is what a chip check does. NIST is a US framework and its categories do not map one-to-one onto these tiers, but the logic is the same.

Why is the pass not enough to route on?

Because two verifications with the same verdict can carry very different amounts of proof.

Consider two illustrative applicants to the same investment app. One is a Kenyan customer verified against the government record, with a selfie matched to the record photo. The other is an applicant from a country with no reachable database, verified from a driving licence photograph, with the selfie matched to the photo printed on that licence. Both come back verified. Only one of them was checked against a source the applicant could not have produced.

The second field that matters is facialMatchSource, which says which photo the selfie was compared with: gov_record, chip or document. A match against the printed photo is weaker evidence, because a forger prints their own face on the forgery; in Myaza Trust it never raises the assurance level. A policy that looks at assuranceLevel but ignores facialMatchSource misses half the picture.

How should each tier be treated?

Here is a starting policy for an app that holds and moves money. It is illustrative; your own limits depend on your product, your licence and your risk appetite.

Three principles sit behind the table.

1. Tier sets the ceiling, not the floor. A document-tier customer is not a suspect. They are a customer about whom you know less, which is a reason for smaller limits, not for rejection.

2. Assurance is about identity, not risk. A chip pass says the person is who the passport says. It says nothing about whether they are sanctioned, politically exposed or about to commit fraud. Screening and monitoring apply at every tier.

3. Let customers climb. A customer at document tier who later verifies with a chip passport in your mobile app, or with a second ID, should be able to move up. Offer the upgrade path rather than a permanent cap.

What does this look like as a decision graph?

In Myaza Trust Workflows, a decision graph runs after the checks finish, branches on fields such as verification.assuranceLevel and verification.facialMatchSource, and lands on approve, review or decline. A tag action can mark the tier so your backend sets limits from the workflow.run.completed webhook. An illustrative graph for the policy above:

1. Wait for screening
2. If screening.anyMatch            -> open case, then REVIEW
3. If verification.status != VERIFIED -> DECLINE
4. If assuranceLevel in [chip, gov_db]
     and facialMatchSource in [chip, gov_record] -> tag "tier-full", APPROVE
5. If assuranceLevel == document    -> tag "tier-reduced", APPROVE
6. Otherwise                        -> REVIEW

Your backend reads the outcome and the tags from the webhook and applies the limits. Because each run is pinned to the workflow version it started with, changing the policy later never rewrites a decision already made. The decisioning documentation lists the fields and node types.

What are the edge cases?

A chip on the government database path. In Myaza Trust, when an ID is also checked against a government database (a Nigerian passport, for example), the selfie is compared with the government's photo rather than the chip's. On that path, a chip reaches the chip tier only if Active Authentication proves it is not a copy; otherwise the verification still passes at gov_db. That is not a downgrade in practice: both tiers receive the same treatment in the policy above.

A chip that could not be confirmed. A chip whose issuing country is not on the trusted certificate list, or that cannot be read, never fails the verification. It simply does not contribute chip assurance, and the verification is decided on its other checks. See the NFC chip documentation for the details.

Approvals despite a failed check. Assurance levels attach to passing verifications. When a reviewer approves someone whose check failed, the record keeps the failed checkStatus and its reasonCode. Treat those approvals as their own category in your limits policy, not as a pass at any tier.

Checklist before you launch

• Store assuranceLevel and facialMatchSource with every customer record, beside the outcome.

• Write a one-page policy mapping each combination to an outcome and a limit.

• Implement it as a decision graph so it is applied consistently, and tag the tier for your backend.

• Give lower-tier customers a route to a higher tier.

• Keep screening and monitoring on for every tier.

• Review the policy when you add markets, because the tier your new customers can reach depends on the country.

Customer due diligence requirements differ by jurisdiction and licence, and this article is general information, not legal advice. The underlying idea travels well: know how strongly each identity was proven, and let that decide how much you rely on it.