View
232
Download
0
Category
Preview:
Citation preview
PNR Data requirements guide for airlines „Establishment of the Hungarian Passenger Information Unit” (HOME/2012/ISEC/AG/PNR/4000004451)
Table of content
1. INTRODUCTION .......................................................................................................................... 6
2. PASSENGER NAME RECORD (PNR) REQUIREMENTS .................................................... 6
2.1 LEGISLATIVE REQUIREMENTS ...................................................................................... 6
2.2 LEGISLATIVE COMPLIANCE ............................................................................................ 6
2.3 ADVANCE PASSENGER INFORMATION ....................................................................... 7
2.4 MEMBERS OF THE PROCESS ........................................................................................ 7
2.4.1 PIU .................................................................................................................................. 7
2.4.2 MINISTER OF INTERIOR ........................................................................................... 7
2.4.3 AIRLINES ....................................................................................................................... 7
2.4.4 SERVICE PROVIDERS ............................................................................................... 8
2.4.5 PASSENGER ................................................................................................................ 8
2.5 OBLIGATIONS IN CONNECTION WITH THE FORWARDING OF DATA ................. 8
2.5.1 DATA EXPECTED BY THE SYSTEM ....................................................................... 8
2.5.2 TIME OF DATA-FORWARDING ................................................................................ 8
2.5.3 PNR DATA transfer ...................................................................................................... 9
2.5.4 PNR DATA FORMAT ................................................................................................... 9
2.5.5 INFORMATION ON THE PROTECTION OF PERSONAL DATA ........................ 9
2.6 SANCTIONS ........................................................................................................................ 10
2.7 THE MAIN CASES OF IMPLEMENTATION .................................................................. 11
2.7.1 DIRECT FLIGHTS WITHOUT STOPOVER AT ONE OF THE MEMBER STATES
BUT WITH A STOPOVER IN HUNGARY .............................................................................. 11
2.7.2 MULTI SEGMENT FLIGHTS .................................................................................... 11
2.7.3 FLIGHT SUBJECT TO INCIDENTS ........................................................................ 12
3 THE APPROVAL PROCESS AND CERTIFICATION........................................................... 14
4. TRANSMISSION OF PNR DATA ........................................................................................................... 17
4.1 TRANSMISSION MANAGED DIRECTLY BY THE AIRLINE ...................................... 17
4.2 MANAGEMENT OF TRANSMISSION INCIDENTS ...................................................... 17
5 APPENDICES ............................................................................................................................. 18
5.1 APPENDIX I: Relevant parts of section 4/I of Act. LXXV. of 1999 on the Rules of
Action against Organised Crimes and certain Related Phenomena and on the required
amendments of the law .................................................................................................................. 18
5.2 APPENDIX II: Section 27/C of Act XCVII of 1995 on Air Traffic ................................. 19
5.3 APPENDIX III.: Registration forms ........................................................................................ 21
Signatories to a treaty ............................................................................................................................ 21
Contacts ................................................................................................................................................ 21
Frequency of data sending: ................................................................................................................ 21
Start time of the live data sending: .................................................................................................... 21
VPN TUNNEL PNR Endpoint ........................................................................................................... 21
TUNNEL CONFIGURATION (Applies to each tunnel) ........................................................................ 22
Template Option A ....................................................................................................................... 22
Template Option B ....................................................................................................................... 22
sFTP ....................................................................................................................................................... 24
MQ configuration ................................................................................................................................ 24
IP Connectivity ................................................................................................................................. 24
MQ Series Configuration Information ............................................................................................ 24
MQ Channels ................................................................................................................................. 24
Message Queues ............................................................................................................................... 25
HUPIU Message Queues ............................................................................................................... 25
PROVIDER Message Queues ......................................................................................................... 25
Message format types .......................................................................................................................... 25
PNR Data Content ............................................................................................................................... 26
API Data Content ................................................................................................................................ 28
5.4 Appendix IV: Technical Information on the PNR Data Transfer ....................................... 28
1 Contents ........................................................................................................................................ 30
2 TABLES ........................................................................................................................................... 32
3 DESCRIPTION ................................................................................................................................. 32
3.1 Introduction ........................................................................................................................... 32
4 TECHNICAL INTERFACE OVERVIEW ................................................................................................ 32
4.1 Transport Mechanisms .......................................................................................................... 32
4.1.1 (S)FTP ............................................................................................................................. 33
4.1.2 IBM MQ .......................................................................................................................... 33
4.1.3 HTTPS ............................................................................................................................. 34
4.2 Network Protocols ................................................................................................................. 34
4.3 Character Encoding ................................................................................................................ 34
4.4 Interface Service Levels ......................................................................................................... 34
4.5 Interface Information Model ................................................................................................. 34
4.5.1 Service Information (SI) Dataset .................................................................................... 34
4.5.2 Advanced Passenger Information (API) Dataset ............................................................ 35
4.5.3 Passenger Name Record (PNR) Dataset ......................................................................... 36
4.6 SI Dataset: Technical Details .................................................................................................. 38
4.6.1 Carrier Code ................................................................................................................... 38
4.6.2 Route ID ......................................................................................................................... 38
4.6.3 Port Codes ..................................................................................................................... 38
4.6.4 Scheduled Departure/Arrival Date and Time ................................................................. 39
4.7 Country and Issuing State Codes ........................................................................................... 39
4.8 API Dataset: Technical Details ................................................................................................ 40
4.8.1 Travel Document Type ................................................................................................... 40
4.8.2 Travel Document Number ............................................................................................. 41
4.8.3 Travel Document Expiry Date ........................................................................................ 41
4.8.4 Travel Document Issuing State (IS) ................................................................................ 41
4.8.5 Surname ......................................................................................................................... 41
4.8.6 Given Names .................................................................................................................. 42
4.8.7 Gender ........................................................................................................................... 42
4.8.8 Date of Birth................................................................................................................... 42
4.8.9 Nationality ..................................................................................................................... 42
4.9 API Dataset (PNR Subset) ....................................................................................................... 42
4.9.1 PNR Locator Code .......................................................................................................... 42
4.9.2 Initial Point of Embarkation ........................................................................................... 42
4.9.3 Final Point of Debarkation ............................................................................................. 42
4.9.4 Transit Flag ..................................................................................................................... 42
4.9.5 Total Luggage Weight .................................................................................................... 42
4.9.6 No of Bags ...................................................................................................................... 43
4.9.7 Bag Tags ......................................................................................................................... 43
4.9.8 Security Number ............................................................................................................ 43
4.9.9 Baggage Details .............................................................................................................. 43
4.9.10 Carrier Operator Unique Passenger Reference Identifier .............................................. 43
5 INFORMATION EXCHANGES OVERVIEW ........................................................................................ 43
5.1 Commercial Aviation (API) Information Exchanges ................................................................ 43
5.1.1 Check-In / Report-In Data Submissions .......................................................................... 43
5.1.2 Departure Data Submissions .......................................................................................... 44
5.2 Commercial Aviation (PNR) Information Exchanges .............................................................. 46
5.2.1 PNR Data Submission: Preliminary Submission .............................................................. 46
5.2.2 PNR Data Submission: Final Submission ........................................................................ 47
5.3 Message Responses and Error Handling ................................................................................ 48
5.3.1 Transport Level Acknowledgement ............................................................................... 48
5.3.2 Error Handling ................................................................................................................ 48
5.4 Data Currency ........................................................................................................................ 49
5.4.1 Check-in Submissions ..................................................................................................... 49
5.4.2 Departure Submissions .................................................................................................. 49
5.4.3 PNR Submissions ............................................................................................................ 49
5.5 Implementation ..................................................................................................................... 49
6 SECURITY CONSTRAINTS & NETWORKS ......................................................................................... 49
6.1 Protective Marking ................................................................................................................ 49
6.2 System Security ...................................................................................................................... 49
6.3 System Access ........................................................................................................................ 49
6.4 Networks ................................................................................................................................ 50
6.4.1 Internet (Public Network) .............................................................................................. 50
6.4.2 Third-party Suppliers ..................................................................................................... 50
7 INTERFACE AND CONTROL ............................................................................................................. 50
7.1 Interface Security Architecture .............................................................................................. 50
7.1.1 Additional Information Provided to Carriers .................................................................. 50
8 Managing relationship with the airlines and service providers ..................................................... 51
8.1 Approval process and certification ........................................................................................ 51
8.2 Management of transmission incidents ................................................................................. 52
9 GLOSSARY ...................................................................................................................................... 52
6 of 55
1. INTRODUCTION
The purpose of this guide is to provide airlines and their data transmission service
providers with a common framework, describing the scope of information to be
collected, the conditions of connection, the procedures to be implemented, as well as
the certification requirements.
Contacts
For further information and assistance please email or write to:
Informatical expert:
gabor.nyari@wsh.hu
Operational expert:
mihaly.turcsan@tibek.gov.hu
2. PASSENGER NAME RECORD (PNR) REQUIREMENTS
2.1 LEGISLATIVE REQUIREMENTS
The subsection 4/I (1) of Act. LXXV. of 1999 on the Rules of Action against Organised
Crime and certain Related Phenomena and on the required amendments of the law1,
allows the Coordination Centre against Organised Crime (hereafter TIBEK) to
request access to PNR data, in a particular manner and form, from all international
passenger air service operators flying to and from a country outside Schengen area to
or from Hungary.
2.2 LEGISLATIVE COMPLIANCE
Under subsection 27/C (5) of the Act XCVII of 1995 on Air Traffic2, airlines must forward
the PNR data to the TIBEK, or a data processing organization assigned by TIBEK after
the checking in process occurred, immediately after take-off (“wheels up”).
1 The relevant law is under modification, so the content of this chapter may change till the adoption of the new act. 2 The relevant law is under modification, so the content of this chapter may change till the adoption of the new act.
7 of 55
Section 27/C is listed in Appendix II.
According to the technical solution, repeated push of the data is also needed, the
method is summarized in Section 2.5.2.
2.3 ADVANCE PASSENGER INFORMATION
Currently the airline’s responsibility escalates only to the forwarding of Advance
Passenger Information (API data) according to the Council directive 2004/82/EC on
the obligation of carriers to communicate passenger data, and according to the section
27/B of Act XCVII of 1995 on Air Traffic. In Hungary the API data are collected and
fixed according to the Passport data, about which the passenger can be identified. The
aim of the collection of API data is to combat illegal immigration effectively and to
improve border control. In Hungary the collecting and forwarding of API data occurs
according to the section 27/B of Act XCVII of 1995 on Air Traffic.
2.4 MEMBERS OF THE PROCESS
2.4.1 PIU
The "Passenger Information Unit" (hereafter PIU) is a service of the Member State
administration that brings together the various authorities responsible for the
prevention of and fight against terrorism and serious. It is the single entry point for
interactions with the airlines or data providers. The PIU is responsible for the collection,
storage and processing of PNR data transmitted by the aviation stakeholders.
PIU is also responsible for managing the relationship with the airlines and their service
providers, as well as their monitoring and certification.
In Hungary the TIBEK is responsible for the tasks of the PIU.
2.4.2 MINISTER OF INTERIOR
The TIBEK (PIU) operates under the supervision of the Minister of Interior.
2.4.3 AIRLINES
Airlines are responsible for the transmission of reservation data (PNR). PNR data are
uncontrolled reservation information stemming from passengers and are transmitted
by means of an automated process enabling "machine to machine" (B2B: Business to
business) interface. The information may be transmitted in whole or in part by the
carrier or a service provider authorized by the carrier.
8 of 55
Under subsection 27/C (5) of Act 1995 on Air Traffic, airlines must forward the PNR
data to the HU PIU, or a data processing organization assigned by TIBEK after the
checking in process occurred, immediately after take-off (“wheels up”).
Under subsection 27/C (6) of Act 1995 on Air Traffic, airlines must inform the
passenger about the transmission of data (to which organization could the data be
forwarded), the manager of data, the data-processer, and about the right of data-
correction immediately.
According to the technical solution, repeated push of the data is also needed, the
method is summarized in Section 2.5.2.
2.4.4 SERVICE PROVIDERS
Service providers are intermediaries that the airline may mandate in order to transmit
the data. In any event, airlines remain responsible for the proper data
transmission.
2.4.5 PASSENGER
According to the subsection 27/C (2) of Act 1995 on Air Traffic, the passenger must
make the data, defined by the air service company available.
2.5 OBLIGATIONS IN CONNECTION WITH THE FORWARDING OF DATA
2.5.1 DATA EXPECTED BY THE SYSTEM
List of PNR data expected by the system can be found in Appendix I.
2.5.2 TIME OF DATA-FORWARDING
The airline must forward the PNR data to the HU PIU after the checking in process
occurred, immediately after take-off (“wheels up”)
HU PIU requires the specified PNR data elements to be transmitted a total of two times,
once 12 hours before the scheduled flight and again after flight closure as shown
below:
- 12 hours (Push 1)
- after the checking in process occurred, immediately after take-off (“wheels up”)(AFC)
(Push 2)
The chart below specifies the data content (API and PNR) expected to be transmitted
at the timeframes.
PUSH PNR DATA API DATA
9 of 55
-12 (Push 1) X
-AFC (Push 2) X X
2.5.3 PNR DATA transfer
Airlines must provide a ‘push’ electronic transfer of passenger information from their
Reservations system and from Departure Control System to HU PIU as defined in
subsection 27/C (5) of the Act XCVII of 1995 on Air Traffic.
PNR data, which are available from the data listed in Appendix I, must be provided to
the HU PIU for passengers whose itineraries include a flight to, from or through
Hungary, to or from a country outside Schengen area by the operating airline.
2.5.4 PNR DATA FORMAT
The form of the data means the form by which PNR data is to be provided to PIU
preferred to be in accordance with.
HU PIU prefers when airlines transfer PNR data in PNRGOV format according to the
International Air Transport Association (IATA) / International Civil Aviation Organisation
(ICAO) / World Customs Organisation (WCO) common Guidelines.
The preferred PNRGOV3 message have to be developed under the auspices of the
IATA PADIS Board. The message structure and the contents of the message need to
provide a consistent approach for all airlines required to provide PNR information to
Governments.4
2.5.5 INFORMATION ON THE PROTECTION OF PERSONAL DATA
3 More information about PNRGOV can be reached at the following website:
https://www.iata.org/iata/passenger-data-toolkit/assets/doc_library/04-
pnr/New%20Doc%209944%201st%20Edition%20PNR.pdf
4 https://www.iata.org/iata/passenger-data-toolkit/assets/doc_library/04-pnr/PNRGOV%20EDIFACT%20Implementation%20Guide%2013_1.pdf
10 of 55
TASKS OF HU PIU
HU PIU manages a data transmission register on passenger data, and it is bound to
preserve it for ten years.
The passenger data can be managed from the date of data transmission till 5 years.
After 30 days, the passenger data had arrived to HU PIU it must be depersonalised.
The data could be repersonalised, only if the head of the HU PIU disposes it in the
cases of
- an affair hardly threatens the national security or the independence of the
country, or
- the suspicion of a preparation of a felony punished with imprisonment of five
years or more severe punishment.
TASKS OF THE AIRLINE
Under subsection 27/C (3) of Act 1995 on Air Traffic, airlines can manage data form
the 345th day before the date of departure till 60 days after the arrival to the final
destination in connection with first and family names, place of departure, transit and
arrival, and means of payment, including invoicing address.
The other data can be managed by the airline from the 345th day till 24 hrs after the
arrival of the final destination of the flight.
Under subsection 27/C (6) of Act 1995 on Air Traffic, airlines must inform the
passenger about the transmission of data (to which organization could the data be
forwarded), the manager of data, the data-processer, and about the right of data-
correction immediately.
The data, mentioned in Appendix I can be changed till the checking in procedure ends.
2.6 SANCTIONS
Under subsection 66/A (1) f) of Act 1995 on Air Traffic the Air Traffic Authority can
impose a penalty up to 100 000 000 Ft, if an Airline violates the commitments on data
supplying, information or notification stated in the regulations of an act, regulation
based on an act, or EU regulation. In regard to the transmission of PNR data is a
statutory commitment (stated in an act), so the subsection 66/A (1) f) of Act 1995 on
Air Traffic can be applied in case of the violation of the regulations.
11 of 55
2.7 THE MAIN CASES OF IMPLEMENTATION
2.7.1 DIRECT FLIGHTS WITHOUT STOPOVER AT ONE OF THE MEMBER
STATES BUT WITH A STOPOVER IN HUNGARY
In the context of a direct flight with no stopovers to or from another member state, the
airline operating the flight is responsible for sending data of the passengers that it
carries.
The company may decide to outsource the transmission of the data to the PIU by a
service provider, but remains responsible for the proper data transmission.
2.7.2 MULTI SEGMENT FLIGHTS
A traveller may make a journey with multiple segments.
The airline sends all the reservation data it has, whether the journey has one or more
segments.
Multi-segment journeys
When the various segments are operated by one or more airlines under the guise of
different flight numbers for each of the segments, the requirement with respect to
transmitting PNR data is applicable to any segment involving flying to Hungary from a
non-Schengen country, or flying from Hungary to a third country, outside of the
Schengen area.
Multi-segment flights
When the various segments are carried out under the guise of the same flight number,
one should apply the following management rules:
12 of 55
The regulations provided for the transmission of all the data of the passengers whose
final destination is BUD.
In theory, the Jakarta-Doha-Budapest flight is operated by a single airline and has a
unique flight number for the Jakarta-Doha (segment A) and Doha-Budapest (segment
B) segments.
The system accepts these two strategies from the service provider:
- PNR data sending concerning the passengers flying from Jakarta to Budapest (A+B)
and PNR data sending concerning the passengers boarding in Doha to Budapest (B).
2.7.3 FLIGHT SUBJECT TO INCIDENTS
This chapter is intended to deal with cases of flights subject to incidents affecting the
initial programming. This includes the following cases:
- cancelled flights;
- postponed and/or renumbered flights
- technical stop
- emergency
In the case of cancelled flights, technical stop and emergency the company does not
transmit data.
13 of 55
In the case of postponed and/or renumbered flights, the airline will transmit the data at
the time of the actual take-off of the postponed and/or renumbered flight without the
need to inform the PIU.
14 of 55
3 THE APPROVAL PROCESS AND CERTIFICATION
The process is based on the five steps described below.
Preliminary step:
Once the legal requirement has been notified to the airline, the carrier contacts the PIU
(to initiate the process and implement the appropriate modalities (agreement,
documents, forms, calendar, etc.)
A dedicated website will allow carriers to download all the relevant information.
THE BASIC STEPS OF CONNECTION AN AIR CARRIER AS FOLLOWS:
a) configuring and setup the VPN - see the attached form below
b) configuring and setup the MQ
c) connect to our test system
d) test data sending /we check the format (PNRGOV and PAXLST)
e) error corrections if needed
f) continuous test data sending /we check the format (PNRGOV and PAXLST)
and timing
g) error corrections if needed
h) connect to our productive system
15 of 55
i) continuous live data sending
Step 1: Application for accreditation and/or certification
This step allows an airline and its possible service provider to register with the PIU for
accreditation and/or certification.
The application for accreditation of the carrier (Appendix III.) relates exclusively to
airlines while the form for technical certification of the IT system (Appendix III.)
concerns the airline and/or one or more data providers.
In the application for accreditation, the airlines shall specify in particular:
- the coordinates of the specified contacts; - the list of routes they operate that depart from, arrive in or transit through MS
territory, indicating for each: - the reservation and registration systems used, - the possible use of a service provider for the data transmission.
A service provider may apply independently to the PIU in order to technically certify its transmission system.
Step 2: Validation of the application for accreditation by the Administration
The Passenger Information Unit examines and validates the application for approval
filed by an airline for the transmission of PNR data accompanied by an agreement
(Appendix III.) to be signed between the administration and the airline.
The examination step permits validation of application for which arrangement is made
by an airline regarding the completeness of data to be transmitted, after presentation
of a proposal from the carrier to justify an arrangement. In fact, some airlines may not
be able to immediately comply with all the MS requirements. In this case, the validation
of the application is subject to an undertaking by the airline and a timetable for
compliance.
In other cases, some airlines, by their nature or by their operational constraints, may
not have all the data required. In this case, the request for arrangement must be
justified.
Step 3 : Certification
We define the connection of a data provider to the system as the situation in which the
data provider is operationally connected to the production environment of the system,
is authenticated by the system, and is able to transmit the PNR data to the system, in
accordance with predefined formats and using predefined protocols.
16 of 55
Certification is the process of assessing the ability of a data provider to connect to the
system. The certification may concern either the system of an airline or that of a
possible service provider to which the airline subcontracts the transmission of the data.
The certification step includes the carrying out of tests to check:
- the analysis of the data link; - the transmission of data; - the analysis of the data transmitted.
17 of 55
4. TRANSMISSION OF PNR DATA
4.1 TRANSMISSION MANAGED DIRECTLY BY THE AIRLINE
The airline must be approved and certified by the PIU.
The airline should implement the following four-step process:
Step 1: The airline makes an application for accreditation and certification by
completing the application form;
Step 2: After checking the ability of the airline to send the PNR data for all the
stated routes, the PIU validates the request for accreditation.
Step 3: The airline carries out technical certification tests of its means of
transmission.
Step 4: After validation of the previous steps, the airline is awarded the
certificate of accreditation and certification. The agreement is signed.
- Issuing a certificate: The certificate declares the data processing requirements
stated in the agreement (which was discussed with the airlines).
4.2 MANAGEMENT OF TRANSMISSION INCIDENTS
A company discovering a transmission incident in its systems shall immediately notify
the PIU.
An airline receiving an acknowledgment of receipt designated as "non-compliant" by
the programme, shall immediately contact the PIU.
A new complete transmission of the data must be made as soon as possible
Incident management is independent of penalty management processes.
The Hungarian PNR system will have web-portal through which Airlines can send
passenger data in case of no data link or other transmission incidents.
18 of 55
5 APPENDICES
5.1 APPENDIX I: Relevant parts of section 4/I of Act. LXXV. of 1999 on
the Rules of Action against Organised Crimes and certain Related
Phenomena and on the required amendments of the law
4/A (1) With the aim of facilitating the prevention, interruption and investigation of organised crime the organisation responsible for the collection, usage and control of data collected for the purpose of fight against organised crime (hereinafter referred as the coordination centre against organised crime) …
h) fulfils the tasks of the passenger information unit. ... 4/I (1) In the context of its roles specified in point h) of 4/A § (1) the coordination centre against organised crime takes over and handles passenger data. … 2) The passenger data provider shall transfer the passenger data in an electronic format and in a way determined by the coordination centre against organised crime. …
19 of 55
5.2 APPENDIX II: Section 27/C of Act XCVII of 1995 on Air Traffic
27/C. § (1) With the aim of ensuring the safety of the air navigation and the security of
the passenger and with the aim of facilitating the detection, the investigation of
terrorism and organised crime related criminal offences, as well as measures targeting
the prevention of efforts and activities endangering national security and with the aim
of facilitating tasks related to the prevention of illegal migration, based on the data
provision of the passenger or its trustee – or based on the data provision of the ticketing
service provider carrying out its activity on behalf of the passenger air carrier – the
passenger air carrier may handle the below mentioned data of the passenger travelling
from an originating country other than Schengen States to Hungary as final destination
or as transit country, and the data of the passenger travelling from Hungary to
destination outside of the territories of Schengen States:
1) Name (full name of the passenger, the name of the person booking the
ticket in case of this person is different from the passenger )
2) Gender of the passenger
3) Travel agency, name of the travel agent
4) Flight number
5) Date of departure and arrival
6) Origin, transit country and destination
7) Record locator code
8) Date of ticket issuance
9) Seat number and particular requests and information related to the seat
10) Number of and data related to the hold luggage and hand luggage of
the passenger
11) Name and number of travelling companion(s)
12) Contact information provided by the passenger, especially the
permanent and temporary address, phone number and e-mail address
of the traveller and the traveller’s companions
13) All available bank account and credit card related payment and billing
information except those that cannot be linked to the transaction of the
travel
14) Ticketing details, especially the number of the flight ticket and the name
of the issuing airline
15) Information related to the circumstances of the flight
16) Data available on the travel document (type and number of travel
document, nationality, issuing country, expiration date of the travel
document, date of birth)
17) Modification of the information listed in points 1) – 16)
(2) The passenger shall make available those data for the passenger air carrier which
are specified in paragraph (1) and are requested by the passenger air carrier.
20 of 55
(3/a) With regard to the data specified in points 1., 6. and 13. of paragraph (1) –
furthermore in connection with those, the data specified in point 17. of paragraph (1) –
provided that the passenger, after having been duly informed, did not voluntary and
expressly give consent to different duration of data handling – the passenger air carrier
may handle the data from the 345th day prior to the date of the departure until for a
period of 60 days after the date of the arrival of the flight to the final destination.
(3/b) The passenger air carrier may handle the data specified in points 2-5., 7-12. and
14-16. of paragraph (1) – furthermore in connection with those the data specified in
point 17. of paragraph (1) - from the 345th day prior to the date of the departure until
for a period of 24 hours after the date of the arrival of the flight to the final destination.
(4) The data specified in paragraph (1) might be modified – on the initiative of the one
who booked the ticket – until the termination of the check-in procedure.
(5) 12 hours prior to the planned departure of the flight, and upon the completion of the
check-in procedure, after the take-off, the passenger air carrier shall transmit those
data specified in paragraph (1) which are available to the coordination centre against
organised crime in order to enable it to perform passenger information related tasks.
(6) Simultaneously with the recording of the data the passenger air carrier shall inform
the passengers about the data transmission, the data handler, the purpose and
duration of the data handling, eventual data processor as well as about the passenger’s
right of requesting information about the retained data and requesting the correction of
those data. The passenger air carrier shall inform the passenger about the
organisations to which the data may be transmitted and about the purpose of the data
transmission.
21 of 55
5.3 APPENDIX III.: Registration forms
Signatories to a treaty
Authority: Hungarian Passanger Information Unit (HU PIU) Carrier: <Airline name> (Airline code: <XX>) Destinations: <Destination>-Budapest, Budapest-<Destination> (XXX-BUD-XXX) Flight numbers: <Flight list>
Contacts
AIRLINE
Company Name
<Airline name>
PRIMARY AIRLINE
CONTACT
Name Email Phone
SECONDARY AIRLINE
CONTACT
Name Email Phone
HU PIU REPRESENTATIVE
Name Email Phone
Frequency of data sending:
HU PIU requires the specified PNR data elements to be transmitted a total of two times, once 12 hours before the scheduled flight and again after flight closure as shown below:
- 12 hours (Push 1) - after the checking in process occurred, immediately after take-off (“wheels up”)(AFC) (Push 2)
HU PIU requires the specified API data elements to be transmitted after flight closure as shown below:
- after the checking in process occurred, immediately after take-off (“wheels up”)(AFC)
Start time of the live data sending:
VPN TUNNEL PNR Endpoint
HUPIU PNR’S HOST
INFORMATION
Hardware Type Software Version VPN Termination Address (Peer IP)
Local Network
CUSTOMER’S HOST
INFORMATION
Hardware Type Software Version VPN Termination Address (Peer IP)
Local Network
22 of 55
CUSTOMER’S NETWORK
INFORMATION
Network / Host / Source (Provide a public source network address)
TUNNEL CONFIGURATION (Applies to each tunnel)
Is this request for a “NOFEP” tunnel? YES / NO:
Note: Tunnels other than NOFEP require a Service Request (SR) and a Firewall Rule Change Request (FRCR). For
NOFEP tunnels, PCC must be provided in “Customer Company Information” section above.
Tunnel Configuration Parameters
(please select option ‘A’ or ‘B’)
Option ‘A’
Option ‘B’
Perfect Forward Secrecy is disabled by default.
ENABLE PFS? YES / NO: NO
If PFS enabled, Diffie-Hellman (DH) Group 2 OR
5?
SPECIFY “2” OR “5”:
Template Option A
IKE - PHASE 1
Encryption AES-256
Authentication SHA1 DH Group Group 2 Lifetime 86,400 seconds
IPSec - PHASE 2
Encryption AES-256 Authentication SHA1
Lifetime 28,800 seconds
Template Option B
IKE - PHASE 1
Encryption 3DES Authentication SHA1
DH Group Group 5
Lifetime 86,400 seconds
IPSec - PHASE 2
Encryption 3DES Authentication SHA1
23 of 55
Lifetime 28,800 seconds
24 of 55
sFTP
IP address Port Username Password
TEST
<username>
PRODUCTIONB
<username>
<username>
MQ configuration
IP Connectivity
Traffic Type HUPIU <Airline/Service Provider>
IP Address Port IP Address Port
Test
Outbound, Airline initiated
* *
Inbound, HU PIU initiated
* *
Production
Outbound Airline initiated
* *
Inbound HU PIU initiated
* *
MQ Series Configuration Information
MQ Channels
Organisation / Channel type Environment / Channel name Environment / Channel name
HUPIU Test Production
Sender
Receiver
Airline Test Production
Receiver
Sender
25 of 55
Message Queues
HUPIU Message Queues
Item Test Production
MsgType
Persistence
Format
Queue Name (HUPIU) for PNR
Queue Name (HUPIU) for API
MQ Queue Manager (HUPIU)
PROVIDER Message Queues
Optional (you should only take this into consideration if you require acknowledgements)
Item Test Production
ReplyTo Queue for acknowledgement
ReplyTo Queue Manager for acknowledgement
Message format types
Message format type Version
PNRGOV EDIFACT MESSAGE (PNRGOV)
WCO/IATA/ICAO PASSENGER LIST MESSAGE (PAXLST)
26 of 55
PNR Data Content
Data Group Data Item(s) Name Does carrier send this data
(Yes/No)?
Basic Passenger Information
Name (first name, last name)
Nationality (Citizenship)
Birthday
Gender
Address (street, city, country, postcode)
E-mail address
Phone number
Traveller Reference Number
Identity document
Type
Number
Issuing Country
Expiry date
Travel Itinerary
Sequence Number
Carrier Code
Flight Number
Flight Number Suffix
Arrival Airport Code
Arrival City
Arrival Date
Arrival Time
Departure Airport Code
Departure City
Departure Date
Departure Time
Seat Number
Seat Type
Flight Status
Codeshare Carrier Code
Travel Information
PNR Locator
PNR Creation Date (assume is the same as Reservation Date)
PNR Creation Time
Parent PNR
Split PNR
Split Date
Group Name
Traveller Status Ind
27 of 55
Data Group Data Item(s) Name Does carrier send this data
(Yes/No)?
Number of PNR
Transit
Embark Port
Debark Port
Ticket Information
Ticket Number
Ticketing Date
Ticketing Time
Ticketing Type
Booking Travel Agency Id
Booking Travel Agency
Booking Travel Agent
Fare Class
Reservation
Reservation Date (assume is the same as PNR Creation Date)
Reservation Time
Reservation Ctl Type
Company Ident
Payment
Cost Of Ticket
Currency Code
Payment Type
Credit Card Number
Checkin Info
Boarding Number
Passenger Name
Seat Number
Cabin Class Designator
Traveller Reference Number
Travel Agent Identify
Baggage Info
Total Baggage Pieces
Total Checked Bag Weight
Unit of measure (UOM)
Bag Tag
Bag Final Destination
Traveller Reference Number
Total Consecutive Item
28 of 55
API Data Content
Data Group Data Item(s) Name Does carrier send this data
(Yes/No)?
Basic Passenger Information
Name (first name, last name)
Nationality
Birthday
Gender
Identity document
Type
Number
Issuing Country
Expiry date
Travel Information
PNR Locator
Transit
Embark Port
Debark Port
Checkin Info
Boarding Number
Seat Number
Traveller Reference Number
Baggage Info
Total Baggage Pieces
Total Checked Bag Weight
Unit of measure (UOM)
Bag Tags
Bag Final Destination
5.4 Appendix IV: Technical Information on the PNR Data Transfer
HU-PIU
29 of 55
Master Carrier Interface Control Document
Version 1.2
30 of 55
1 Contents
2 TABLES ........................................................................................................................................... 32
3 DESCRIPTION ................................................................................................................................. 32
3.1 Introduction ........................................................................................................................... 32
4 TECHNICAL INTERFACE OVERVIEW ............................................................................................... 32
4.1 Transport Mechanisms .......................................................................................................... 32
4.1.1 (S)FTP ............................................................................................................................. 33
4.1.2 IBM MQ ......................................................................................................................... 33
4.1.3 HTTPS ............................................................................................................................. 34
4.2 Network Protocols ................................................................................................................. 34
4.3 Character Encoding ............................................................................................................... 34
4.4 Interface Service Levels ......................................................................................................... 34
4.5 Interface Information Model ................................................................................................. 34
4.5.1 Service Information (SI) Dataset .................................................................................... 34
4.5.2 Advanced Passenger Information (API) Dataset ........................................................... 35
4.5.3 Passenger Name Record (PNR) Dataset ........................................................................ 36
4.6 SI Dataset: Technical Details.................................................................................................. 38
4.6.1 Carrier Code ................................................................................................................... 38
4.6.2 Route ID ......................................................................................................................... 38
4.6.3 Port Codes ..................................................................................................................... 38
4.6.4 Scheduled Departure/Arrival Date and Time ................................................................ 39
4.7 Country and Issuing State Codes ........................................................................................... 39
4.8 API Dataset: Technical Details ............................................................................................... 40
4.8.1 Travel Document Type .................................................................................................. 40
4.8.2 Travel Document Number ............................................................................................. 41
4.8.3 Travel Document Expiry Date ........................................................................................ 41
4.8.4 Travel Document Issuing State (IS) ................................................................................ 41
4.8.5 Surname ........................................................................................................................ 41
4.8.6 Given Names.................................................................................................................. 42
4.8.7 Gender ........................................................................................................................... 42
4.8.8 Date of Birth .................................................................................................................. 42
4.8.9 Nationality ..................................................................................................................... 42
4.9 API Dataset (PNR Subset) ...................................................................................................... 42
4.9.1 PNR Locator Code .......................................................................................................... 42
4.9.2 Initial Point of Embarkation ........................................................................................... 42
31 of 55
4.9.3 Final Point of Debarkation ............................................................................................. 42
4.9.4 Transit Flag .................................................................................................................... 42
4.9.5 Total Luggage Weight .................................................................................................... 42
4.9.6 No of Bags ...................................................................................................................... 43
4.9.7 Bag Tags ......................................................................................................................... 43
4.9.8 Security Number ............................................................................................................ 43
4.9.9 Baggage Details ............................................................................................................. 43
4.9.10 Carrier Operator Unique Passenger Reference Identifier ............................................. 43
5 INFORMATION EXCHANGES OVERVIEW ....................................................................................... 43
5.1 Commercial Aviation (API) Information Exchanges............................................................... 43
5.1.1 Check-In / Report-In Data Submissions ......................................................................... 43
5.1.2 Departure Data Submissions ......................................................................................... 44
5.2 Commercial Aviation (PNR) Information Exchanges ............................................................. 46
5.2.1 PNR Data Submission: Preliminary Submission ............................................................. 46
5.2.2 PNR Data Submission: Final Submission........................................................................ 47
5.3 Message Responses and Error Handling ............................................................................... 48
5.3.1 Transport Level Acknowledgement ............................................................................... 48
5.3.2 Error Handling ............................................................................................................... 48
5.4 Data Currency ........................................................................................................................ 49
5.4.1 Check-in Submissions .................................................................................................... 49
5.4.2 Departure Submissions.................................................................................................. 49
5.4.3 PNR Submissions ........................................................................................................... 49
5.5 Implementation ..................................................................................................................... 49
6 SECURITY CONSTRAINTS & NETWORKS ........................................................................................ 49
6.1 Protective Marking ................................................................................................................ 49
6.2 System Security ..................................................................................................................... 49
6.3 System Access........................................................................................................................ 49
6.4 Networks ............................................................................................................................... 50
6.4.1 Internet (Public Network) .............................................................................................. 50
6.4.2 Third-party Suppliers ..................................................................................................... 50
7 INTERFACE AND CONTROL ............................................................................................................ 50
7.1 Interface Security Architecture ............................................................................................. 50
7.1.1 Additional Information Provided to Carriers ................................................................. 50
8 Managing relationship with the airlines and service providers .................................................... 51
8.1 Approval process and certification ........................................................................................ 51
8.2 Management of transmission incidents ................................................................................ 52
9 GLOSSARY ................................................................................................................................. 52
32 of 55
2 TABLES
Table 1 Supported transport mechanisms by message type ................................................................ 33 Table 2 SI Data Items ............................................................................................................................. 34 Table 3 API Data Items .......................................................................................................................... 35 Table 4 PNR Data Items ......................................................................................................................... 36 Table 5 Carrier Codes, Country/Issuing State Codes, Port Codes and Route ........................................ 39 Table 6 Travel Document Codes and Names (acceptable travel documents) ...................................... 40 Table 7 Commercial Aviation (API) Supported Data Formats ............................................................... 43 Table 8 Commercial Aviation (API) Passenger Check-In ........................................................................ 44 Table 9 Commercial Aviation (API) Passenger Departure ..................................................................... 45 Table 10 Commerical Aviation (PNR) Supported Data Formats ............................................................ 46 Table 11 Commercial Aviation (PNR) Preliminary Submission .............................................................. 46 Table 12 Commercial Aviation (PNR) Final Submission ......................................................................... 47 Table 13 Terms, Acronyms and Abbreviations ...................................................................................... 53 Table 14 List of PNR topics expected by the system .............................................................................. 0
3 DESCRIPTION
3.1 Introduction
This document constitutes the Master Carrier Interface Control Document (ICD) and contains the technical guidelines for Carriers to follow in the preparation and transmission of Passenger API and PNR data for processing by HU-PIU.
Carriers can use one or more interface options covered by this document to deliver the information to the Passenger Information Unit (PIU).
Changes to existing standards and formats will follow normal industry implementation practices and will include working with the industry to reduce the impact of any change on their systems.
4 TECHNICAL INTERFACE OVERVIEW
4.1 Transport Mechanisms
This section discusses the various transport mechanisms available to the Carrier for the transmission of data to HU-PIU. Instructions on how to connect to HU-PIU using one of these mechanisms are made available to the Carrier in the applicable User Guide which is provided to them during the Carrier Certification process.
Each of the message format types is transmitted over a range of transport mechanisms. Each of the transport mechanisms must be used in conjunction with either a VPN connection or SSL/TLS session. For the remainder of this document where the term SSL is used, it shall be used to represent both SSL and TLS.
A summary is provided within this document to provide a security context. The credentials required to establish a connection to the HU-PIU system are provided to the Carrier as part of the certification process. Whether the Carrier chooses to use VPN or SSL to connect to the HU-PIU system, the data transmitted through the VPN tunnel or over the SSL session is encrypted by the methods provided by each of the respective transport layer security mechanisms.
Based on the transport mechanism used to transmit messages to HU-PIU, the Carrier can choose to digitally sign their messages. This provides both non-repudiation and integrity checking for messages sent by the Carrier affording them a high level of information security assurance. For a Carrier who
33 of 55
chooses to digitally sign messages, they must do so in the method specified for each transport mechanism or protocol. Table 1 provides details of the supported mechanism types.
Depending on the specific transport mechanism selected by the Carrier different connection parameters may be required for each of the information exchanges. For Certification purposes these details are provided as part of the User Guides. Connection parameters to HU-PIU environments are provided to the Carrier during Carrier Certification process.
Table 1 Supported transport mechanisms by message type
WCO/IATA EDIFACT PAXLST
US Varient EDIFACT PAXLST
PNRGOV EDIFACT
PNRPUSH PNR CSV PNR XML
SSH / SFTP - - Yes Yes Yes Yes
IPSec VPN / FTP - - Yes Yes Yes Yes
IPSec VPN / MQ Server – Server / SSL Auth / Type B
Yes Yes Yes Yes - -
IPSec VPN / MQ Client – Server / SSL Auth / Type B
Yes Yes Yes Yes - -
SS SSL / HTTPS – Web Manual File Upload
- - Yes Yes Yes Yes
4.1.1 (S)FTP
There are two alternatives for file transfer using this transport: FTP over VPN or SFTP.
The FTP protocol is used by a Carrier to supply data to the HU-PIU system where data is captured in one or many files. The HU-PIU system provides the capacity for a Carrier to connect to an (S)FTP server provided by the HU-PIU system and transmit files. Data sent over an (S)FTP connection must be secured. To achieve this, the Carrier must ensure that they have configured their (S)FTP client to meet the HU-PIU security requirements.
An example of this connection method - An authenticated Carrier wishing to submit a CSV file will be provided with a CSV template. The Carrier then populates the template off-line. When a file (using a template or not) is encoded in the correct format and ready to transfer, the Carrier submits the file via (S)FTP. A transport level response is immediately returned by the HU-PIU (S)FTP server.
4.1.2 IBM MQ
IBM MQ is a messaging service for assured delivery of messages between different systems and their associated platforms. The HU-PIU system provides a number of message queues for the exchange of messages between the Carrier and HU-PIU.
HU-PIU prefers the use of MQ for the exchange of data between the Carrier and HU-PIU.
The Carrier makes use of a VPN connection to exchange MQ messages over a public network to the HU-PIU system. This is to ensure secure transmission of data between the Carrier and the HU-PIU system.
The MQ message encapsulation can support the inclusion of a digital signature which the Carrier may choose to generate. HU-PIU will digitally sign the response of any MQ response.
34 of 55
4.1.3 HTTPS
A web site is provided by HU-PIU to allow a Carrier to upload files to the HU-PIU system. A Carrier, using an approved browser and provided credentials, is afforded the ability to upload one or many files containing messages supported by this interface.
The Carrier should be aware of the bandwidth of their Internet connection as this affects the time it takes to upload files using this mechanism. For all supported message formats, when the file is ready to transfer and encoded in the correct format, the Carrier can then submit the file for transfer. The HU-PIU system will receive the file and a transport level response is immediately returned.
Through the SSL handshaking procedure, the necessary keys are exchanged to facilitate the encryption of data over the interface from the Carrier to the HU-PIU system.
4.2 Network Protocols
HU-PIU supports IPSec VPN, SSL and SSH network protocols. Transmitted data is encrypted by the methods provided with each of the network protocols. The credentials required by these protocols are provided to the Carrier as part of the certification process.
Topics
The URL and IP address to which Carriers connect.
Registering the submitter s static IP
address (or that of their router) for purposes of
verification of sender.
Username and password assignment.
4.3 Character Encoding
HU-PIU supports UTF-8 encoding format. Message formats described in each annex contain restrictions of allowable characters within UTF-8, in order to conform to the message format standards.
An example is the use of the quote („) character in PAXLST. Details of how to handle these characters are provided in the Message profile annexes and the message standards they reference.
4.4 Interface Service Levels
Carrier interfaces are highly-available (24/7) with outages being planned within pre-defined service windows. The service levels provided by the Carrier source systems are not specified in this ICD.
4.5 Interface Information Model
The data provided to HU-PIU is categorised into several datasets. The data items that exist within each of these datasets are outlined in this section. Each of the data items listed may be comprised of several data fields within the message sent to HU-PIU. The values supplied by the Carrier for certain fields vary by industry and are discussed further in this sections. Regardless of these industry variations the Carrier provides the data within the same fields in the message format. Variations to the guidelines, specific formatting rules, and fields used within the message type are discussed in each of interface profiles that are annexed to this document.
4.5.1 Service Information (SI) Dataset
The list of the SI data items and their definition is provided in Table 2
Table 2 SI Data Items
35 of 55
Data Item Definition
Carrier Code Code assigned to identify the Carrier
Carrier Route Number A unique identifier for a particular voyage on a given day.
Last Place/Port of Call Port of departure of Carrier’s voyage.
This must be the last port of call for the vessel.
Place/Port of First Arrival
Place/Port in the country of destination where Vessels arrive from the ‘last place/port of call’
Subsequent Place/Port of call within the country
Subsequent place/port of call within the country following the ‘place/port of first arrival’.
Left blank unless the vessel is continuing to a subsequent port within the same country. Mandatory for inbound voyages and optional for outbound voyages.
Scheduled Departure Date
Local date for scheduled voyage departure (at Last Place/Port of Call)
Scheduled Departure Time
Time for scheduled voyage departure (at Last Place/Port of Call)
Scheduled Arrival Date Local date for scheduled voyage arrival at Place/Port of First Arrival
Scheduled Arrival Time Time for scheduled voyage arrival at Place/Port of First Arrival
4.5.2 Advanced Passenger Information (API) Dataset
The API data accompanies SI data and provides specific data items.
At Check-in and for Qualified Change, the entire API and SI data sets are transmitted. For departure (confirmation and exception), only a subset of API data is mandatory.
The list of API data items and their definition is provided in Table 3.
Table 3 API Data Items
Data Item Definition
Travel Document Type Type of Travel Document being used.
See Table 6 for a list of valid Travel Documents
Travel Document Number Identification Number of the Travel Document
Travel Document Expiry Date Expiry date of the Travel Document
Mandatory only if the travel document has one.
Travel Document Issuing State State/Organisation that issued the Travel Document being used
Surname Surname (family name) of the travelling person
Given Names Given names of the travelling person.
Gender Gender of the travelling person
Date of Birth Date of birth of the travelling person
Nationality Nationality of the travelling person
36 of 55
Data Item Definition
*PNR locator code A code which uniquely identifies a particular PNR record for a given voyage. The voyage would be defined by the SI data set. This code is used to link a passenger‟s API data to a single PNR record.
The same PNR record locator code needs to be included in both the API and PNR. It is anticipated that Carriers use the booking reference or PNR to populate this data element.
Carrier Operator Unique Passenger Reference Identifier
Used to uniquely identify a passenger within a Carrier‟s Reservation and DCS systems. Therefore there is no repeat between flights.
*Initial Point of Embarkation Port code of the initial place of embarkation
*Final Point of Debarkation Port code of the final place of debarkation
*Transit Flag Indicates if the passenger or crew is in transit
*Total Luggage Weight Weight of total luggage carried by a passenger
*No of Bags Total number of bags carried by a passenger
*Bag Tags Tag information of bags carried by a passenger
*Security Number Unique number allocated by the check in desks and it identifies a passenger.
*Baggage Details Details of the baggage including bag destination
*Seat number Passenger seat number
* Indicates PNR fields that a Carrier may supply to the extent known. Note: mandatory, to the extent known, where a Carrier is submitting PNRGov.
4.5.3 Passenger Name Record (PNR) Dataset
When applicable or required, PNR data accompanies the SI data and provides the specific data items in Table 4.
Table 4 PNR Data Items
Data Item Definition
PNR Locator Code A code which uniquely identifies a particular PNR record for a given voyage. The voyage would be defined by the SI data set. This code is used to link a passenger’s API data to a single PNR record. The same PNR record locator code needs to be included in both the API and PNR.
It is anticipated that Carriers use the booking reference or PNR to populate this data element.
Date Of Reservation Date reservation made.
Date(s) Of Intended Travel Date Passenger intends to travel.
37 of 55
Data Item Definition
Name Passenger name.
Other Names On PNR Including names of all other passengers on the booking and any contact person.
Address Passenger‟s address and any further contact address for the passenger/reservation.
Contact Telephone Numbers Can include telephone number for Passenger, Travel Agency, Hotel etc.
Email Address Email address of person who made reservation.
Contact Details The name, address, telephone number and email address for any individual who placed the booking.
All Forms Of Payment Information Specifies payment means and details (e.g. Credit Card Number). Should not include CSC (also referred to as CVV).
Billing Address Address used to authorise payment.
Ticketing Field Information Includes ticket number and ticket type.
All Travel Itinerary For Specific PNR Route booked for those passengers on the PNR record. Will consist of several sets of SI data one for each leg of the journey associated to the booking.
All Historical Changes To The PNR All changes to the PNR record.
Frequent Traveller Information Card number and type of any frequent flyer or similar scheme used.
Travel Agent Agency name, IATA code or telephone number of travel agency.
Identity Of Person Who Made The Booking The identity of person/agent who made the booking. This is the identity of a person in travel agency who made the booking.
Code Share PNR Information PNR reference of code share booking.
Split/Divided PNR Indicator The fact that a reservation in respect of more than one passenger has been divided due to a change in itinerary for one or more but not all of the passengers.
Seat Requested Class of travel, seat number and cabin number request where applicable.
Seat Allocated Class of travel, seat number and cabin number allocated where applicable.
Baggage Information Number of bags, total weight, tag numbers, destination of bags and pooled bag details.
Issued at check-in.
General Remarks Additional information that the agent considers of interest or relevance to the booking.
38 of 55
Data Item Definition
OSI Information Other supplementary information, e.g. Infant, Staff, VIP. OSI string will be extracted and stored.
SSI/SSR Information Special Service Information or Special Service Requests. The entire SSR/SSI string will be extracted and stored.
Additional SSR/SSI elements will also be extracted.
Any Collected API Information Any API data elements collected at the time of booking. Name and travel document number will be extracted.
Group Indicator Indicates whether the passenger is travelling as part of a group.
Number Of Travellers On PNR Number of passengers in party.
Security Number Unique number allocated by the check in desks and it identifies a passenger.
4.6 SI Dataset: Technical Details
The SI dataset defines the voyage for which data is submitted to HU-PIU.
Details of SI data items and their definition are provided below.
4.6.1 Carrier Code
HU-PIU requires unique Carrier codes to identify each Carrier. HU-PIU supports the following Carrier codes:
Air Carriers use two character IATA code or three character ICAO code. Carrier Codes along with Country and Issuing State Codes, Port Codes and Route IDs are further clarified in the Table 5.
4.6.2 Route ID
The route IDs provided by the Carrier may be in any number of different formats. The format of route ID is dictated by the message format selected by the Carrier.
The Carrier is responsible for ensuring that this identifier is unique for all voyages operated by the Carrier on a specific date or dates when voyages may overlap in time. All data transmissions received by HU-PIU relating to a specific scheduled service should include the exact same route ID on the SI record for those transmissions.
Whilst no specific route ID source is required, it is anticipated that the following route IDs may be supplied by the Carriers:
Commercial Carriers (air and rail) may provide their designated route IDs (e.g. the 5character train running number for rail or flight number).
Route IDs along with Country and Issuing State Codes, Port Codes, Carrier Codes are further clarified in Table 5.
Route IDs should be zero padded consistently by the Carriers for messages in the interaction lifecycle.
4.6.3 Port Codes
The HU-PIU system supports a number of port code standards, some of which are used primarily by Air, Maritime or Rail Carriers.
39 of 55
One of the following supported coding standards must be used when reporting the LastPlace/Port of Call, Place/Port of Initial Arrival and the Subsequent Place/Port of call within the country.
HU-PIU ingests the following port codes:
Air Carriers use port IDs assigned by IATA (three characters) or assigned by ICAO (four characters) location indicators.
Port codes along with Country and Issuing State Codes, Carrier Codes and Route IDs are further clarified in Section 3.7 & Table 5.
4.6.4 Scheduled Departure/Arrival Date and Time
The Scheduled Departure/Arrival Date and Scheduled Departure/Arrival Time given for a voyage must remain the same for all subsequent Check-in/Report-in, Qualified Change and Departure message submissions for the same voyage.
For example, if the Carrier reports a Scheduled Departure Date of 2014-08-27 and a Scheduled Departure Time of 1310 in its first submission of a check-in message, then all subsequent check-ins and report-ins, as well as the departure messages, must report the same scheduled date and time of operation.
Any submissions with the same Carrier and route ID but a different Scheduled Departure/Arrival Date and Scheduled Departure/Arrival Time will be treated as a separate voyage.
All Dates and Times must be reported as local time and date to both the Port of Departure and the Port of Arrival.
4.7 Country and Issuing State Codes
HU-PIU accepts the set of ISO 3166 alpha-3 codes country codes.
HU-PIU also accepts the set of ICAO Doc 9303 codes for the designation of nationality, place of birth or issuing state/authority (Reference 04). These 3-letter codes are based on the ISO 3166-1 Alpha-3 codes (Reference 03), with extensions for certain States.
An extension means either a change, e.g. for Germany the ISO 3166 alpha-3 code is DEU but for the ICAO 9303 the code is D, or a new code, e.g. UNO which designates the UN or one of its officials.
For HU-PIU, it is possible to specify Nationality or Issuing State using either the ICAO 9303 or ISO 3166 code.
Table 5 Carrier Codes, Country/Issuing State Codes, Port Codes and Route
Code Type Value
Port Codes
IATA Location Identifiers
ICAO Location Indicators
Notes for Ports:
The 3 port code standards are IATA, ICAO and UN/LOCODE.
Codes from the 3 standards are easily distinguishable: IATA is 3-chars, ICAO is 4-chars and UN/LOCODE is 2-chars, followed by a space, followed by 3-chars.
Regardless of the recommendation, a Carrier may use any of the supported port code standards.
Country Codes ISO 3166-1 alpha-3 country codes
40 of 55
Code Type Value
Nationality or Issuing State Organisation Codes
ICAO Doc 9303 Issuing (for the designation of nationality, place of birth or issuing state/authority)
or
ISO 3166-1 alpha-3 country codes
Notes for Issuing State / Nationality: -
The ICAO Doc 9303 codes are based on the set of ISO 3166-1 alpha-3 codes, with additional 'special' codes (e.g. refugee) and some changes (e.g. Germany has an ISO- 3166-1 alpha-3 code of 'DEU' and an ICAO Doc 9303 code)
Route ID’s Commercial Carrier Route ID‟s
Carrier Codes Two character IATA Carrier code
or
Three character ICAO Carrier code
4.8 API Dataset: Technical Details
The API dataset provides data on a traveller on an international voyage. Details of API data items and their definition are provided below.
4.8.1 Travel Document Type
Table 6 and Table 7 lists the Travel Document Codes that are accepted by the HU-PIU system. Both a Document Code and a Document Name are provided for each of the listed Travel Document Types. Either the Document Code or the Document Name is included in the submitted dataset, depending on which of the message formats offered by HU-PIU is utilised.
Document types as listed in Table 6, are the group of acceptable travel documents. At least one of this group must be supplied.
Table 6 Travel Document Codes and Names (acceptable travel documents)
Travel Document Type Document Code Document Name
Passport P* Passport
Group / Collective Passport G Group Passport
National Identity Card - A A* Identity Card – A
National Identity Card - C C* Identity Card – C
National Identity Card - I I* Identity Card – I
Military Identification M Military Identification
Diplomatic Passport D Diplomatic Identification
Re-entry Permit (I-327) or
Refugee Travel Document (I-571)
T Re-entry Permit
Refugee Travel PT Refugee Travel
41 of 55
Other approved identity documents used for travel.
F Other
4.8.1.1 Collective Passports
A collective passport must be reported as a ‘Group Passport’
Document Name or a ‘G’ Document Code depending on the chosen message format.
Carriers must treat each passenger reported on the collective passport as if they had their own passport. Therefore, each of the passengers is reported with same Travel Document Number and Travel Document Issuing State data items. This is the same procedure for both pre-departure and departure data submissions.
4.8.1.2 Family Passports
A family passport is one where a standard passport, reported as a ‘Passport Document’ Name or a ‘P’ Document Code depending on the chosen message format, is used as the Travel Document Type for the holder of the document and any of their children that are listed on that passport.
Carriers must report each of the passengers using a family passport as if they had their own passport. Therefore, each of the passengers is reported with same Travel Document Number and Travel Document Issuing State data items. This is the same procedure for both pre-departure and departure submissions.
4.8.2 Travel Document Number
The Travel Document Number (TDN) data item is populated with the reference number of the document used by the traveller for identification purposes on the voyage.
This data item should be populated with the reference number on the document scanned by the MRZ reader if an MRZ reader is used by the Carrier. Any extra check digit that is scanned is not to be included in the data item.
Where a travel document has no reference number of its own, such as a United Nations Laissez-passer, the reference number from the accompanying documents should be entered instead.
4.8.3 Travel Document Expiry Date
This data item is required if the travel document provides an expiry date.
The Travel Document Expiry Date data item should be populated with the date on the document scanned by the MRZ reader if an MRZ reader is used by the Carrier. Any extra check digit that is scanned is not to be included in the data item.
4.8.4 Travel Document Issuing State (IS)
HU-PIU accepts the set of ISO 3166 alpha-3 codes country codes for the Travel Document Issuing State data item. HU-PIU also accepts the set of ICAO Doc 9303 codes for the designation of issuing state/authority (Reference 04).
Issuing State Codes are further clarified in Section 3.7 & Table 5.
4.8.5 Surname
The Surname data item contains the family name of the travelling person as provided on the travel document.
42 of 55
4.8.6 Given Names
The Given Names data item contains the given names of the traveller as provided on the travel document. All given names of the traveller must be provided. At least one given name must be provided. A single letter or initial may be used only if that is exactly how the traveller s given name is listed on the travel document used for identification purposes.
4.8.7 Gender
The Gender data item contains the gender of the traveller. Specific values for submitting the Gender data item can be found in the appropriate annexe.
4.8.8 Date of Birth
The Date of Birth data item contains the date of birth of the traveller as provided on the travel document. The Date of Birth data item must coincide with the value scanned by the MRZ reader if an MRZ reader is used by the Carrier. Any extra check digit that is scanned is not to be included.
4.8.9 Nationality
Nationality of the traveller as per the travel document.
HU-PIU accepts the set of ISO 3166 alpha-3 codes country codes for the designation of Nationality data item. HU-PIU also accepts the set of ICAO Doc 9303 codes for the designation of Nationality (Reference 04).
Nationality Codes are further clarified in Section 3.7 & Table 5.
4.9 API Dataset (PNR Subset)
The following PNR datasets may also be supplied to the extent known if held within the Carriers Departure Control System.
Note: Where a Carrier is supplying PNRGov to HU-PIU, these data items become mandatory to the extent known by the Carrier:
4.9.1 PNR Locator Code
The PNR record locator is a code which is provided on both API/SI transmissions and PNR/SI transmissions. This field is mandatory for submissions relating to routes for which Carriers provide PNR data to HU-PIU.
The PNR booking record is used to report PNR data for all passengers that are part of the same booking, for instance, families or groups travelling together.
4.9.2 Initial Point of Embarkation
Port code of the initial place of embarkation.
4.9.3 Final Point of Debarkation
Port code of the final place of debarkation.
4.9.4 Transit Flag
Indicates whether the Passenger is in transit.
4.9.5 Total Luggage Weight
Weight of total luggage carried by a passenger.
43 of 55
4.9.6 No of Bags
Total number of bags carried by a passenger.
4.9.7 Bag Tags
Tag information of bags carried by a passenger.
4.9.8 Security Number
Unique number allocated by the check in desks and it identifies a passenger.
4.9.9 Baggage Details
Details of the baggage including bag destination.
4.9.10 Carrier Operator Unique Passenger Reference Identifier
Used to uniquely identify a passenger within a Carrier Reservation and DCS system. Therefore there is no repeat between flights.
5 INFORMATION EXCHANGES OVERVIEW
This section of the document outlines each of the different information exchanges that occur between a Carrier and HU-PIU. Each separate information exchange is documented in a separate sub-section below. For each exchange HU-PIU supports a number of different message formats known as profiles for the submission of the required data. The specific details about each of the supported message formats are detailed in the Interface Profile Annexes. The Carrier may submit data to the HU-PIU system in any of a range of formats. The specific format(s) to be used by a given Carrier is agreed during the Carrier Registration/Certification.
Data submission occurs at times aligned with business events dependent on the Carrier/Route messaging style. The Carrier can submit messages on a per passenger basis or may opt to send a batch of passengers in a single combined data transmission; specifics may vary with each profile and messaging style.
5.1 Commercial Aviation (API) Information Exchanges
The following section covers API information exchange for Commercial Aviation Carriers.
Table 7 Commercial Aviation (API) Supported Data Formats
Message Data Format
WCO/IATA EDIFACT PAXLST
US Variant EDIFACT PAXLST
Passenger API Check-in Yes Yes
Passenger API Departure Yes Yes
5.1.1 Check-In / Report-In Data Submissions
5.1.1.1 Passenger Check-In: Information Exchange
It is not mandatory for all passenger check-in data for one voyage to be included within a single message. Further, the details for all passengers that check-in may be provided in batches if the Carrier so chooses. However, the complete details for all passenger check-in information must be received within the agreed timescales.
44 of 55
Check-in messages are sent from the Carrier to HU-PIU via one of the transport mechanisms described in Section 3.1 and consist of the SI and API data for passengers, compiled in the chosen message format. The triggering event for the submission of passenger check-in details is a passenger, or group of passengers having checked in, their information having been processed by the Carrier, and the Carrier is ready to transmit this data to the HU-PIU system.
An overview of the Passenger Check-in Information Exchange is provided in Table 8.
Table 8 Commercial Aviation (API) Passenger Check-In
Information Exchange Name Passenger Check-in Details
Description Receive check-in details for each passenger or group of passengers
Volume and Frequency Dependent on the number of passengers travelling on routes certified using this interface and the frequency of journeys.
Initiation Event Driven Initiation Event or Trigger
Passenger or group of passengers check in and information has been processed by the Carrier.
Flow Name Request
Source System Component
Carrier System Target System Component
PIUs System
Directionality Push
Synchronicity Asynchronous Batching Single or Batch
Logical Data Model Fields SI and API data items as defined in Table 4 and Table 5
Number of passengers
Event type (check-in)
Flow Name Response
Source System Component
PIUs System Target System Component
Carrier System
Directionality Push
Synchronicity Asynchronous Batching Single or Batch
Logical Data Model Fields File name or other message identifier
5.1.2 Departure Data Submissions
At or shortly after departure (Push-Back), Carriers are required to submit a departure message consisting of TDN, Issuing State, and the SI data set. A full API submission may be provided at this time if the Carrier opts to do so, although only TDN and Issuing State are mandatory for departure submissions.
As with check-in data, the timeframe during which departure data must be submitted is configurable by the Authority. The granularity with which this configuration can occur is on a route-by-route basis for each route operated by the Carrier.
45 of 55
5.1.2.1 Passenger Departure: Information Exchange
It is mandatory for all passenger departure data for one voyage to be included within a message. The complete list of passenger departure confirmations/exceptions must be received within the agreed timescales.
Departure messages are sent from the Carriers system to HU-PIU via one of the transport mechanisms described in Section 3.1, containing voyage SI data and when required, Passenger TDN and Issuing State data compiled in the chosen message format.
The triggering event for the passenger departure details is the final list of Passengers confirmed as travelling or a list of those confirmed as not having departed being available to the Carrier.
Where this is the case it is documented in the relevant Interface Profile annex. Passenger departure submissions are provided to HU-PIU as one of the following:
Departure Confirmations
- a final list of passengers confirmed as having departed (i.e. full manifest)
Departure Exceptions
- a final list of passengers who are confirmed as having not departed
Nil Departure Exception
- confirms all passengers who previously reported; departed and only SI data is submitted
Note: HU-PIU treat any received exception message that has no matching Check-In message as an erroneous message.
An overview of the Passenger Departure Information Exchange is provided in Table 9.
Table 9 Commercial Aviation (API) Passenger Departure
Information Exchange Name Passenger Departure details
Description Receive final confirmation of passengers departed or confirm those that have not departed
Volume and Frequency Dependent on the number of passengers travelling on routes certified using this interface and the frequency of journey
Initiation Event Driven Initiation Event or Trigger
The final list of passengers confirmed as travelling is available to the Carrier.
Flow Name Request
Source System Component
Carrier System Target System Component
PIUs System
Directionality Push
Synchronicity Asynchronous Batching Single or Batch
Logical Data Model Fields SI, TDN and Issuing State as defined in Table 4 and Table 5
Other API fields may optionally be provided
46 of 55
Information Exchange Name Passenger Departure details
Number of passengers
Event type (Departure Confirmation or Departure Exception)
Flow Name Response
Source System Component
PIUs System Target System Component
Carrier System
Directionality Push
Synchronicity Asynchronous Batching Single or Batch
Logical Data Model Fields File name or other message identifier
5.2 Commercial Aviation (PNR) Information Exchanges
The following section covers information exchange for those Commercial Aviation Carriers that have been mandated to supply PNR data to HU-PIU.
PNR data submissions are required from Commercial Carriers for all HU-PIU-designated international journeys outbound from and inbound to Hungary. For each journey, two data submissions are required; a preliminary PNR data submission and a final PNR data submission. Preliminary and final PNR data submissions are subject to separate submission schedules and must be provided as separate messages at the appropriate times. Table 10 shows the supported data formats for submitting PNR data.
Table 10 Commerical Aviation (PNR) Supported Data Formats
Data Format
PNRGOV EDIFACT
PNRPUSH HU-PIU CSV
HU-PIU XML
Information Exchange
PNR Preliminary Yes Yes Yes Yes
PNR Final Yes Yes Yes Yes
5.2.1 PNR Data Submission: Preliminary Submission
HU-PIU requires that Carriers send PNR data for each passenger booked on a specific journey at a point in advance of departure which is configurable by Carrier and Route.
A Carrier may opt to send more than one message to report changes in booking data as their system receives it. An overview of the PNR Preliminary Information Exchange is given in Table 11.
Table 11 Commercial Aviation (PNR) Preliminary Submission
Information Exchange Name PNR: Preliminary
Description SI and PNR for each passenger
Volume and Frequency Dependent on the number of passengers travelling on routes certified using this interface and the frequency of journey
47 of 55
Information Exchange Name PNR: Preliminary
Initiation Event Driven Initiation Event or Trigger
The Carrier submits data in advance of departure upon timescales agreed with HU-PIU
Flow Name Request
Source System Component
Carrier System Target System Component
PIU System
Directionality Push
Synchronicity Asynchronous Batching Single
Logical Data Model Fields SI as defined in Table 4
PNR (to the extent known by the Carrier) as defined in Table 10
When submitting updates to previously reported PNR records Carriers need only submit updated elements.
Event type (preliminary)
Flow Name Response
Source System Component
PIU System Target System Component
Carrier System
Directionality Push
Synchronicity Asynchronous Batching Single or Batch
Logical Data Model Fields File name or other message identifier
5.2.2 PNR Data Submission: Final Submission
HU-PIU also requires for PNR to be submitted again during a second time period for the Voyage, after the Carrier has finished making changes to the PNR.
The Final message is the last submission of PNR data for a particular booking and voyage and should only be transmitted to HU-PIU when the known data is stable.
An overview of the PNR Final Information Exchange is given in Table 12.
Table 12 Commercial Aviation (PNR) Final Submission
Information Exchange Name PNR: Final
Description SI and PNR for each passenger
Volume and Frequency Dependent on the number of passengers travelling on routes certified using this interface and the frequency of journey
Initiation Event Driven Initiation Event or Trigger
The Carrier has finished updating the PNR information for all
48 of 55
Information Exchange Name PNR: Final
passengers on a departed voyage.
Flow Name Request
Source System Component
Carrier System Target System Component
PIU System
Directionality Push
Synchronicity Asynchronous Batching Single
Logical Data Model Fields SI as defined in Table 4
PNR (to the extent known by the Carrier) as defined in Table 10
Event type (final)
Flow Name Response
Source System Component
PIU System Target System Component
Carrier System
Directionality Push
Synchronicity Asynchronous Batching Single or Batch
Logical Data Model Fields File name or other message identifier
5.3 Message Responses and Error Handling
When a Carrier submits data to the HU-PIU system, a Transport Level Acknowledgement may be used to acknowledge message receipt.
5.3.1 Transport Level Acknowledgement
Specifics as to the behaviour of each transport level acknowledgement are dependent on both the transport protocol selected and the-specific implementation of that protocol.
For example, an FTP client from a command prompt might simply display a string such as “1234 bytes transmitted successfully”, whilst a GUI-based client might display a dialog box confirmation successful transmission. For these reasons, specifics of the transport level acknowledgement format and content are not contained in this ICD.
5.3.2 Error Handling
Hardware, communication or software failure internal to HU-PIU is managed as part of the HU-PIU management environment.
Some transport mechanisms provide limited support for error flows, mainly centred on if the data transmission was successful.
For example, the (S)FTP protocol can inform the client application if the file being transferred has been successfully transferred to the (S)FTP server.
These error flows do not contain any information pertaining to data validation or quality; they are only intended to acknowledge successful data transfer.
The data quality of transmissions received by the Carrier is monitored on an on-going basis.
49 of 55
Should negative trends be identified, these trends are reported to the Carrier along with information to aid the Carrier in determining what the root of the problem is.
HU-PIU support the native transport level error handling provided by HTTP, IBM MQ and (S)FTP.
5.4 Data Currency
5.4.1 Check-in Submissions
Check-in data is a snapshot of data captured by the Carrier for the Check-in event, and therefore data currency is not an issue. The Carrier may check-in small groups of people together (for example family group) and send this information in a batch, and the Carrier may batch the entire service Check-in information into a single message.
5.4.2 Departure Submissions
Departure information data is a snapshot of data captured by the Carrier for the departure event, and therefore data currency is not an issue. It is expected that the frequency of transfer is per departure event. The Carrier can choose to send one departure message for passengers.
The Departure Information provided by the Carrier must be correct for the departure event. The Departure Information provided by the Carrier must be within a time period from the departure event as specified by HU-PIU which is confirmed through the registration and certification process.
5.4.3 PNR Submissions
PNR data provided prior to travel is a snapshot of data captured by the Carrier. Information may be incomplete or missing for some Passengers during this time period. Data currency issues are mitigated by the provision of a second delivery of PNR data provided by the Carrier once the Carrier has finalised the PNR data content. This ensures that the system has the most complete PNR data possible for the Voyage.
5.5 Implementation
Apart from providing the interface option, HU-PIU are not responsible for an individual Carriers implementation of their chosen interface. The Carrier can choose to implement their chosen interface in any manner which is appropriate for them.
Through the registration and certification process, HU-PIU ensures that each implementation meets the standard required to allow the submission of data to the HU-PIU system prior to the issuing of credentials for access to the live system.
6 SECURITY CONSTRAINTS & NETWORKS
6.1 Protective Marking
Registration and Certification information provided by the Carrier to HU-PIU is treated as commercial sensitive and is stored appropriately.
6.2 System Security
For information concerning the security constraints to which this interface is subject, please refer to the Code of Connection.
6.3 System Access
System access is afforded to a Carrier over their chosen transport mechanism after their interface has been certified by HU-PIU.
50 of 55
Once the system has been certified, HU-PIU provides the necessary credentials and network connection information to the Carrier.
6.4 Networks
The Carrier can choose to implement this interface using the Internet or via a third party supplier such as SITA or ARINC.
The following paragraphs summarise the network connectivity options for the HU-PIU system as it pertains to Carrier interfaces.
6.4.1 Internet (Public Network)
When using a public network, any data transmitted over that network has to be secured. The security mechanism is dependent on the transport mechanism chosen by the Carrier. Details are included in Section 3.1.
The Carrier is responsible for providing within their infrastructure sufficient connections with sufficient bandwidth, performance, availability and scalability between their systems and the Internet to support the volumes of data they send to and receive from HU-PIU using these interfaces.
This bandwidth provision is in addition to any bandwidth already provisioned by the Carrier for other use.
HU-PIU is responsible for providing sufficient connections with sufficient bandwidth, performance, availability and scalability to the Internet to support the volumes of data sent to and received from the full set of Carriers using the Internet to provide transport.
6.4.2 Third-party Suppliers
The Carrier, by agreement with any third-party supplier, is responsible for providing within their infrastructure sufficient connections with sufficient bandwidth, performance, availability and scalability between their systems and the third-party supplier to support the volumes of data they send to HU-PIU using these interfaces.
This bandwidth provision is in addition to any bandwidth already provisioned for other messaging the Carrier may use the third-party supplier to deliver transformation services. It is the Carriers choice whether they wish to make use of these services to transform an output from their systems which does not meet this interface specification into an HU-PIU Interface message for onward transmission to the HU-PIU system.
Any costs associated with transformation services are the responsibility of the Carrier.
7 INTERFACE AND CONTROL
7.1 Interface Security Architecture
The obligations for the Carrier applicable to the Carrier interfaces are found in the Carrier Code of Connection.
7.1.1 Additional Information Provided to Carriers
The Code of Connection is provided during the Carrier Registration and Certification process.
Detailed instructions to establish specific connections to HU-PIU are provided in the User Guides, covering:
The URL and IP address to which Carriers connect when submitting data, as required when submitting data files via HTTP(S) or (S)FTP.
The name of the channel(s) to be used by the Carrier to connect to HU-PIU.
51 of 55
The name of the queues to which the Carrier connects when exchanging data across an MQ channel.
Potentially including the submitters registered IP address (or that of their router) for purposes of verification of sender.
Username/password assignment.
Assignment of pre-shared key credentials.
Directory/Folder naming conventions so Carriers know where to place files (applies to SFTP).
8 Managing relationship with the airlines and service providers
The PIU is the unique contact for airlines and service providers. It ensures compliance with the requirements specified by the programme relating to the transmission of data.
In order to transmit data, airlines must obtain an official accreditation of the HU-PIU, by carrying out and passing a technical certification.
The airlines may transmit the data themselves or outsource this task.
Once connected, the airlines must always ensure the proper transmission of the data required. To this end, they must set up the required technical and business processes.
When an airline expects to change a service provider or open a new route departing from, arriving in, or transiting through the MS territory, it should notify the PIU at least six months in advance if possible.
8.1 Approval process and certification
Preliminary step:
Once the legal requirement has been notified to the airline, the carrier contacts the PIU to initiate the process and implement the appropriate modalities.
Step 1: Application for accreditation
The airline registers with the PIU for accreditation. In an application form for accreditation, the airline shall specify in particular:
the coordinates of the specified contacts;
the list of routes it operates that depart from and arrive in or transit through the MS territory;
the reservation system used including the possible use of a service provider. Step 2: Validation of the application for accreditation by the Administration
The Passenger Information Unit examines and validates the application for approval filed by the airline for the transmission of PNR data. In fact, some airlines may not be able to immediately comply with all the HU-PIU requirements. In this case, the validation of the application is subject to an undertaking by the airline and a timetable for compliance.
The examination step allows validation of a data matrix for which arrangement may be made with the airline regarding the completeness of data to be transmitted. Some airlines, by their nature or by their operational constraints, may not have all the data required. In this case, the request for arrangement must be justified.
Step 3: Certification
Certification is the process of assessing the ability of a data provider to operationally connect to the system. The certification may concern either the system of an airline or that of a possible service provider to which the airline subcontracts the transmission of the data.
The certification step includes the carrying out of tests of data transmissions and their analysis.
Certification shall be carried out in a test environment where the method of connection and chosen message format are the same as that will be used in the production environment.
52 of 55
The 1st phase involves the setting up of the network between the data provider and the certification environment of the system. To this end, the elements required to configure and secure the network connection.
The data provider and the HU-PIU exchange complementary technical information such as the parameters related to the connectors used (e.g. related to the MQ server).
Once the technical connectivity phase is passed, the data provider tests include a full flight of data for all the submission times. These tests shall include all the relevant declared business models (code share, progressive flights, etc.).
In each case, the system monitors the compliance of the message with the standards (possibly amended by the specific configuration of the supplier or the route).
The data provider may have access via a GUI to specific certification tools such as acknowledgement tracking or validation report presenting the results of the analysis of the messages received by the system. Any errors found shall be corrected by the data provider, which shall be followed by re-testing, until all the cases to be processed successfully pass the tests.
Step 4: Granting of accreditation
When all functional test cases have been successfully passed, a certification assessment report is drawn up by the HU-PIU.
This step involves the provision by the HU-PIU of the temporary or permanent accreditation to the airline as well as the certification associated with the system used for the data transmission.
The approval is provisional when the airline has sought a schedule for the setup of certain routes or transmitted data. The approval is final when all the data on all the affected routes have been transmitted.
The Administration communicates its Technical Certification to the data provider, i.e. its ability to connect to the system according to the technical modalities described in the agreement between the air carrier and the HU-PIU.
The administration then schedules a date of entry into production of the data provider, i.e. the activation of its connection to the production environment of the system.
For the use of a new system, an application should be routinely made for an update of the approval and, if necessary, the certification of the new system.
In the case where the new route involves a system that is already certified for the company, no new tests need to be performed.
8.2 Management of transmission incidents
A company discovering a transmission incident in its systems shall immediately notify the HU-PIU.
An airline receiving an acknowledgment of receipt designated as "non-compliant" by the programme, shall immediately contact the HU-PIU.
A new complete transmission of the data must be made within 24 working hours on weekdays and 72 hours at weekends.
Incident management is independent of penalty management processes.
9 GLOSSARY
53 of 55
Table 13 Terms, Acronyms and Abbreviations
Term Definition
ARINC Aeronautical Radio, Incorporated
API Advanced Passenger Information
APIS Advanced Passenger Information System
BATCH MESSAGING Messaging style, where multiple passengers are included in one message. A batch message can also contain a single passenger.
CARRIER Any entity transporting individuals by means of air into or out of Hungary
CARRIER ENGAGEMENT The end-to-end process from initial engagement through to handover of the live interface into HU-PIU live service
CARRIER REGISTRATION The initial process to ensure the Carrier holds a valid Operating Licence or Air Operating Certificate
CSV Comma Separated Variable
CUSRES Customs Response
DCS Departure Control System
FTP File Transfer Protocol
GDS Global Distribution System
HTTP HyperText Transfer Protocol
HTTPS HyperText Transfer Protocol Secure
IATA International Air Transport Association – IBM MQ IBM Websphere Message Queuing also known as MQ
ICAO International Civil Aviation Organisation
ICD Interface Control Document
INTERFACE PROFILE A content format for a Carrier interface, e.g. PAXLST
IPSec Internet Protocol Security
OSI Other Service Information
PADIS Passenger and Airport Data Interchange Standards
PAXLST Passenger List
PNR Passenger Name Record
PNREXC PADIS PNR Data Exchange
SFTP Secure File Transfer Protocol
SI Service Information
SITA Société Internationale de Télécommunications Aéronautiques
SSI/SSR Special Service Information/Special Service Request
SSL Secure Socket Layer – refers to TLS v1.1
54 of 55
TDN Travel Document Number
TLS Transport Layer Security
UN/EDIFACT United Nations/EDI for Administration, Commerce and Trade
URL Uniform Resource Locator
VPN Virtual Private Network
XML Extensible Mark-up Language
XSD XML Schema Definition
44 of 44
Table 14 List of PNR topics expected by the system
Recommended