Workflow level
If a policy sequentially requests face, fingerprint or iris, this is multi-modal workflow orchestration. It is not automatically score-level or feature-level fusion.
MULTI-BIOMETRIC
Multi-biometrics — verification, identification and assurance
Face, fingerprint, iris, palmprint and palm vascular are modeled as distinct modalities selected by device, quality, risk and policy; score-level fusion is not claimed without implementation evidence.
SOURCEAuthoritative / document
CAPTUREDevice / SDK
VERIFYDocument + biometric
ASSUREPolicy + risk
DECIDEClaims / status
EVIDENCEAudit / trace
Technical basisSOURCE-BACKED
SourceCheckID CheckID + ISO standards register
StandardISO/IEC 19795 + modality standards
VersionCurrent published edition per standard
ApplicabilityModality-specific; implementation dependent
EvidenceProcess types + standards mapping + certificate scope
TECHNICAL REFERENCE
Multi-biometric: multi-modality orchestration is not automatically fusion
Availability → modality selection → quality → per-modality result → policy combination
Feature-level fusion
Claimed only when an engine combines feature representations before matching and a primary source confirms it.
Score-level fusion
Claimed only when matcher scores are normalized/combined through a documented rule or model.
Decision-level fusion
Claimed only when multiple modality decisions are combined into a policy-defined decision.
Fallback
An unavailable sensor or low-quality sample may lead to an alternate modality only when policy/source supports that behavior. Multiple available modalities do not imply automatic fallback.
Evidence
Evidence should preserve modality, capture/source, result and combination policy so an auditor knows which modalities contributed rather than receiving only “multibiometric passed”.
BIOMETRIC ARCHITECTURE
Modality, operation, quality, matching and performance are separate layers
Face, fingerprint, iris, palmprint and palm vascular do not share one operating envelope. “Supported/tested” is used only when matching engine/device/profile evidence exists.
| Dimension | Face | Fingerprint | Iris | Palm |
|---|---|---|---|---|
| Capture concern | Pose/illumination/occlusion/live context | Sensor/profile/segmentation/finger configuration | Focus/segmentation/occlusion/single-both eye | Surface ROI or vascular sensor path |
| Operation | 1:1 / 1:N where supported | Enroll / 1:1 / 1:N / dedup where supported | Enroll / 1:1 / 1:N where supported | Actual product profile |
| Performance proof | Test-context bound | Test-context bound | Test-context bound | Test-context bound |
Operating profile
Every claim about devices, thresholds, capture conditions or model versions maps to test/profile evidence; a vendor datasheet is not Mobile-ID compatibility evidence.
Verification vs identification
1:1 compares a probe with a known reference; 1:N searches a gallery. FMR/FNMR do not replace FPIR/FNIR and gallery context.
PAD vs matching
PAD measures presentation-attack handling; matching measures recognition/similarity. APCER/BPCER are not face-matching accuracy metrics.
Multi-biometric
Fusion is used only when feature-, score- or decision-level fusion is source-backed; sequential modality workflows are not automatically fusion.