ICTS Europe Systems

ICTS Europe Systems
System overview and implementation guide v2.2

ICTS Europe Systems TravelDoc Page 2 of 28
Disclaimer
The information contained within this document is confidential and provided by ICTS Europe Systems as a service to its
shareholders, customers, employees and other interested persons. You should assume that everything you see or read in this
document is copyrighted and may not be used except with the express written permission of ICTS Europe Systems. ICTS Europe
Systems neither warrants nor represents that your use of materials contained within this document will not infringe rights of
third parties not owned by or affiliated with ICTS Europe Systems.
Privacy Information
This document may contain information of a sensitive nature. This information should not be given to persons other than those
involved in the project or persons who will become involved during the lifecycle.
Version History
Version Date Author Description
Draft Will Rosie Initial Draft
2.0 07/12/15 Yochai Legum Baseline version
2.1 04/01/16 Yochai Legum Updated Diagram
2.2 21/01/16 Karl Grützner Updated pseudo code example

Table of Contents
1. Introduction................................................................................................................................................................................ 5
1.1. Overview .................................................................................................................................................................................. 5
1.2. Features and Benefits .............................................................................................................................................................. 5
1.3. How Does TravelDoc Work? .................................................................................................................................................... 6
1.4. TravelDoc Products and Services ............................................................................................................................................. 6
1.4.1. TravelDoc Integrated Service ........................................................................................................................................... 6
1.4.2. TravelDoc Library .............................................................................................................................................................. 7
1.4.3. TravelDoc Website ........................................................................................................................................................... 7
1.4.4. TravelDoc Widget ............................................................................................................................................................. 9
1.4.5. TravelDoc Reports .......................................................................................................................................................... 10
1.5. Can TravelDoc be customised? .............................................................................................................................................. 11
1.6. Who Manages the Travel Rules? ........................................................................................................................................... 11
1.7. Does user feedback have an influence on TravelDoc? .......................................................................................................... 11
1.8. TravelDoc Environment ......................................................................................................................................................... 11
1.9. TravelDoc Architecture .......................................................................................................................................................... 12
1.10. Data Privacy ......................................................................................................................................................................... 13
2. TravelDoc API ........................................................................................................................................................................... 14
2.1. General Information .............................................................................................................................................................. 14
2.1.1. Accessing the TravelDoc Integrated service ................................................................................................................... 14
2.1.2. Testing Application ......................................................................................................................................................... 15
2.1.3. Testing / Live Environments ........................................................................................................................................... 16
2.1.4. User Credentials ............................................................................................................................................................. 16
2.1.5. Version Upgrades ........................................................................................................................................................... 16
2.1.6. Communication with the rules team .............................................................................................................................. 16
2.2. Authentication ....................................................................................................................................................................... 17
2.3. TravelDoc Request ................................................................................................................................................................. 18
2.4. TravelDoc Response ............................................................................................................................................................... 19
2.4.1. Status .............................................................................................................................................................................. 19
2.4.2. Message Codes ............................................................................................................................................................... 20
2.4.1. Suggested Documents .................................................................................................................................................... 21
2.4.2. Message Levels ............................................................................................................................................................... 21
2.5. Feedback ................................................................................................................................................................................ 21
2.6. Testing.................................................................................................................................................................................... 22
3. Implementation Scenarios ....................................................................................................................................................... 23
3.1. Reservation and Booking ....................................................................................................................................................... 23

3.2. Web Check-in ......................................................................................................................................................................... 24
3.3. Counter check-in/Assisted bag-drop ..................................................................................................................................... 25
3.4. Self-service check-in/Bag-drop .............................................................................................................................................. 26
3.5. Departure Gate ...................................................................................................................................................................... 27
4. Support ..................................................................................................................................................................................... 28
4.1. Technical Support .................................................................................................................................................................. 28
4.2. Operational Support .............................................................................................................................................................. 28

1. Introduction
1.1. Overview
TravelDoc is the most advanced automated document checking system available today. Many major airlines around the
world trust TravelDoc to deliver comprehensive, robust automated document checks for over 100 million passengers
every year. Each and every TravelDoc client have seen the virtual elimination of penalty notices issued against them for
carrying incorrectly documented passengers, resulting in significant, long lasting cost savings.
As a suite of products and services, TravelDoc is an all inclusive automated document checking solution, with each of the
TravelDoc products being designed to solve a specific problem faced by customers. TravelDoc can be integrated into a
wide variety of customer systems, such as self-service kiosks, reservations and departure control systems, customer
websites and more.
1.2. Features and Benefits

Unique ability to customise service per client
TravelDoc is the only ADC (Automated Document Checks) solution that allows clients the ability to customise its
behaviour to meet their exact business needs.
Can be integrated anywhere

TravelDoc offers a web based API (Application Programming Interface) that affords customers the ability to
directly integrate TravelDoc into any system or application they wish.
Unmatched Business Intelligence

Comprehensive statistical reports and audit capabilities are built into TravelDoc from the ground up giving
customers an in-depth insight into the day to day operation.
Ability to give direct feedback

TravelDoc gives customers the ability to send feedback directly to the TravelDoc rules team. All feedback is
responded to within one working day.
Simple and easy to understand

TravelDoc avoids the use of complex terms and baffling terminology by ensuring that system messages and texts
are written using simple, concise language.
Immediate updates from independent sources

TravelDoc is maintained by a dedicated team of analysts who are in constant contact with immigration
departments, embassies and consulates around the world. TravelDoc does not buy or lease information from any
other supplier. Changes to immigration regulations are updated immediately in TravelDoc. No waiting for weekly
or monthly updates.
24 x 7 x 365 support
Technical support is provided 24 x 7 x 365 by a team of specialists and TravelDoc comes with strict SLA.
1.3. How Does TravelDoc Work?

The TravelDoc system applies international travel rules to any itinerary and returns an instant result.
Customers submit passengers’ itinerary and travel documents to the TravelDoc service. The TravelDoc engine then applies
the most recent TravelDoc rules and returns a result within 100 milliseconds.
The result returned by TravelDoc has an overall passenger status of Go (Board), No Go (Do Not Board) or Conditional
(Passenger may be boarded if certain conditions are met). Passenger data can be submitted on an individual, passenger-
by-passenger basis, or in batches of multiple passengers (such as families, groups or entire flights).
1.4. TravelDoc Products and Services

TravelDoc consists of several products that work together to provide a comprehensive solution for any documentation
verification scenario. The sections below offer a brief overview of the various products.
1.4.1. TravelDoc Integrated Service

The TravelDoc Integrated service is the main offering for system integrators and for airlines who wish to connect to TravelDoc
directly. As a platform agnostic web-service, TravelDoc Integrated provides a simple yet powerful way of providing automated
document checks to a wide range of systems.
See Chapter 2 – TravelDoc API For more information.

1.4.2. TravelDoc Library

The TravelDoc Library offers a complete overview of immigration, health and customs travel requirements. It is intended for use
by airline agents to further evaluate passengers who have received a conditional or no-go response from the Integrated Service.
It provides an interface to show all potentially applicable rules to the passenger’s situation. It can be accessed via a web interface
or as an app on Android devices.
1.4.3. TravelDoc Website

During the passenger booking and reservation stages, TravelDoc allows carriers to offer their customers a quick and easy way to
check their documentation requirements.
The TravelDoc Website allows users to perform a simple check of their travel documentation requirements. Customers enter
minimal information into the website (destinations and dates of travel, nationality and expiry date) and in response receive a
simple, easy to understand message that details whether they can travel or not.
The TravelDoc Website is intended as a tool for passengers to self-check the requirements for upcoming journeys, which allows
any issues with documentation to be resolved well before their flight. The website can be customised to use the carrier’s own
branding and work flow. A generic version of the website is available at www.traveldoc.aero.
To simplify the process even further, the TravelDoc website can accept URL parameters to pre-fill the information required to
perform a TravelDoc check. Customers may include a hyperlink in a passengers booking confirmation email that would link the
passenger directly to the TravelDoc website and allow them to perform a TravelDoc check without entering any additional
information. An example URL is as follows,
https://www.traveldoc.aero/?S=1|HKG|CDG|2015-03-17&S=2|CDG|AMS|2015-03-17%2010%3A19&S=3|AMS|HKG|2015-03-
17%2012&3A10|N&D=1|CHN|CHN|2018-12-31#input
For more information about TravelDoc website customisation please contact your TravelDoc account manager.
1.4.4. TravelDoc Widget

A recent addition to the TravelDoc suite of products is the TravelDoc Widget, a small, customisable widget that can be added to
any webpage with a few lines of code. The widget gives passenger s the quickest way to check for their visa requirement needs
and links directly to the full TravelDoc website (https://www.traveldoc.aero/Info/Widget).
1.4.5. TravelDoc Reports

The TravelDoc Reports website provides customers with common business reports about the operation of TravelDoc services, as
well as access to records of all TravelDoc checks for auditing purposes.
1.5. Can TravelDoc be customised?

The results returned by TravelDoc can be customised depending on a wide variety of factors. For example a check-in agent
may only require a Go/No Go result where as a passenger query from a customer website may include additional
information such as the details of local embassies where they can obtain a visa etc.
The ability to customise rules has been present in TravelDoc since its very first release and is a core feature unmatched by
any competing product. All customised rules can be implemented with minimal effort by the TravelDoc support team.
Customised TravelDoc rules can be based on factors such as the level of detail required, the application making the
TravelDoc check, the departure or arrival ports the passenger is flying to, the types of documents the passenger is using to
travel and many more.
1.6. Who Manages the Travel Rules?

The travel rules used in the system are written specifically for TravelDoc. The rules are a completely original piece of work
created by the TravelDoc rules team for the sole use of the TravelDoc system. ICTS does not buy or copy information from
other databases. This ensures complete control over the responses for customers and allows the development of unique
features and customisation.
ICTS Europe Systems' TravelDoc Rules team is in regular contact with immigration and border control authorities and
monitors all relevant changes to travel regulations. The TravelDoc Rules team transform the source information to a set of
rules that are simple and easy-to-understand, avoiding complex terms and ambiguous information.
All members of the TravelDoc Rules team have extensive field experience working in an airport environment and dealing
first-hand with travel documentation issues.
1.7. Does user feedback have an influence on TravelDoc?
Absolutely. The TravelDoc team place a great deal of emphasis on working in close co-operation with customers in order to
ensure TravelDoc remains the most simple and effective document checking solution on the market.
Included in the TravelDoc integrated API, the TravelDoc Library website and Android app are direct feedback options that allow
users to give direct feedback to the TravelDoc team about specific rules and all feedback received is responded to with one
working day.
The team also works closely with ICTS Europe’s airport personnel; direct feedback from thousands of ground staff allows
the team to continually improve and enhance the TravelDoc system.
1.8. TravelDoc Environment

TravelDoc is hosted on Azure – the Microsoft Cloud platform. Microsoft Azure is an advanced cloud infrastructure platform that
includes a variety of enterprise-grade features.
Azure meets a broad range of international and industry-specific compliance standards, such as ISO 27001, HIPAA, FedRAMP,
SOC 1 and SOC 2, as well as country-specific standards including Australia IRAP, UK G-Cloud and Singapore MTCS. Microsoft was
also the first to adopt the uniform international code of practice for cloud privacy, ISO/IEC 27018, which governs the processing
of personal information by cloud service providers.
Rigorous third-party audits, such as by the British Standards Institute, verify Azure's adherence to the strict security controls
these standards mandate.
To protect against online threats, Azure offers Microsoft Antimalware for cloud services and virtual machines. Microsoft also
employs intrusion detection, denial-of-service (DDoS) attack prevention, regular penetration testing and data analytics and
machine learning tools to help mitigate threats to the Azure platform.
TravelDoc is currently deployed on 4 Azure regions; Hong Kong, Singapore, Ireland and California. The environment within each
region is setup with full redundancy on all components. If a data centre becomes unavailable Azure Traffic Managers
automatically redirect traffic to the nearest available region.
1.9. TravelDoc Architecture

The current version of TravelDoc was created for Azure, leveraging many of the advantages of the platform. The solution uses no
traditional server machines, instead the application layer is deployed as Azure cloud services. These services have no Operating
System and do not require patching and maintenance. Cloud services can also be easily scaled up without disruption or
downtime. The database platform used in the solution is Azure SQL Database, this is a relational database-as-a-service (DBaaS)
hosted in the Azure cloud.
The system was designed in consultation with Microsoft Azure Solution Architects to ensure the service is robust, scalable, and
adheres to design best practices.
Careful planning was taken to ensure the system is always available and to mitigate the risk of service interruptions for our
customers. There is full redundancy on all components within a region and each region can be used as DR site to other regions.
The system includes a service monitor which can trigger SMS and email alerts based on a configurable rule set. For example, the
monitor can issue warnings based on unexpected traffic patterns or performance fluctuations.
The system is thoroughly stress-tested on every major release.

1.10. Data Privacy

ICTS will generally retain records of TravelDoc checks for a period of one month for auditing purposes. This can be extended up
to one year based on the needs of the customer. Customers should discuss their data retention needs with their TravelDoc
account manager.
Records of TravelDoc checks may be exclusively stored in specified geographical regions to comply with regulatory requirements.
Many properties which can be submitted for a TravelDoc check are optional, and customers may choose not to submit this
information based on regulatory requirements. However, certain fields which can contain sensitive information may still be
critical in order to determine whether a passenger may travel. TravelDoc provides various methods to allow this information to
be submitted anonymously to maintain accurate responses.
To learn more, please contact your TravelDoc account manager.

2. TravelDoc API
2.1. General Information
2.1.1. Accessing the TravelDoc Integrated service
TravelDoc Integrated is most commonly available as an XML / JSON based web-service, but is also available using EDIFACT.
To access the service, customers need five parameters:
 URL – The TravelDoc service address

 UserName – The User Name of the TravelDoc account
 Password – The password of the TravelDoc account
 ClientName – A Client Name associated with the TravelDoc account
 ConfigurationName – A valid Configuration Name for the client
These parameters will be supplied to the customer by their TravelDoc Account Manager.
2.1.2. Testing Application

ICTS provide system integrators with a simple Windows application that can be used to check how the system responds in
various scenarios.
The application provides access to the underlying request and response data which is shown in SOAP or JSON.
TravelDoc Integrated Client application is available from your account manager.

2.1.3. Testing / Live Environments

For each customer, ICTS supplies two environments by default; staging environment and a production environment. Each
environment uses different credentials. Each environment is accessed using a different URL, which is customer specific.
Access to both environments is over HTTPS (port 443) or IPsec VPN.
2.1.4. User Credentials

User credentials issued by ICTS may be subject to change if ICTS believe that they have been compromised and are being
used by third parties. Customers should ensure that their user credentials are stored in a configurable way to allow easy
updating of credentials if and when required.
2.1.5. Version Upgrades

TravelDoc Integrated is constantly being developed and enhanced with new features and performance improvements.
Each upgrade is designed as far as possible to be backward compatible with previous versions of the service so as to
ensure minimal disruption for customers. When a new version which is not backward compatible with earlier versions is
released, the major version number will be incremented. Endpoints will be accessible using a defined URL structure.
For example, http://......../integrated/1.1/..... or , http://......../integrated/1.2/.....
As a result customers will be required to change the URL they use to access the TravelDoc service to continue using the
latest version. Customers should ensure that the URL for TravelDoc is stored in a configurable way to allow easy upgrading
of the system.
2.1.6. Communication with the rules team
Customers are encouraged to contact the Rules team regarding any rules which are unclear, who will provide a response within
1 working day. Customers should designate a contact person to receive responses to these queries.
2.2. Authentication
Applications connecting to the TravelDoc service must first authenticate using the GetSession method which will return a Session
GUID. The session GUID is used for checking passengers without passing credentials on each call. Sessions do not have a set
expiry time but integrators should add code for renewing expired sessions when needed (see example below).
On the Client side, a SessionGUID represents a specific configuration of the service. The session’s service configuration is
determined by the ClientName, and ConfigurationName parameters of the GetSession method.
Client Name is most commonly the carrier name but can also be a ground handler or travel agency.
Configuration Name represents a specific implementation such as Reservation, Web Check-In, Mobile Check-In, Self-Service
Kiosk, Counter Check-In, Departure Gate, etc.
The Client-Configuration name is used to track the traffic of different clients and implementations within a single account. This
allows users of the TravelDoc Reports website to monitor the performance of each implementation separately.
Specific Client-Configuration name can also be used for customised responses. For example; an airline may request to add an
operational message that appears on certain routes under specific conditions or change the wording of existing messages. The
logic of the responses can also be modified, for example; a query with the same details may return a Conditional (Amber) status
in a counter Check-In implementation but a Do Not Board (Red) status in a Self-Service Kiosk implementation.
Client-Configuration names are created upon request by the TravelDoc account manager.
The pseudo code below shows a suggested implementation of the CheckPassengers method call with session handling.
// Method for checking an array of passengers
public List<Passenger> CheckPassengers(Passenger[] passengers)
{
try
{
// Call the CheckPassengers method passing in the stored session GUID,
// avoid sending service credentials on each call
return Service.CheckPassengers(this.sessionGUID, passengers);
}
catch (FaultException ex)
{
If (ex.Message == “Invalid session identifier submitted, please login again to get a new session identifier”)
{
try // this Session GUID is invalid, let’s get a new one
{
// Pass in the service credentials and get a new session GUID
this.sessionGUID = Service.GetSession(this.UserName, this.Password, this.ClientName, this.ConfigurationName);
// Reprocess the passengers by recursively calling this method
return this.CheckPassengers(passengers);
// Add code to prevent an infinite loop occurring
}
catch (Exception exInner)
{
// add error handling
}
}
}
catch (Exception ex)
{
// add error handling
}
}
2.3. TravelDoc Request

TravelDoc submissions can consist of a single Passenger object, or a Passengers object containing multiple Passenger
objects. Each Passenger object must contain one or more Document objects, and one or more Segment objects. For
detailed information on the structure and content of objects and properties, please refer to the TravelDoc Integrated API
reference guide.
It is recommended that wherever possible, the information submitted in the Document or Segment objects is captured by
automated means to avoid input error (for example, by scanning the machine readable zone of a travel document or the
barcode of a boarding pass). Where this information is entered manually, it is recommended that customers appropriately
validate entered data before allowing the user to complete the data entry process.
Customers are encouraged to submit as much information as possible about a passenger’s future itinerary as Segment
objects to ensure the most accurate response. However, customers should consider how negative indications relating to
future travel will be handled within their processes.
Structure of TravelDoc submission (some properties removed for clarity)
To simplify auditing, it is strongly recommended that customers ensure that each passenger is assigned an
AirlinePAXReference property which is unique to each passenger. However, the same AirlinePAXReference should be used
if the same passenger is submitted to TravelDoc multiple times. Customers should ensure at least that the combination of
AirlinePAXReference and PNR is unique to the passenger.
2.4. TravelDoc Response
The response from the TravelDoc check will include an overall status for the passenger (OK / Not OK / Conditional) and then
further messages detailing any problems the passenger may have. These messages are assigned to either the passengers
documents (such as a passport not having the correct validity) or to the passengers segment (such as a passenger requiring a visa
for a destination). Furthermore, messages are displayed in order of importance with Level 1 messages being of high importance
and Level 2 messages being of lower importance.
Structure of TravelDoc response (some properties removed for clarity)
2.4.1. Status
TravelDoc Status indicators have three states:
 Green – OK TO BORAD – Indicating that the passenger is in possession of the correct documentation to travel.
 Red – DO NOT BORAD – Indicating that there is a problem with part of the passenger’s itinerary and further action
is required.
 Amber – CONDITIONAL TO BORAD – Indicating that a particular condition needs to be verified manually in order to
determine whether the condition would prevent a passenger from travelling.
TravelDoc provides 3 different Status results within the response: PassengerStatus, SegmentStatus and MessageStatus. Each
Status type may be used in different circumstances.
 PassengerStatus indicates the overall status of the passenger across all Flight Segments. Integrators should note that a
passenger may still be permitted to travel even if the passenger status is red, depending on the status of individual
Segments and the business rules of the operating carrier.
 SegmentStatus indicates the overall status of an individual flight segment. Customers should consider under what
circumstances they may permit a passenger to travel if a future SegmentStatus is Red but the current flight segment is
Green.
 MessageStatus indicates the status of an individual message.
TravelDoc Status response structure
2.4.2. Message Codes
Each TravelDoc message includes a numeric code which represents a scenario “type”. For example; 1001 means “Visa required”
and 1204 means “Proof of onward travel is required”.
Integrators can use Message Codes to customise the behaviour of client applications and create specific flows for certain
Message Code responses.
TravelDoc currently supports over 50 scenario types with specific codes. See the TravelDoc API documentation for a complete
listing of message codes.
2.4.1. Suggested Documents
Certain messages include a SuggestedDocuments object, which consists of a list of DocumentTypes, which could be used to
allow the passenger to travel.
2.4.2. Message Levels
Message objects are returned in two collections; Level 1 and Level 2.
Level 1 messages are the most important. TravelDoc responses will always include at least one Level 1 message for each flight
segment.
Level 2 messages are less specific and normally include information that may or may not apply to the passenger. For example; a
country’s requirement for blank passport pages could show as a Level 2 message since it refers to all visitors but actually apply to
only a small minority of travellers.
Status of Level 1 messages is taken into account when calculating the Segment Status, whereas the Status of Level 2 messages is
ignored.
As part of the integration process, carriers have the opportunity to discuss their specific needs with ICTS, which may result in
changing the Level of certain messages which are particularly relevant to the carrier.
It is recommended that Level 1 messages always be available to a customer agent, in order to understand the reasons behind
the TravelDoc response. Level 2 messages may optionally be included, but it is recommended that agents have the ability to
retrieve Level 2 messages if required, and that Level 1 and Level 2 messages are clearly distinguished in the interface if displayed
together.
2.5. Feedback
TravelDoc includes methods for customers to submit feedback about rules directly to the rules team. This can be used where a
customer has a query about the application of a particular travel rule, where a particular message provided by TravelDoc is
unclear or ambiguous, or where a rule reported by TravelDoc is out of date or requires changes. A feedback submission should
identify the rule and change required (if necessary) as clearly as possible. It is recommended that as many as possible of the
optional fields in the feedback submission be completed to facilitate this. Customers should designate a default contact person
or e-mail address for responses (if the request does not specify an e-mail address for the response), consider which staff
members will have authority to submit feedback request and develop a process to disseminate responses to feedback requests
inside their organisation.
ICTS will respond to feedback requests by e-mail within 1 working day.
See the TravelDoc API documentation for more details about the SubmitFeedback method.
2.6. Testing
On request, ICTS can supply scenarios to test all potential TravelDoc responses across different implementations. Customers are
advised to discuss common scenarios with their TravelDoc Account Manager to ensure that the most appropriate response is
returned.
3. Implementation Scenarios
TravelDoc can be implemented anywhere and at any point of the passenger handling workflow. However, at each stage different
considerations should be taken into account when implementing the TravelDoc service.
Based on our experience of implementing TravelDoc for automated document checks with a wide variety of airlines we have
designed several high level implementation scenarios that can aid Customers in the design of their own ADC solutions.
The following sections provide high-level overview of common integration scenarios and their suggested process flow.
3.1. Reservation and Booking

During the reservation / booking process, a TravelDoc check can be performed to give the passenger confirmation they are clear
to go or provide information of their documentation needs.
In most cases, this is the best time to alert passengers to potential documentation problems, as passengers will have time to
resolve these problems, by obtaining a visa or renewing their passport. In such a scenario, the TravelDoc check is performed at
the end of the booking process. Alerts can be displayed or sent by e-mail to the passenger if they have a problem with their
documentation.
3.2. Web Check-in

When a passenger uses web check-in, they are usually issued a boarding pass to print at home. As a result, a passenger can
potentially make it all the way to the boarding gate before encountering a member of customer staff. If the passenger has an
issue with their documentation then attempting to solve this issue at the gate can be time consuming and problematic,
inevitably causing disruption to the boarding of the flight.
Performing a TravelDoc check during the web check-in process can eliminate these problems. If a passenger has a serious
problem they can be directed to contact a customer service help desk for help and the issuing of a boarding pass can be
prohibited. Alternatively, if a passenger is required to bring additional documentation with them, the passenger can be
reminded to do so and a visual stamp included on the boarding pass so that staff at the gate can easily identify which passengers
require their documentation to be checked.
3.3. Counter check-in/Assisted bag-drop

By this stage, passengers will have arrived at the airport. Checks should be performed to ensure that the passenger actually
holds the documentation they are required to have and that the documentation is valid for travel.
When passengers present their documents to check-in staff, the information from the documents should be used to perform a
TravelDoc check. Even if a passenger has previously been cleared to travel it is important to perform another check so as to
verify that the information the passenger had supplied previously is accurate.
3.4. Self-service check-in/Bag-drop

Self-service kiosks can provide most of the same functionality as TravelDoc processing by check-in agents by scanning the
machine readable zones of travel documents, and by presenting appropriate questions or prompts to the user. The minority of
passengers using self-service kiosks who generate a negative response from the TravelDoc check, or whose documents require
manual inspection, should be directed to help desk / check-in counter to complete the TravelDoc check.
3.5. Departure Gate

The departure gate is the last point at which a customer can prevent an incorrectly documented passenger from travelling. It
may also be the first point at which a passenger travelling without bags encounters airline agents. It is crucial that customers put
in place procedures to resolve documentation issues at the departure gate. It is recommended that passengers with
documentation issues identified as early as possible in the boarding process and are directed way from the main boarding queue
so that their issues can be resolved without affecting other passengers.
It is equally important to verify at the gate that any passenger-submitted information is correct. Customer agents at departure
gates should be able to easily compare the passenger’s actual travel documents with the details of travel documents used for
previous TravelDoc checks, ideally at the same time as usual security checks.
4. Support
4.1. Technical Support
 ICTS provide 24x7x365 technical support for issues related to stability and availability of the TravelDoc service.
 A support ticket can be raised via web or e-mail.
 For urgent issues, support can also be contacted via phone.
Support contact details are supplied by the TravelDoc Account Manager.
4.2. Operational Support
 ICTS provides a dedicated product support contact for operational support (rule queries and changes) and feedback.
 Feedback can be submitted via the API, via the TravelDoc Library or by opening a support ticket.
 Product Support queries have an SLA of 1 working day for responses.
Support contact details are supplied by the TravelDoc Account Manager.

ICTS Europe Systems

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

ICTS Europe Systems

Hochgeladen von

Copyright:

Verfügbare Formate

ICTS Europe Systems

System overview and implementation guide v2.2

Draft Will Rosie Initial Draft

2.0 07/12/15 Yochai Legum Baseline version

2.1 04/01/16 Yochai Legum Updated Diagram

2.2 21/01/16 Karl Grützner Updated pseudo code example

1.1. Overview .................................................................................................................................................................................. 5

1.2. Features and Benefits .............................................................................................................................................................. 5

1.3. How Does TravelDoc Work? .................................................................................................................................................... 6

1.4. TravelDoc Products and Services ............................................................................................................................................. 6

1.4.1. TravelDoc Integrated Service ........................................................................................................................................... 6

1.4.2. TravelDoc Library .............................................................................................................................................................. 7

1.4.3. TravelDoc Website ........................................................................................................................................................... 7

1.4.4. TravelDoc Widget ............................................................................................................................................................. 9

1.4.5. TravelDoc Reports .......................................................................................................................................................... 10

1.5. Can TravelDoc be customised? .............................................................................................................................................. 11

1.6. Who Manages the Travel Rules? ........................................................................................................................................... 11

1.7. Does user feedback have an influence on TravelDoc? .......................................................................................................... 11

1.8. TravelDoc Environment ......................................................................................................................................................... 11

1.9. TravelDoc Architecture .......................................................................................................................................................... 12

1.10. Data Privacy ......................................................................................................................................................................... 13

2. TravelDoc API ........................................................................................................................................................................... 14

2.1. General Information .............................................................................................................................................................. 14

2.1.1. Accessing the TravelDoc Integrated service ................................................................................................................... 14

2.1.2. Testing Application ......................................................................................................................................................... 15

2.1.3. Testing / Live Environments ........................................................................................................................................... 16

2.1.4. User Credentials ............................................................................................................................................................. 16

2.1.5. Version Upgrades ........................................................................................................................................................... 16

2.1.6. Communication with the rules team .............................................................................................................................. 16

2.2. Authentication ....................................................................................................................................................................... 17

2.3. TravelDoc Request ................................................................................................................................................................. 18

2.4. TravelDoc Response ............................................................................................................................................................... 19

2.4.1. Status .............................................................................................................................................................................. 19

2.4.2. Message Codes ............................................................................................................................................................... 20

2.4.1. Suggested Documents .................................................................................................................................................... 21

2.4.2. Message Levels ............................................................................................................................................................... 21

2.5. Feedback ................................................................................................................................................................................ 21

3. Implementation Scenarios ....................................................................................................................................................... 23

3.1. Reservation and Booking ....................................................................................................................................................... 23

3.2. Web Check-in ......................................................................................................................................................................... 24

3.3. Counter check-in/Assisted bag-drop ..................................................................................................................................... 25

3.4. Self-service check-in/Bag-drop .............................................................................................................................................. 26

3.5. Departure Gate ...................................................................................................................................................................... 27

4.1. Technical Support .................................................................................................................................................................. 28

4.2. Operational Support .............................................................................................................................................................. 28

1.2. Features and Benefits

Can be integrated anywhere

Unmatched Business Intelligence

Ability to give direct feedback

Simple and easy to understand

Immediate updates from independent sources

1.3. How Does TravelDoc Work?

1.4. TravelDoc Products and Services

1.4.1. TravelDoc Integrated Service

See Chapter 2 – TravelDoc API For more information.

1.4.2. TravelDoc Library

1.4.3. TravelDoc Website

1.4.4. TravelDoc Widget

1.4.5. TravelDoc Reports

1.5. Can TravelDoc be customised?

1.6. Who Manages the Travel Rules?

1.7. Does user feedback have an influence on TravelDoc?

1.8. TravelDoc Environment