Architecture Overview
Traveler Identity Service (TIS) is built in two tiers: a platform layer that manages traveler identity, enrollment orchestration, and encounter handling, and a biometric backend (ABIS) that executes biometric matching and template management. The platform layer routes matching requests to the biometric backend and processes the returned results — it does not execute biometric matching directly.
Integrators interact with the platform layer's REST API; the biometric backend is not directly accessible.
The diagram shows the runtime composition: enrollment modules (Kiosk / Mobile / Web) feed the Enrollment Service, which submits to the Traveler Identity Service (the cluster middleware). TIS uses the Biometrics Record Service (ABIS) directly for both enrollment and matching — it is the sole, embedded matching engine, with no external ABIS dependency. An External Integration Service connects upstream systems into TIS. Subset distribution to the Smart Corridor, eGate, and other consumers flows through the Data Synchronisation Service. Encounter records — modeled as sessions of fine-grained capture / assessment / decision events — persist via the Repository Module; identity resolution can complete asynchronously, so an Encounter can be created before its Traveler is known and linked later.
Platform layer
Integration service
Primary entry point for all external systems. Exposes a REST API following OpenAPI Specification 3.0 with OAuth authentication, and a GraphQL interface for internal service communication. Enrollment products, third-party systems (airline departure control systems, passenger manifest feeds), and border authority integrations all connect through this service.
Data service
Owns the authoritative traveler identity store. Provides a GraphQL interface consumed by the integration service and exposes the persistent data layer to all platform services. Traveler records, travel documents, journey data, and encounter history are managed by this service and persisted to the underlying SQL database.
Synchronization service
Distributes time-windowed, location-scoped identity subsets from the central database to individual border sites — corridors, eGates, border posts, and other site-level applications consume the relevant subset for fast local matching.
Deduplication
The biometric integrity gate on enrollment ingestion. When a new traveler record is submitted, their biometric templates are searched 1:N against the existing traveler database. Outcomes:
| Outcome | Meaning | Result |
|---|---|---|
| New identity | No biometric match found | New traveler record created; enrollment credential issued |
| Verified identity | Match found; data fields consistent | Existing record updated; enrollment credential issued |
| Duplicate requiring adjudication | Match found; data fields inconsistent | Record flagged; routed to officer for manual review |
Resolutions can be Merge, Update, Reject, or No Match, with deployment-specific configuration. Hit lists are persisted for audit and traceability. Enrollment credentials (QR, DTC) are issued only after a successful new or verified outcome.
External integration
The cluster's interface to devices and external data sources. Two responsibilities:
- Device Communication Adapter — REST API for eGates, kiosks, and other border devices. Devices send events ("traveler passed / denied") and request decisions ("can this traveler pass?"); the adapter translates device-specific payloads into internal domain operations.
- Data Feed Component — consumes manifests, API/PNR feeds, external watchlists, and partner systems. Cleans, normalizes, and enriches the data before pushing it into Traveler Identity Service.
Authorization service
API access control for external integrators. The new capability is authorization, not authentication — authentication is reused from the existing organizational identity platform. The authorization layer (RBAC as the first model) restricts external access to explicitly approved endpoints and operations, protects internal-only endpoints from external consumers, and is policy-evaluated through Open Policy Agent (OPA). Human-UI role administration and business-workflow authorization inside consuming applications are out of scope for this layer.
Admin, adjudication, trust and risk
This area in the diagram covers the operator-facing and analytical capabilities that sit on top of TIS:
- Adjudication — operator queues for resolving deduplication conflicts and exception paths (Merge, Update, Reject, No Match)
- Trust assessment — normalized trust level based on identity attributes (civil identity, enrollment state, citizenship, known lists)
- Risk assessment — normalized risk level based on behavioral patterns (encounter history, movement over time). Reported independently from trust
- Dashboard — operational visibility for supervisors and analysts (demographics, journey lifecycle, route map)
ABIS biometric backend
Fast service
The biometric API consumed by the platform layer. Exposes:
- Read operations (Identify, Verify, Get) — biometric search and retrieval against the gallery
- Write operations (Create, Update, Delete) — template ingestion and record management
Extractor
Performs biometric feature extraction from raw images, producing face, fingerprint, iris, and palm templates used by the matcher. Includes per-modality quality assessment — ICAO facial image compliance and NFIQ-based fingerprint quality scoring.
Matcher
The multimodal biometric matching engine. Searches and compares templates across all enrolled modalities: face, fingerprints, palmprints, and irises. Deployed as a horizontally scalable cluster, coordinated by ZooKeeper, backed by Apache Ignite distributed in-memory caches for sub-second search latency on large galleries.
Image service
Manages storage and retrieval of raw biometric images, independent of the biometric template store managed by the matcher.
See also
- Biometrics via Traveler Identity Service — TIS as the single integration point and the matching contract for integrators
- Galleries & Watchlists — gallery model: internal vs integrator-defined, single vs multi-membership
- TIS deployment — deployment topology, HA, supported infrastructure
- Data Model — entities managed by the platform layer