Skip to main content

Data Model

Traveler Identity Service is the system of record for the cluster. Consuming applications (enrollment products, Smart Corridor, eGate, external integrations) reference the same Traveler, Document, Journey, and Encounter entities — no application-specific identity model.

The traveler representation is biometric-agnostic at the interface level: entities reference biometric records, they do not embed biometric processing logic. See Biometrics via Traveler Identity Service for the matching contract.

Draft of a Model​

Traveler
├── Biographic                      (1:1)
├── Demographics                    (1:1)
├── Applicant / EnrollmentProfile   (0:1 or 1:N — domain decision)
├── Document                        (0:N)
│   ├── Authenticity                (0:1)
│   └── DocumentBiometricModalities (0:N)
├── Encounter                       (0:N)
│   └── EncounterEvent              (0:N)
├── Journey                         (0:N)
│   ├── JourneySourceSnapshot       (1:N)
│   └── JourneyRisk                 (0:N)
├── TravelerRisk                    (0:N)
└── CapturedBiometricModalities     (0:N)

The four root entities developers will most often work with each have their own page. Risk and modality sub-entities are referenced where relevant; their detailed schemas will be published as those capabilities ship.

Entities​

  • Traveler — definitive identity entity, root of the model
  • Document — official travel or identity documents linked to a traveler
  • Journey — planned or actual movement on a transport instance, with its JourneySourceSnapshot audit lineage
  • Encounter — recorded interaction session at a border touchpoint, with its EncounterEvent atomic steps

Standards Alignment​

The model adopts the field semantics of established border-control identity standards so integrators familiar with them can map directly:

  • Primary — EES (Entry/Exit System), ETIAS, ICAO Doc 9303
  • Secondary — VIS (Visa Information System), SIS II (Schengen Information System), eu-LISA interoperability framework

Field optionality reflects the minimum required for system integration. Individual deployments may enforce stricter requirements via configuration.

Domain separation​

Border Control owns operational identity for border processes — the Traveler (operational identity used in border processes) and the Encounter (a time-bound snapshot of a traveler interaction, e.g. enrollment or crossing). These must not be conflated with the identity and enrollment concepts of adjacent civil-identity domains: an external enrollment snapshot and an Encounter are conceptually similar time-based records but belong to different domains and must not be directly mapped.

See also​