Verification, written 1:1. The subject claims an identity, usually by logging into an account or presenting a credential, and the system compares a fresh capture against the biometric template recorded for that identity when it was first enrolled. The answer is yes or no. The typical case is identity verification after a successful onboarding: the customer enrolled their face during onboarding, and every later login, high-value transaction or account recovery is checked against that stored reference.

Identification, written 1:N. No claim is made. The system searches the biometric against the entire enrolled gallery and returns whoever matches, or nobody. Finding a person in a national registry, checking a watchlist, and deduplicating an enrolment are all identification.

ISO/IEC 2382-37 defines this vocabulary formally, which is worth citing in a procurement document when different suppliers use the terms loosely.

A complete identity system chains both operations rather than picking one.

• Capture. The biometric is acquired and validated as coming from a live person. This is where presentation attack detection belongs, tested against ISO/IEC 30107-3, and where injection attacks have to be stopped, because no matching decision downstream can recover from a compromised capture. Identy.io processes capture on the device itself, so the biometric is validated where it is created.
• Verify. A 1:1 check against a claimed record. Fast, cheap, high volume.
• Identify. A 1:N search when no claim exists or when the claim must be tested against the whole population.
• Bind. The verified biometric is linked to a credential or an account, so the identity becomes reusable.
• Reuse. Subsequent interactions verify against the bound credential rather than re-running identification. This is what keeps cost under control at scale.

Systems that skip the bind step end up running 1:N searches for transactions that only ever needed 1:1, which is expensive and slower than it needs to be.

NIST uses the term in its own glossary to describe IDENT, the Department of Homeland Security system that holds biometric records for immigration, border and law enforcement purposes. That gives you the working definition: a large scale repository plus a matching engine, built to answer identification questions rather than authentication questions.

An ABIS differs from an AFIS in scope. An AFIS handles fingerprints. An ABIS handles several biometric characteristics, typically face and fingerprint and often iris, and can combine them in a single decision.

Centralised. All matching happens in one place. This is the classic model and it suits national registries and watchlists.

On-premise or hybrid. The matching engine runs inside the customer’s own infrastructure or a mix of private and cloud. Common in government and regulated finance where data residency is a requirement.

Edge capture with central matching. Capture and validation happen on the device, and only what is needed travels to the central matcher. This reduces latency, lowers bandwidth dependence and keeps enrolment working in low connectivity conditions.

Identy.io is built around the third model. Biometric capture is processed on the device itself, and the ABIS handles centralised 1:N identification and deduplication across the enrolled population. The system is designed for horizontal scaling and supports on-premise and hybrid deployment.

Verification asks whether this person is who they claim to be. Deduplication asks whether this person is already in the database under a different name. The second question is the one that protects a national registry, a benefit programme or a voter roll from duplicate identities.

Deduplication is a 1:N search run at enrolment, against the entire population, every time. An AFIS can already do this across its fingerprint and palm records. A multimodal system runs it on face and fingerprint together, which catches duplicates that a single modality would miss, for example someone enrolling twice with deliberately degraded fingerprints.

Identy.io’s ABIS handles enrolment processing, encrypted template storage, searchable index generation and a deduplication engine with configurable tolerance margins, and was validated through MOSIP’s partner compliance process for governments deploying on that platform.

Capture. A fingerprint enters the system either as a ten-print card, scanned live or digitised from ink, or as a latent print lifted from a surface. Capture quality sets the ceiling for everything that follows. A poor image cannot be rescued by a better matcher.

Feature extraction. The system does not store or compare pictures of fingers. It extracts minutiae, the points where ridges end or split, and encodes their position, direction and relationship to each other. The result is a template. The standard formats for these templates are defined in ISO/IEC 19794-2 and the newer ISO/IEC 39794 series.

Search. The query template is compared against the enrolled gallery. This is a one-to-many operation, usually written as 1:N, where N is the number of records in the database.

Scoring. Every comparison produces a similarity score. The score is not a probability that two prints came from the same finger. What the system does with it depends on the operating mode.

Decision. Here the two modes split.

• Investigation mode, typical of criminal casework. The system returns a ranked candidate list and a latent print examiner reviews it using the ACE-V methodology, which stands for Analysis, Comparison, Evaluation and Verification. The conclusion belongs to the examiner, not to the algorithm.

• Identification mode, typical of civil programmes such as national ID, voter registration or benefits. The system applies a threshold and only returns candidates whose score exceeds it. A hit can be accepted automatically, or confirmed by a trained operator where the programme requires it. No forensic examiner is involved, which is what allows these systems to process millions of transactions.

AFIS technology is mature, well understood and heavily benchmarked. The reference benchmark for large-scale identification is NIST FRIF TE E1N, an open-set 1:N evaluation that exercises the template creation and search algorithms at the core of an identification system. It is the closest public measure of how an engine will perform in a real national-scale deployment. NIST also runs MINEX III for interoperable template matching and PFT III for proprietary one-to-one matching. Vendors submit algorithms and results are published.

Three limits are structural rather than a question of algorithm quality.

One modality. An AFIS works with fingerprints. If the fingerprint is unusable, and manual labour, age or skin condition make that common in real populations, the system has no second route to a decision.

Capture is assumed, not protected. Classic AFIS design assumes a controlled capture environment with a dedicated scanner and an operator present. That assumption does not hold when enrolment happens through a mobile phone in the field.

Centralised by default. Every search travels to a central matcher. In low connectivity environments, or during an outage, the operation stops.

The picture is not one global ban. It is a set of jurisdiction-specific rules moving in the same direction at different speeds.

Of those three, recovery is the least discussed and the most exposed.

Recovery is a recognised design problem in large passkey deployments, not a vendor talking point — the FIDO Alliance publishes guidance on it precisely because the industry has not settled it. The credential is device-bound by design, which is what makes it strong, and what makes losing the device a problem the credential cannot solve on its own.

At that moment the institution has nothing cryptographic to work with. It has a person claiming to be an existing customer. Historically, the answer was a knowledge-based question, a call centre agent, or an SMS to the registered number. NIST SP 800-63A-4 states that knowledge-based verification must not be used for identity verification. The SMS route is the one being decommissioned. Call centre verification remains a heavily targeted social engineering surface in retail banking.

What remains is the ability to verify that a live, real person matches the identity that was originally enrolled. That is biometric identity verification, performed against the enrolment record, not a local unlock gesture. [internal link: identity verification hub]

Regulators have recognised this. The CBUAE’s own framing of acceptable replacements includes biometric verification alongside cryptographic methods, with Emirates Face Recognition — the UAE’s national face verification service — cited in supervisory communication and industry guidance as one of the routes institutions are expected to use. Vietnam went further, and earlier: Decision 2345 requires the biometric sample to match the national identity record, which is verification against an authoritative source, not a device unlock. The regulators that moved first did not point exclusively at cryptographic tokens.

Liveness detection answers one question: is the biometric sample in front of the camera coming from a real person who is physically present right now?

That question splits into two very different attack surfaces, and a lot of buyer confusion starts here.

Presentation attacks happen in front of the camera. Someone holds up a printed photo, replays a video on a second screen, or wears a silicone mask. The sensor sees something real, but not a real person. This is the category that ISO/IEC 30107 covers, and the standard is explicit that it deals with attacks taking place at the capture device during presentation.

Injection attacks bypass the camera completely. The attacker feeds a synthetic video stream directly into the application, using a virtual camera, an emulator or a compromised device. Nothing is presented to a sensor at all, so a system that only evaluates the image content can be satisfied by a well made deepfake. These attacks sit outside the scope of ISO/IEC 30107-3, which means a PAD certificate says nothing about them.

A vendor can be strong on one and weak on the other. When you compare liveness detection software, treat these as two separate line items rather than a single score.

Beyond lab certification, look for participation in government led programmes. The DHS Science and Technology Directorate ran the Remote Identity Validation Rally through 2025, evaluating document validation, selfie to document matching and presentation attack detection at the Maryland Test Facility, with results published under anonymised system identifiers.

RIVR is useful for a specific reason: it tests with human participants under conditions closer to real deployment, and it reports both security and usability metrics side by side. That combination exposes the tradeoff most vendor decks hide. A system can accept zero attacks and still reject a meaningful share of genuine users, and RIVR makes both numbers visible at once. Willingness to be measured that publicly is itself informative.