Skip to main content

Border Control Platform Modules

The Border Control Platform is delivered as six modules that share a single biometric foundation and a single traveler data model. Together they cover the full traveler journey — from pre-registration through automated crossing — with leading biometric matching orchestrated across pre-border, border post, land border, and automated crossing workflows.

End-to-end view​

Each module owns a piece of the flow:

  • Pre-registration — Pre-Enrollment Toolkit and Kiosk & PC Enrollment Toolkit let travelers register from home or at on-site kiosks, ahead of the border. The traveler captures their own document and biometrics, and the system issues a QR / DTC credential for fast-lane processing.
  • Registration & authentication at the border — Border Post Module is the officer workstation at the staffed counter; the Mobile Field Biometric Toolkit extends the same officer-led capture and identification to handheld devices for land borders and field operations.
  • Matching & data foundation — Border Control Core sits at the center: ABIS matching engine + biometric and traveler data repository. Every module reads from and writes to Core.
  • Operational intelligence — Traveler Management Module provides the person-centric repository and officer-facing UI on top of Core: persistent traveler records, encounter history (entry, exit, refusal, visa actions, field checks), journeys, dashboards, and the operational workflows that connect them.
  • Endpoint synchronization — Border Control Core distributes time-windowed identity subsets to downstream automated-crossing endpoints (such as smart corridors and eGates).

How a traveler moves through the platform​

  1. Intent — API and PNR data — the primary inputs are Advance Passenger Information (API) and PNR booking records ingested from upstream systems (airline departure control, travel authorities, visa systems). The platform normalizes these into the cluster's data model and creates a Journey linked to the traveler. Carrier manifests are accepted as a secondary input — useful operationally near departure / arrival, but API and PNR provide the richer identity and booking context.
  2. Enrollment — the traveler is enrolled through one of the available products: Pre-Enrollment Toolkit (from home), Kiosk & PC Enrollment Toolkit (on-premise kiosks), Border Post Module (officer counter), or Mobile Field Biometric Toolkit (handheld in the field).
  3. Deduplication — Border Control Core runs a biometric search before committing the record. Outcomes: new identity (credential issued), verified identity (existing record updated, credential issued), or duplicate (routed to officer adjudication via Traveler Management Module).
  4. Distribution to border sites — Border Control Core distributes time-windowed, location-scoped identity subsets to Smart Corridors, eGates, and border posts ahead of expected arrivals. Border posts receive the subset both for validation and for operational readiness — on-prem deployments can be informed in advance of the expected traffic size so they can optimize throughput, staffing, and resource allocation for the active window.
  5. Border validation — at the border point, the corridor / eGate / counter performs identity verification. Multiple entry paths are supported:
    • Face-first detection / identification — the primary mode, mimicking the Smart Corridor approach. The traveler walks up and is identified passively against the local site dataset using face biometrics. No token presentation needed.
    • QR / DTC credential — fast-lane lookup against the pre-loaded site dataset, followed by biometric confirmation.
    • Travel document — standard lane via OCR / NFC reading, followed by biometric match against the site dataset or central ABIS.
    • Other biometric modalities — fingerprint, iris, palm — used where the deployment configuration requires multi-modal verification.
  6. Encounter Registry — every interaction is recorded in the Encounter Registry inside the Traveler Management Module, linked to the traveler's Journey, with full audit trail.

Border Control Core as master matching engine​

Beyond serving as the matching backend the channel modules call into, Border Control Core also operates as the master matching engine for two important paths:

  • Escalation cases — when a channel returns a low-confidence or ambiguous result (e.g., a corridor's on-site subset doesn't yield a confident match, an eGate verification falls below the threshold, a field handheld's local 1:N hits a borderline candidate), the request is escalated to Core's full-scale matching against the central traveler database and configured galleries — beyond what the channel can resolve on its own.
  • Direct operations — when an integrator does not rely on the channel modules at all (custom client, third-party device, integration with an external system), they call Core's APIs directly for identification, verification, and enrollment. Core is the single integration point for partners and the canonical matching engine independent of any channel.

Modules​

See also​