Skip to main content

Core Service & ABIS

The Border Control Core Service is the cluster's central orchestrator and biometric platform. It combines a domain-aware service layer — owning the Traveler, Document, Journey, and Encounter entities, orchestrating biometric operations, and producing trust and risk signals — with a multimodal ABIS matching backend that performs fast 1:N identification and 1:1 verification across face, fingerprint (including contactless), iris, and palm.

Why this exists as one service: every other component in the cluster (enrollment toolkits, Identify & Verify App, Traveler Hub, Smart Corridor, eGate) reads from and writes to this service. Centralizing identity and matching here is what lets integrators consume one stable contract instead of wiring directly to a matching engine and a separate identity store.

Core is replaceable — but at a cost

Each Border Control product (Identify & Verify App, Enrollment Border Post, the Enrollment Framework channels) can be deployed with or without Border Control Core. Integrators who already operate their own middleware can wire individual products into it, and the products will function.

What's lost without Core is the value of the shared foundation: one Traveler model across channels, a consistent Encounter history, deduplication that spans every enrollment channel, normalized trust and risk signals, and a single integration contract for partners. The individual products keep working; the cross-channel intelligence does not.

Capabilities​

  • Multimodal matching — native processing for face, fingerprint (slap and contactless), palm, iris, and DNA (images and templates), with fused multimodal scoring
  • Document handling — passport (ordinary, diplomatic), national ID, visa, residence permit, and other travel documents; OCR + MRZ + NFC chip reading with authenticity checks. Documents are stored as records linked to Travelers — see the Document entity for the schema
  • Identification (1:N) and Verification (1:1) — identification queries the full database or logically isolated galleries
  • Encounter handling — every interaction across channels is recorded as a session of events with shared semantics. Encounters can be created before identity is resolved and linked to a Traveler later (shadow-identity pattern)
  • Trust assessment — normalized trust level per traveler based on identity attributes (civil identity, enrollment state, citizenship, known lists)
  • Risk assessment — normalized risk level per traveler based on behavior (encounter history, movement patterns). Reported independently from trust
  • Configurable matching threshold — parameters tuned during deployment, including candidate-count limiters
  • Stateless / Semi-stateful / Stateful matching modes — see Biometric Functions
  • Audit trails — permanent persistence of resolution actions and resolved hitlists for governance and traceability
  • Galleries — logical isolation of records to support border control zone environments; targeted identifications limit search scope to specific galleries to reduce latency and optimize throughput
  • API access control for external integrators — authorization layer (RBAC) restricting external access to explicitly approved endpoints and operations; authentication is reused from the existing organizational identity platform
  • Designed for large scale — robust architecture suitable for national-level deployments
  • Awarded / certified algorithms — consistently top-ranked in NIST benchmarks across fingerprint (MINEX III, PFT III), face (FRTE), and iris (IREX)
  • Hardware and platform agnostic — design philosophy focused on interoperability to avoid vendor lock-in

Operator workflows​

The Core service includes operator workflows for managing identity exceptions and ambiguous matches, surfaced through the bundled Supervisor & Audit GUI:

  • Workflows — merging, splitting, and updating identities, with auditable events linked to affected records and travelers
  • Hitlists — persisted relations between biometric records flagged for exception paths (Duplicate, Mismatched); transition from Unresolved to Resolved through adjudication
  • Resolve queue — configurable queues with actions (Merge, Update, Reject, No Match) defined by deployment-specific metatypes
  • Supervisor & Audit GUI — biometric record browser with configurable columns and saved filters; record detail with direct 1:1 matching and on-demand identification; biometric audit (split-screen) with side-by-side probe and candidate views; high-resolution fingerprint adjudicator tools

For a traveler-centric officer interface that complements the audit GUI, see Traveler Management.

Inside this product​

  • Biometric Functions — multimodal support, scoring hierarchy, matching modes
  • Deployment — cluster topology, HA, supported infrastructure, databases

See also​