Rwanda is embarking on a traveller data programme with the objective of enabling it to better managing its borders. In support of this strategy the Rwanda Directorate General of Immigration and Emigration (DGIE) requires that all air, land and maritime carriers provide traveller information for all persons being transported to and from Rwanda.

This guide recognises that airlines will be the first adopters of this system and that other transport services do not have the necessary systems and infrastructure in place. Those other carriers will be addressed in a separate document.

Please review the Carrier guidance for more information.

API is required for all flights to and from Rwanda. For both crew and passengers. Data shall be sent in accordance with the UN/EDIFACT PAXLST message format described in this document.

The transmission of Interactive API (iAPI) is now required for all travellers flying to and from Rwanda. Airlines must request permission to issue a board pass to a passenger. The DGIE will provide a response within the current IATA guidelines such that the airline should, in normal circumstances, receive it within seven (7) seconds of the Check-in request.

The use of iAPI removes the requirement to send an API PAXLST at Check-In close. A final API transmission on departure / at “Off-Blocks” with the consolidated details of all passengers on board is required.

NB:

Final API transmission should be transmitted at “Off-Blocks ” (immediately after the flight takes off from the point of embarkation)

The implementation of API is an ICAO “Standard”, that is, States are required to implement API. (ICAO Annex 9 Facilitation 15th Edition, ICAO Montreal October 2017) to which Rwanda is a party to.

The API program aims at helping countries to investigate and prosecute acts of terrorism as well as serious and cross border crimes that may be posed by travellers.

Law n°57/2018 of 13/08/2018 on immigration and emigration article 36 and Ministerial Order N°06/01 of 29/05/2019 article 57 relating to Immigration and Emigration provides for obligations of transport companies to present to an immigration officer information on incoming or outgoing passengers as may be required by the Directorate General.

Article 36: Obligations of transport companies. Any company that transports people, prior to exit or entry, presents to an immigration officer information on incoming or outgoing passengers as may be required by the Directorate General. The Directorate General may issue instructions waiving the requirement of providing the passenger information, depending on the particular nature of the passengers or the transport companies.

Article 57: Passengers and crew information. A transport company transmits in advance all information relating to its passengers and crew before entry or departure from the country. Such information may be in form of advance passenger information and names or any journey record; of which usage, privacy, transmission and sharing modalities are determined by relevant laws.

Reporting timelines and format of the information required are provided by the instructions of the Directorate General. The Directorate General through the Government may enter into agreement with countries and a community on processing and transfer of Passenger Name Record data by air carriers and Advance Passenger Information

Article 60: Refusal or delay to provide information related to passengers. An air transport company that does not comply with the provisions of Article 57of this Order commits a fault and is liable to a fine of two million Rwandan Francs (FRW 2,000,000).

https://www.migration.gov.rw/fileadmin/templates/PDF_files/Official_Gazette_no_Special_of_30.05.2019_IMMIGRATION.pdf

In addition to providing passenger information, airlines shall inform passengers the purposes of collecting the data, namely the prevention of illegal immigration through better border controls, and how they can contact the airline for further details. Furthermore, the airline shall inform the passenger about the following:

1. what information is collected

2. who are the recipients of the data (the Rwanda border control authority)

3. the right of the passenger to view their information and seek correction if the passenger information is incorrect (if the data has not already been destroyed).

I. Introduction

Before API data is sent to the National Passenger Information Unit (NPIU) of the Rwanda Directorate General of Immigration and Emigration (DGIE), the airline should register with the API program. This shall done through the Air Liaison Officer of the NPIU. A test phase shall be planned and if transmission is successful a notification will be sent by the NPIU to the airline confirming that the airline complies with the requirements for sending API data.

II. Registration

Airlines can register themselves by contacting liaison@migration.gov.rw

Airlines shall include the following information in their registration:

1. Carrier Name

2. Contact details of the person responsible within the carrier for their API programme including:

   • Name

   • Job Title

   • Email address

   • Telephone numbers

3. Anticipated start date from transmission

II.1 Test phase 

The test phase will be scheduled with the airline by the NPIU and Service Provider.

Testing will continue until:

1. Transmission format is correct for sending and receiving information.

2. Information is received according to the data requirements posted in this implementation guide.

Test API transmission requires the utilisation of real data from the airline’s operational system. If the airline wishes to carryout preliminary testing using their test system this will be allowed, final acceptance must however be completed from their production system as per above.

If an airline starts operations from a new airport then testing using the same hosted departure control system, testing in advance is not necessary.

For new departure control system then testing is required.

II.2 Airline Connection Process

The following process for connecting airlines shall be applied:

1. After registration the NPIU will contact the airline to plan the test phase.

2. Test data will be sent to the test address KGLATXH.

3. Operational data (live data) will be sent to the test address for 1 week or until successful.

4. Operational data (live data) will be sent to the production address for 1 week.

5. Testing will continue until transmission is working properly and data requirements are received in good order and can be processed without problem.

I. API Transmission

API data should be sent using the IATA Type B message format as UN/EDIFACT PAXLSTs as defined by the ICAO, IATA and WCO standard.

For more information about the UN/EDIFACT PAXLSTs, please refer to Annex III Rwanda PAXLST

Message Implementation Guide.

The IATA address of the API production system is: KGLAPXH

The IATA address of the API test system is: KGLATXH

API data must be sent twice at:

• First transmission shall be at Check-In closure, and

• Second transmission shall be at “Off-Blocks.”

Note: That when using iAPI the first transmission shall be when the traveller checks in for their flight and the requirement for a batch transmission at Check-in close is not required, however a second transmission shall be required at “Off-Blocks”.

II. iAPI Transmission

iAPI data should also follow the UN/EDIFACT PAXLSTs standard, however, the preferred transmission method is MQ Queue to Queue.

A single iAPI message per passenger is preferred. When sending multiple travellers in a single iAPI transmission a single CUSRES response is returned for each passenger.

II.1. iAPI Testing Procedure

Testing instructions in brief:

1. Send using IBM MQ Q2Q ensure unswitched MQ channels with both send and receive queues are provisioned to ARINC’s network.

2. Check that all the required data is included in the passenger list (see the API factsheet).

3. Check that the passenger list is in the correct format.

4. Send as a test iAPI check-in requests for two separate flights, using you planned production message transmission medium, with fictitious passenger details. The first flight should contain less than five passengers and the second flight more than 80 passengers.

5. Verify that you have received a CUSRES message with a traveller status from the DGIE Traveller Screening System.

6. Later, the status of one passenger from a previously transferred flight will be changed, and the DGIE Traveller Screening System will send an Unsolicited CUSRES message that the status has been changed.

7. Ensure the Unsolicited CUSRES message is received from the DGIE Traveller Screening System, the new traveller status is recorded in your system, and that an Unsolicited CUSRES was sent from your system to notify that the message is received.

8. The DGIE airline liaison team will inform you promptly, if the tests were completed successfully.

I. General

The Rwanda NPIU requires the following data:

• travel document type

• travel document number

• nationality

• name (family and given names)

• date of birth

• gender

• issuing State of the travel document

• expiry date of the travel document

• flight number

• departure time of transportation

• arrival time of transportation

• total number of passengers carried on that transport

• border crossing point of entry into the territory

• initial point of embarkation

• place/port of onward foreign destination (Routing Information)

• Passenger Name Record (PNR) locator number

• Unique Passenger Reference

• Number of Bags

• Bag Tag Identifiers

• Seat Number

Passengers are required to have a travel document that is valid for 6 months from the date of entry into Rwanda.

iAPI Messages

Check-in request/approval messages will be exchanged between the Passenger Services Check-in System, otherwise known as a Departure Control System (DCS) and DGIE Traveller Screening System.

iAPI should be sent as UN/EDIFACT PAXLSTs as defined by the ICAO, IATA and WCO standard (the Guidelines on Advance passenger information (API) prepared by WCO / IATA / ICAO. Edition of 2013 APPENDIX IIA. WCO/IATA/ICAO PASSENGER LIST MESSAGE (PAXLST) IMPLEMENTATION GUIDE).

In normal operation at check-in the DCS sends a request permission to carry a traveller using an iAPI message in the UN/EDIFACT PAXLST format using the BGM+745 Document Identifier.

iAPI should be sent using an un-switched IBM MQ connection (known as Q2Q).

The AIS APPDP receives API and iAPI PAXLST messages through the telecommunication network operated by Collins Aerospace/ARINC.

II. API and iAPI Message Headers

II.1. API Message Header

The following message header values should be used when sending API-data to the Rwanda border authorities:

• UNB Segment Interchange Recipient ID Element: RWNPIU

• UNG Segment Application Recipient ID Element: RWAPINPIU¹

Airlines are obliged to send information from passengers, including transit passengers, crew and off duty crew. Off duty crew travelling are considered to be passengers.

II.2. iAPI Message Details

The following message header should be used when sending iAPI-data to the Service Provider of the Rwanda border authorities:

• UNB Segment Interchange Recipient ID Element: RWNPIU

• UNG Segment Application Recipient ID Element: RWIAPINPIU¹

Airlines are obliged to send check-in requests for all passengers, including transit passengers, crew and off duty crew. Off duty crew travelling are considered to be passengers.

It is recognised that some airline systems are unable to use different values for the UNB Segment Interchange Recipient ID Element and the UNG Segment Application Recipient ID Element. In this case the value should be the same for both elements.

II.2.1. Information about PAXLST messages and CUSRES responses.

Responses to Carriers will be sent using the UN/EDIFACT CUSRES format as defined by the ICAO, IATA and WCO standard (the Guidelines on Advance passenger information (API) prepared by WCO / IATA / ICAO. APPENDIX IIB. WCO/IATA/ICAO API RESPONSE MESSAGE (CUSRES) IMPLEMENTATION GUIDE).

iAPI PAXLST BGM+745 Check-in requests messages should preferably be sent as discrete a message for each traveller, both crew and passengers, as they check-in to facilitate traveller processing.

Multiple passengers may be sent in a single PAXLST BGM+745 message provided they are traveling on a single booking. But Carriers should take into account that the check-in response time may increase beyond the 4-7 second window. In this case AIS APPDP will return statuses of the passengers in a single CUSRES response for each passenger.

For example, if Carriers send a passenger and a lap infant in a single PAXLST message, DGIE Traveller Screening System will return their status in a single CUSRES response.

The DGIE Traveller Screening System will return an iAPI CUSRES response with the traveller Check-in status to the originator using the same method on which they were received.

“OK to Board” and “Not to Board” are currently the only two status options which the DGIE Traveller Screening System will return in a CUSRES response:

• 0 = “OK to Board”. Passenger cleared. Boarding pass may be issued.

• 1 = “Do Not Board”. Passenger not cleared to board. Boarding pass issuance 'Inhibited'.

Only a CUSRES BGM+962 message with the passenger status will be sent without a preliminary confirmation of receipt (a sample acknowledgement of receipt message).

The target time for an end to end iAPI response is no more than 7 seconds, In the event that the airline does not receive a response to an iAPI Check in request after 8 seconds the airline may issue a boarding pass.

If a “Do Not board” notification is received prior to departure the airline should make all reasonable efforts to prevent boarding or remove the traveller from the plane.

II.2.2. Unsolicited Response (Intervention Post Check In, widen scope of intervention).

Circumstances may require the authorized authority of the Republic of Belarus to change the status of a passenger, particularly when a “cleared” status has been issued.

In this case an Unsolicited CUSRES message will be send from AIS APPDP to the Carrier.

The Carrier will provide an Unsolicited CUSRES message back to the AIS APPDP.

III. Biographical and Document Elements

Airlines are obliged to send data identical to that in the travel document that will be used to enter Rwanda or to transfer in Rwanda. All travel document data must be compliant with the relevant ICAO 9303 standards.

III.1 Passengers with Multiple Passports

In the case of a passenger travelling with an expired passport with a valid visa and valid passport, the details of the valid passport shall be provided.

In the case of a person holding multiple nationalities and travel documents, the API-data from the travel document that the passenger intends to use to enter or transfer through Rwanda shall be provided.

III.2 Date of Birth

The default format is ‘YYMMDD’ (n6). For example a person with a date of birth of August 19th 2002 would be represented as ‘020819’. Care should be taken to ensure manually entered dates are sequenced correctly and in particular that the day and month are not transposed.

III.3 Credited Children

Some countries provide passports in which several people are listed such as the spouse and/or children. API-data shall be collected for every person who travels. The Machine Readable Zone contains only the data of the passport holder. The information of the people credited must be entered manually with the same travel document details, however, the biographical details must be that of each individual traveller.

III.4 Progressive Flights

In case of a flight with two or more sectors, API-data is only required from the sector prior to arrival in Rwanda, but must be provided from all passengers on board from the sector prior to arrival in Rwanda. The airline is responsible for ensuring that travellers who disembark and re-embark at intermediate stations are the same persons who originally boarded the aircraft prior to the stop over.

III.5 Crew/Off Duty Crew

All the above data requirements also apply to crew and off duty crew. The airline should send a discrete PAXLST for crew using the appropriate code in the Implementation Guide. In that case the airline is asked to differentiate the flight reference with the letter ”C” after the flight number.

Off duty crew are treated as passengers, including those that are “positioning.”

III.6 Code share flight

The airline operating the flight is responsible for collecting and sending the API data, the flight number must be that of the operating airline.

III.7 Inbound/Outbound

API data is required for flights inbound and outbound to and from airports in Rwanda.

III.8 Accepted Document Types

Document types as per ICAO 9303 are accepted by the API program. The airline shall collect and provide the travel document type the passengers will use for transferring or entering Rwanda.

IV. Technical Failure

API and iAPI data are required at all times. If for any technical reason no data can be sent, the airline shall give prior notice to the authority via the following email addresses:

1. npiu@migration.gov.rw

2. liaison@migration.gov.rw

In such cases the airline shall resend the data at the earliest possible time. For review with airlines.

V. General Aviation

General Aviation will be required to send API and iAPI in future.

1 If your DCS system is unable to correctly support UN/EDIFACT standards then the value of UNB Segment Interchange Recipient ID Element may be used.

Failure to comply with this notification of requirement will lead to administrative sanctions as laid down in Ministerial Order Number 06/01 of 29/05/2019.

The sanctions are specified in Article 60 of the above Order for liability concerning the obligation to communicate passenger information.

In order to avoid data errors that could lead to fines, it is recommended that where possible airlines use electronic reading (swipe) of the Machine Readable Zone of the travel document.

The airlines will receive monthly feedback about their general performance by email. When mistakes are spotted, airlines will be contacted as soon as possible to intervene.