AIRIMP adds support for additional passenger data

I’ve mentioned previously that airlines and computerized reservation systems (CRS’s) don’t have fields in their databases of passenger name records (PNRs) to accommodate the additional advance passenger information (API) data increasingly being requested by the USA and other governments for CAPPS-II and other “travel inteeligence gathering’ programs, such as a separate address, telephone number, and other identifying details for each passenger in a multi-passenger PNR.

I’ve also mentioned that, because PNR data typically is collected by travel agencies using different CRS’s, and transmitted to the airlines through a series of CRS and other interfaces, the first step towards including API data in PNRs would be the adoption by the airline industry associations ATA (in the USA) and IATA (worldwide) of amendments to the ATA/IATA Reservations Interline Messaging Procedures — Passenger (AIRIMP).

That process has now begun: the 28th edition of the AIRIMP effective 1 June 2004 - 31 May 2005, includes as its largest change from prior editions an entirely new section (Section 3.14, pp. 138-151) specifying formats for “interline” (between airlines or CRS’s, or including with travel agents using different CRS’s form the airline’s host system) transmission of per-passenger API data.

This does not mean that any airline or CRS is yet able to store, transmit, or receive this information. Most don’t, and wouldn’t be able to handle it. By greatly increasing the amount of data in reservation messages, inclusion of the optional data would cause many systems to truncate messages and lose reservations. The new AIRIMP message formats recognize this by forbidding the inclusion of any of this information in general messages to all airlines participating in the itinerary (through the use of the messaging wild card, airline pseudo-code “YY”), or in any case except where the sending and receiving systems have a bilateral agreement in place to allow it. Even in those cases, all of the API fields for which formats are provided are optional.

The new AIRIMP formats apply only to international flights, although there is no technical reason why they couldn’t be extended to domestic flights (as they probablywill be).

The main interest of the airlines in adding these formats to the AIRIMP (despite the airlines’ opposition to being conscripted into collecting API data not needed for their business purposes) would be that, once airline host systems and CRS’s have been modified to support the new formats, airlines will be able to shift the labor burden of API data collection and data entry from their own staff to the travel agencies who already enter most reservations, and who airlines don’t have to pay for their time.

By adopting their own standards, before being forced to do so by governments, airlines are also trying to minimize the amount of data they have to collect, and the changes to their messagiung systems required to accommodate the lengthier reservation messages. In particular, the “address” field of the new AIRIMP message format is limited to 35 characters. Considering that this needs to include a company name, house or building name (much more common in some other countries, such as the UK, than in the USA), steeet number, street name, and floor, room, or mailstop, this means that most addresses will be so severely truncated (for which no standard methodology is provided) as to make address matching difficult or impossible.

In effect, the AIRIMP messaging standards have now defined the fields that CRS’s will now start adding to their databases and interfaces, as that is possible in the course of their other work.