One of the most common data quality PIU problems happens when business airlines use flight identification codes that aren’t compatible with the PIU’s systems. In this article, we show how this common issue can be solved.
Key takeaways:
- Some business airlines use a flight ID (callsign) that is not compatible with API-PNR transmission requirements
- This means these airlines can not transmit their passenger data. Find out how airlines and PIU’s can ensure a compatible flight ID is used for API-PNR transmission
Every day, tens of thousands of flights around the world transmit passenger data to transport authorities (often called Passenger Information Units – or PIUs). In most cases, airlines send complete Advanced Passenger Information (API) and Passenger Name Records (PNR) to PIUs without a hitch by using standardized PAXLST and PNRGOV message formats.
However, a significant number of business and general aviation operators can not transmit these messages. One of the most common reasons is that they do not follow the API-PNR norms for carrier identification – also known as the ‘callsign’ and based on regular aviation standards. As a consequence, they can not transmit their API PNR data. For PIUs, it results in passenger data gaps and means they cannot completely fulfill their mission.
Let’s learn more about this data quality PIU problem, why it happens, and what can be done about it.
Related: 5 common data quality problems faced by PIUs
Airline identification standards in API PNR messages
Whenever an airline transmits data about a flight to a country’s PIU, the flight must be identified following a strict nomenclature. This callsign contains alphanumeric characters which identify the carrier, a flight number, and other optional information.
Flight identifiers, or callsigns, are composed of the following parts:
- An internationally-recognised airline identifier (e.g., FR is Ryanair’s IATA code, and RYR is its ICAO code)
- Flight number (usually four numbers, chosen by the airline for operational reasons)
- A suffix (up to three letters that the airline can choose for themselves)
Here is an example callsign for an Air France flight: AF2560A.
- AF = Air France’s IATA code
- 2560 = The flight number
- A = For internal Air France operational purposes
In regular aviation, all airlines have an IATA or ICAO code which is widely recognised and compatible with requirements for data quality at PIUs.
The challenges of flight identification in API-PNR data for business aviation operators
Unlike regular aviation carriers, business airlines often do not have an IATA or ICAO code. This means that these codes can’t be included in the callsign field, and so their API PNR messages wouldn’t be compliant with the PIU’s system requirements and would be rejected.
There are a couple of reasons why business and charter airlines may not have an IATA or ICAO code. First and foremost, it’s simply not mandatory to have one. Secondly, registering for a code comes at a price (for example, an IATA code costs US $6,500 in 2023). So, there is often little incentive for smaller airlines to register.
Instead of having a standard callsign, many business and general aviation companies use the following alternatives when communicating with air traffic and ground control:
- The aircraft’s registration ID (e.g. JA5578)
- Tail number of the aircraft (e.g. YUPMM)
This approach is fine when an airline is speaking to air traffic and ground control. However, the use of non-standard callsign in the API-PNR world is problematic.
Such a message is automatically viewed as erroneous because it lacks the two or three letter carrier code at the beginning. The data is rejected and the PIU considers the API PNR data to have not been received.
So, even if the airline can send complete API PNR data, the fact that the callsign is incorrect means that the data will be rejected by the PIU. And that means state authorities may miss the opportunity to catch criminals, suspects or terrorists entering their territory.
A solution to flight identification in API-PNR data for business aviation operators
The good news is that the solution to this problem is relatively straightforward.
First, an airline (in agreement with the PIU in the country it is flying to) can use a 3-letter ‘dummy’ code which looks like an ICAO code. So long as this code has not already been used by another airline, the PIU’s system could ‘read’ the callsign when it’s entered into the field, and it would not be rejected. The airline could then use the aircraft’s registration number for the rest of the callsign.
For example, a business airline based in Bulgaria that regularly flies to Hungary could contact the Hungarian PIU and propose to use the 3-letter code ‘ABC’ – not allocated to any other operators by ICAO. ’. The Hungarian PIU verifies that no other airline is using that ICAO code – and if not, agrees to this solution. The Bulgarian airline would then use each aircraft’s registration to form the complete callsign. This might look something like: ABC JA 5578. To avoid unsolvable technical problems on the airline side, the airline should use the same dummy code with all other PIUs, and PIUs should facilitate this approach.
Using an unofficial ‘dummy’ code is the best way to help airlines conform with data quality PIU requirements. In the unlikely event that another airline somewhere begins using the same airline identifier, it is very simple to just change it to a new one.
Streamlane helps you meet data quality PIU standards
At Streamlane, we help PIUs to overcome common data quality issues when airlines transmit API PNR data. When it comes to the issue of flight identification in API-PNR data for Business Aviation operators, we find that the ‘dummy’ code solution described above can provide a quick, effective, and robust solution that ensures PIUs can collect passenger data exhaustively.
Need help meeting data quality PIU requirements? Contact us today for support and advice.
