Match-on-Card Technology

<\/script>\n
'; }, get iframeSnippet() { const domain = '{ SITE_DOMAIN }'; const type = '{ embed_type }'; const slug = '{ embed_slug }'; return ''; }, get activeSnippet() { return this.method === 'script' ? this.scriptSnippet : this.iframeSnippet; }, copySnippet() { navigator.clipboard.writeText(this.activeSnippet).then(() => { this.copied = true; setTimeout(() => { this.copied = false; }, 2000); }); } }" @keydown.escape.window="open = false" @click.outside="open = false">

Embed This Widget

Theme


      
    

Widget powered by . Free, no account required.

How match-on-card biometric verification works: template storage, matching algorithms, FAR/FRR performance, and privacy benefits.

| 4 min read

Match-on-Card Technology

Match-on-Card (MoC) is the architectural principle that both the biometric template storage and the comparison algorithm reside inside the card's secure element. A live fingerprint image is captured by the sensor, processed on the card, and the card returns only a Boolean match result. The raw biometric data — both the enrolled template and the live scan — never crosses the card boundary in plaintext.

This contrasts with Match-on-Host (where the card transmits a template to the terminal for comparison) and Match-on-Server (centralised biometric database) architectures.

Template Storage

Fingerprint templates in MoC implementations typically use one of two formats:

Format Standard Description
Minutiae template ISO/IEC 19794-2 Encoded ridge endings and bifurcations (type, x, y, θ)
Finger image ISO/IEC 19794-4 Compressed grayscale image (JPEG2000 / WSQ)
Proprietary compact Vendor-specific Optimised for on-card storage and comparison

A minutiae template for one finger typically occupies 500–2,000 bytes in ISO 19794-2 format. Cards store 1–2 fingers (some store up to 4) in EEPROM or Flash memory protected by the secure element access control.

ISO/IEC 19794-2 Minutiae Record (simplified):
┌──────────────────────────────────────────────────────┐
│ Format ID (4B) │ Version (4B) │ Total Length (4B)    │
│ Width (2B) │ Height (2B) │ Resolution X/Y (2B each) │
│ Finger count (1B) │ [Finger View records...]         │
│   Finger position │ View count │ Quality              │
│   Minutia count (1B)                                 │
│   [Minutia: type(2b) | X(14b) | Y(14b) | θ(8b)](×N) │
└──────────────────────────────────────────────────────┘

On-Card Comparison Algorithm

The matching algorithm must run within severe constraints: < 3 mW power budget, < 100 KB RAM, and produce a result within 300–500 ms to remain inside the ISO 14443 activation window for contactless use.

Minutiae-Based Matching (Most Common)

  1. Feature extraction: Convert the live sensor image to a minutiae set.
  2. Local structure generation: For each minutia, encode the spatial relationship to its K nearest neighbours as a rotation-invariant descriptor.
  3. Matching: Align probe and gallery (enrolled) minutiae sets using a combination of geometric hashing and score accumulation.
  4. Threshold comparison: If the alignment score exceeds the configured threshold τ, return match; otherwise return fail.

The threshold τ controls the FAR/FRR trade-off:

τ (lower = stricter) FAR FRR Use Case
High threshold < 0.0001% ~3–5% Government ID, high security
Medium threshold < 0.001% ~1–2% EMV payment (typical)
Low threshold < 0.01% ~0.5% Convenience-focused

ECC-Enhanced Templates (Privacy-Preserving)

Advanced MoC implementations combine biometric matching with ECC key binding using fuzzy commitment schemes:

  1. At enrolment: encode a random ECC private key k with the template using an error- correcting code tolerant of typical biometric variation.
  2. At match time: the live scan corrects the codeword and recovers k if and only if the match succeeds.
  3. k signs the transaction challenge — if the biometric match fails, k is not recoverable and no signature is produced.

This approach provides cryptographic proof of biometric match without storing the template in recoverable form.

Security Properties

Property MoC Match-on-Host Match-on-Server
Template at rest In secure element On card, read by host In database
Template in transit Never extracted Transmitted to host Transmitted to server
Revocability Card destruction or re-enrolment Card-level Database update
Privacy risk on compromise Card only Card + host RAM All enrolled users
Common Criteria evaluation EAL 4+/5+ Lower N/A

FAR and FRR in Practice

FAR (False Accept Rate) and FRR (False Reject Rate) are measured per ISO/IEC 19795-1 using large multivendor datasets. For EMV biometric certification, Mastercard and Visa require:

  • FAR ≤ 0.001% (false accept no more than 1 in 100,000 impostors)
  • FRR ≤ 3% (true user rejected no more than 3 times in 100)

Independent evaluation is performed by accredited biometric test laboratories using Test Method ISO/IEC 19795-2 (scenario evaluation) with a population ≥ 500 subjects.

For the payment integration context, see Biometric Payment Cards. For the broader card market, see Biometric Smart Cards Overview.

Frequently Asked Questions

Our guides cover a range of experience levels. Getting Started guides introduce smart card fundamentals. Security guides address Common Criteria certification and key management. Programming guides target developers working with APDU commands, JavaCard applets, and GlobalPlatform card management.