Skip to main content

Traveler Management Module

The person-centric operational repository within the Border Control Platform. It maintains persistent traveler identity records linked to travel documents, biometrics, journey instances, and full passage history.

The module follows an event-driven architecture — every border interaction (entry, exit, refusal, visa action, field check, …) is recorded as an immutable encounter. It separates identity, documents, journeys, and encounter events, while being linked to biometric identity processing and matching in Traveler Identity Service (TIS + ABIS).

Through secure APIs and operational UI components, the module provides border officers with a complete traveler history view, decision-support context, and full traceability — forming the operational backbone of a modern border management system.

What it does

The module is organised around the Traveler Hub — the officer-facing surface that brings together every feature into a single working environment. Three operational concepts live underneath the Hub: Journeys, Encounters, and Workflows.

Traveler Hub

The officer-facing web UI on top of TIS. It surfaces Journeys, Encounters, and Workflows in a unified browser + detail view.

Current availability — interactive showcase

Traveler Hub is available today as an interactive showcase that demonstrates the intended officer experience end to end. The showcase reflects the production UX vision described on this page, with the interface aligned to the Innovatrics design system, and is offered as a hosted, self-contained demonstration environment for evaluation by border authorities and integration partners.

In this showcase form it runs as a standalone application for demonstration and stakeholder validation. Live integration with Traveler Identity Service and the other platform modules — the data flows described throughout this page — is the target architecture, delivered as part of a production deployment.

  • Traveler browser — searchable list with biometric thumbnails, risk status, and journey context; free-text + filters (status / nationality / doc type / DOB / journey); pagination scoped to officer's access permissions and border-point context
  • Traveler detail — composed profile aggregating identity data, biometrics, document scans, and full journey + encounter history; pulled live from Traveler Identity Service
  • Identity validation — side-by-side biometric vs. document comparison; data consistency checks across enrollment, document, and manifest
  • Travel-context evaluation — last travel + next travel views to support risk-based assessment before / during a border encounter
  • Dashboards — Journey Status Funnel (lifecycle progression with stuck / anomalous states), Route & Connectivity Map (geographic visualization with traffic + watchlist overlays), Traveler Demographics Explorer (distribution by nationality, age, gender, document type). Custom dashboards can be tailored to specific operational needs.

Journey

The traveler's planned and actual movement on a transport instance — flight, vessel, train, bus, or land crossing. Journeys carry route, schedule, operator, and conveyance, and link a traveler's identity to a specific trip.

A single Journey may be updated over time by multiple upstream sources (API, PNR, manifest, manual correction). Traveler Management Module presents the current normalized travel state to officers, while the underlying source snapshots remain available for audit.

Encounter

The immutable record of a border interaction. Every traveler touchpoint — entry, exit, visa action, refusal, field check, enrollment — is captured as an Encounter event. Encounters are sessions with internal events: the session represents the operational meaning (what happened, where, when), and the events capture the atomic capture / assessment / decision steps inside.

Encounters are append-only and carry full audit context — purpose, channel, source system, location, status, startedAt, and (when finalized) endedAt. Each Encounter is linked to a known Traveler at creation — identity is established by the channel beforehand (by enrollment, by border-post identification, or by other channel-level identity provisioning).

Workflows

Configurable operational workflows that drive how officers act on traveler records. The workflow logic runs on top of TIS's data so that any channel triggering the same workflow gets consistent semantics.

  • Adjudication — operator triage workspace for identity conflicts surfaced by Traveler Identity Service; every decision is audit-logged and reflected back into TIS's matching backend
  • Border Post Review — resolution mechanism for identity incidents raised at a border post (suspected duplicates, conflicting evidence, document-holder mismatches, suspicious evidence). Operators apply one of four actions: merge, split, keep separate, or mark with a reason
  • Flag traveler — officers raise flags with reasons (suspicious behavior, data inconsistency, document mismatch, custom note); flagged records surface in the shared resolve queue

See Workflows for the full catalog.

Capabilities

  • Persistent person record with linked documents, biometrics, journeys, and encounter history
  • Journey tracking from manifest ingestion through actual passage
  • Immutable encounter history with full audit context
  • Configurable, status-driven operational workflows
  • Adjudication workspace with audit-logged decisions
  • Risk levels for officer triage
  • Traveler browser, detail, validation, and dashboard UIs in Traveler Hub
  • Live data pulled from Traveler Identity Service (no duplicate identity store)

Components we provide

  • Traveler Hub — operator-facing web application
  • Operational APIs — for travelers, documents, journeys, encounters, and workflow actions
  • Configurable workflows — status transitions, adjudication queue, flag reasons, risk-level model
  • Default dashboards — Journey Status Funnel, Route & Connectivity Map, Traveler Demographics Explorer; custom dashboards per deployment

Limitations

  • Runs on top of Traveler Identity Service. Traveler Management Module consumes TIS's matching, deduplication, and biometric data; it does not perform biometric matching itself.
  • Operator-facing, not traveler-facing. Traveler-facing pre-enrollment is delivered by the Pre-Enrollment Toolkit and Kiosk & PC Enrollment Toolkit.
  • Aggregates encounter events; does not capture them. Encounter capture depends on the channel modules (Border Post, Mobile Field, corridor / eGate) submitting events.

See also