When one ID is not enough: verifying two or three IDs in one run

Ask for more than one ID when the weakness of a single ID is exactly the risk you are trying to control, and pick IDs whose evidence comes from different sources. Otherwise the extra step adds friction and cost without adding much proof. Once you have decided to ask, set the pass policy (all must pass, at least two, or any one) by answering one question: if one of these checks cannot confirm the person, would you still onboard them?

Most products do not need multiple IDs. A single government database check with a selfie matched to the record is strong evidence for everyday onboarding. Multiple IDs are for the cases where "strong" is not enough, or where one ID alone leaves a specific gap.

When does a second ID actually add evidence?

A second ID is worth asking for when it answers a question the first one cannot. Three situations come up often.

1. The first ID has no photo to match. Some records return no photo, and some document-only checks rely on the photo printed on the card, which is weaker evidence. A second ID whose record includes a photo gives the selfie something authoritative to be compared with.

2. The product carries higher risk. Large credit lines, high transaction limits or services that attract impersonation justify more evidence up front than a basic wallet.

3. Your policy or a partner requires it. Some banking partners and internal policies ask for two forms of identification for certain customer types. Confirm what your own rules require; requirements differ by jurisdiction, and this article is general information, not legal advice.

What does not add much is two views of one record. Where a second number is an alias or token for the same underlying registration, both checks consult the same source, and agreement between them is expected rather than informative. Prefer combinations that come from separate issuing systems: for example, in Nigeria the BVN comes from the banking system and the NIN from the national identity system, so the two are independent records about the same person.

How should you set the pass policy?

The pass policy decides what the run's result is when the individual ID checks disagree.

A useful way to choose: picture a genuine customer whose second record has a misspelt surname from years ago. Under "all must pass", they fail. If your answer is "we would want a person to look at that", pick a more tolerant policy and route partial passes to review, rather than declining genuine customers automatically.

A failed ID inside a passing run is information

With "at least two" or "any one", a run can pass while one ID fails. Do not throw that failure away. The reason matters:

• A data mismatch on an old record (a spelling, a changed surname after marriage) is common and usually benign.

• A selfie mismatch on one ID while another matches is different: it can mean the second ID belongs to someone else.

• Not found on a number the applicant typed can be a typo or a fabricated number.

Route on the combination as well as the headline. "Passed, but one ID failed its face match" belongs in a review queue, even if the policy says pass.

A worked example

A lender in Nigeria offers two products: a small starter loan and a larger business loan.

• Starter loan: one ID, a BVN or NIN check with a selfie matched to the record. Fast and sufficient for the amount at risk.

• Business loan: two IDs from the Nigerian options the lender allows, with a policy of "all must pass" and failures routed by reason: name-only differences to a light review, face mismatches to a senior reviewer.

An applicant for the business loan verifies with a NIN and a BVN. The NIN passes. The BVN record returns a different middle name and a face match that fails. Under "all must pass" the run fails, and the rule sends it to a senior reviewer because the failure includes a face mismatch rather than only a name difference. The reviewer compares the photos and asks the applicant to explain before deciding.

A second applicant's BVN shows a maiden surname while her NIN shows her married name, and both faces match. She fails the strict policy on data alone, so her application goes to light review, and a reviewer approves her after comparing the two records.

How Myaza Trust runs multiple IDs

In a workflow, the Multiple IDs option verifies two or three IDs in one run. The applicant picks each ID from the ones you allow for their country, one selfie and liveness check covers all of them, and the result is one verification whose status follows your pass policy: all must pass, at least two, or any one. It works in multi-country flows, with each country choosing which IDs its verifications offer.

Each ID is a separate check in the result's multiId.checks, with its own media, including the government record photo the selfie was compared with, and your decision rules can branch on the multiId.* fields for finer routing. Each ID is charged for the checks run on it (its lookup, document read, chip read and face match), while the selfie, liveness and other shared checks are charged once. The workflows documentation and the webhooks documentation describe the configuration and result, and Identity Verification covers the ID types available in each country.

Before you switch it on

• Name the gap a second ID closes. If you cannot, one ID is enough.

• Choose IDs from independent sources, not aliases of one record.

• Pick the pass policy by imagining a genuine customer with one stale record.

• Route partial passes by reason: face mismatches to review, name differences to light review.

• Limit multiple IDs to the products and customer types that need them, since every extra ID adds a step and a charge.

• Test each combination in sandbox, including runs where one ID fails.