Information for Part 135 Operators

History

U.S. Customs Service, in cooperation with the U.S. Immigration and Naturalization Service (INS) and the airline industry, initiated development of APIS as a voluntary program in 1988 to collect biographical information (name, date of birth, nationality, etc.) from air passengers prior to departure for the U.S. from foreign locations.

U.S. Customs, in cooperation with the governments of Australia and New Zealand, developed the Electronic Data Interchange for Administration, Commerce, and Trade (EDIFACT) message format for the initial implementation of the Advance Passenger Information System (APIS) in the early 1990s. This message format is referred to as United States/Electronic Data Interchange for Administration, Commerce, and Trade (US/EDIFACT) and is currently being supported by the new Customs & Border Protection (CBP) for use by air carriers.

On February 18, 2002, the CBP began issuing fines of up to $10,000 to Part 135 operators that did not electronically transmit a passenger and crew manifest to CBP in advance of arrival to the U.S. The requirement was published in the December 31, 2001 Federal Register as an “interim regulation” and became effective immediately.

On May 14, 2002, the “Enhanced Border Security and Visa Entry Reform Act of 2002” instituted a similar INS requirement for both inbound and outbound flights. The deadline for the electronic transmission of manifests was to be January 1, 2003. However, the final regulation, 8 CFR 231, implementing the Border Security Act was never issued.

In April 2004, new Security Directives and Emergency Amendments were released that required carriers that follow a security program like the Twelve-Five Standard Security Program to electronically provide a Master Crew List (MCL) and Crew Manifest data to the TSA. If an operator had an IATA code, that code was to be used. Otherwise, carriers had to obtain an APIS Carrier Code from CBP using a CBP “APIS Registration Form.”

On April 7, 2005, Customs & Border Protection (CBP) released the final rule, “Final Rule.” This rule codified current reporting requirements existing in TSA Security Directives and CBP regulations, and introduced additional reporting requirements required on and after June 6, 2005.

In order to satisfy Advance Passenger Information (API) legislative requirements, CBP established a migration time from US/EDIFACT to United Nations EDIFACT (UN/EDIFACT). UN/EDIFACT was adopted by the United Nations Economic Commission for Europe (UN/ECE) and modified by the International Air Transport Association (IATA) for use by all air carriers worldwide. A rule also established a conversion date of October 4, 2005 for the UN/EDIFACT transmission format for aircraft manifests. UN/EDIFACT requires additional crew member and passenger information, which is outlined in the final rule. Effective October 4, 2005, commercial operators must make an APIS transmission using the UN/EDIFACT format, which captures additional passenger information. The NBAA APIS Submission Service did not use this format and no longer met APIS requirements.

Tail Number vs. Flight Number

Since the APIS program was originally set up to accommodate airline passenger transmissions, the EDIFACT message format is tailored for airline flight numbers. This causes several problems for the general aviation (charter) community.

Most charter operators will use a tail number, or “N” number, for identification of flights and will enter the tail number as the flight number.

If an operator submits an outbound and inbound APIS using the same tail number as the flight number, the APIS program cannot differentiate between incoming and outgoing flights. The APIS program is actually set up to allow for operators to append their lists and add passengers without having to make a whole new submission. Since the flight number is the same tail number, the CBP system assumes an operator is trying to add passengers and will add all the passengers to the first flight submitted.

Scenario: A charter operator has two flights in the same day. One that leaves West Palm Beach for Freeport, in the Bahamas, and one that leaves Freeport for Fort Pierce in Florida. The operator logs on to the eAPIS system and enters the passenger and crewmember information for the first flight using the tail number, N123AB, as the flight number. The operator then makes the submission for the second flight from Freeport to Fort Pierce with different passenger information again using N123AB as the flight number.

Outcome: When the operator arrives at Fort Pierce for the inbound flight, a CBP inspector can’t find any passengers listed on that flight because the computer system added it to the first flight. Since the second submission went into the APIS system with the same flight number (N123AB) the computer took this to mean that the operator wanted to add the new passengers to a previous submission. CBP may fine the operator for failing to provide passenger information.

Another issue that compounds the problem is that tail numbers usually contain both numbers and letters. The letters at the end of the tail number can be interpreted incorrectly in the EDIFACT message format. Currently, the EDIFACT message format takes the APIS carrier code, the flight number, and a command letter and adds them together to make a single data set.

For example: An operator’s carrier code is 426 and the flight number is 3597. The operator inputs the carrier code and flight number into eAPIS. Using the EDIFACT message format, eAPIS will generate a passenger transmission with “4263597” as the specific data set, and a crew transmission with “4263597C” as the specific data set.

The command letter “C” added to the end of the carrier code and flight number identifies the transmission as a crew transmission. There are other commands within the EDIFACT message format. For example, “CC” added to the carrier code and flight number set means that the transmission is a crew change.

Scenario: A charter operator’s carrier code is 333. The operator inputs that carrier code and uses the tail number “N123TC” as the flight number. The passenger transmission would have an identification data set go through as “333N123TC” and the crew transmission would have the identification data set go through as “333N123TCC.”

Outcome: The CBP computer system cannot correctly process these data sets.

The computer cannot tell if the tail number is “N123T” with a command code of “C” for a crew transmission or “N123TC” with no code for a passenger transmission.

The computer may also interpret the transmission as “333N123TC” being the crew transmission, and the true crew transmission (333N123TCC) as being a request to change the crew.

Solutions

Solution 1: Change the EDIFACT message format.

Since the new UN/EDIFACT was adopted by the United Nations Economic Commission for Europe (UN/ECE) and modified by the International Air Transport Association (IATA) for use by all air carriers worldwide, changing this system is not easy. It is close to impossible.

Solution 2: Have charter operators use flight numbers for all flights.

Though not technically required by regulation, this is the easiest solution.

Pick a system that works for your operation and use it. One suggestion would be to use odd flight numbers for outbound flights, and even flight numbers for inbound flights. If more than one outbound or inbound flight will take place with the same aircraft, ensure that a different flight number is assigned to that flight.

The APIS process is reset each night at mid-night; therefore, you are able to use the same flight numbers, each separate day. If you have flights that operate near the mid-night hour, it is suggested you avoid duplicating flight numbers in this hour timeframe.

Non-IATA Airport Codes

When using eAPIS, operators must use the three-character IATA code for the last foreign port of departure, prior to clearance in the United States. Operators must also use the three-character IATA code for the United States departure airport.

Not all airports have an IATA code. If departing from a United States airport with no IATA code, enter the nearest airport to your departure airport that has a code.

If departing a foreign airport for the United States that does not have an IATA code, enter “XXX” as the departure airport code.

Timeline

February 18, 2002

CBP begins issuing fines to Part 135 operators that do not electronically transmit a passenger and crew manifest to the CBP in advance of arrival to the U.S. This requirement was published in the December 31, 2001 Federal Register (47 KB PDF File) as an “interim regulation” and became effective immediately. See the APIS penalty fact sheet for more information on fines.

May 14, 2002

Enhanced Border Security and Visa Entry Reform Act of 2002 (92 KB PDF file) institutes a similar Immigration and Naturalization Service (INS) requirement for both inbound and outbound flights.

January 3, 2003

INS publishes a proposed rule Manifest Requirements Under Section 231 of the Act (80 KB PDF File) which officially states that the INS will not impose any fines until a rewritten 8 CFR 231 is published as a final rule.

June 23, 2004

Air carriers must use unique carrier codes when electronically transmitting APIS data to CBP.

April 7, 2005

CBP publishes Final Rule that is effective June 6, 2005.

October 4, 2005

APIS transmissions must use the UN-EDIFACT format.

July 14, 2006

Customs and Border Protection released a Notice of Proposed Rulemaking (116 KB, PDF) in the July 14, 2006 Federal Register which proposes to change the timeline for APIS submissions for international Part 135 flights.

August 23, 2007

Customs and Border Protection releases a Final Rule (220 KB, PDF) implementing changes to the timeline for APIS submissions for international Part 135 flights.

September 8, 2009

NBAA partners with ARINC Direct to offer Members an electronic APIS Transmission Service.