Recommended Practice 1718 – Passenger Transfer Message (PTM)

Recommended Practice 1718 (Passenger Services Conference, IATA) is the industry recommended practice that standardises the Passenger Transfer Message (PTM). The PTM is a Type B teletype message used to advise down-line stations (and, where required, airport systems) of the number and identity of passengers transferring from an arriving flight to specific onward flights. It is listed in the Passenger Services Conference Resolutions Manual (PSCRM) immediately after the TPM (RP 1717) and PAXLST (RP 1717a) messages and forms part of the core suite of post-departure passenger-handling messages.

Origin, Status, and Relationship to Other Standards

The PTM was developed within the classic IATA Type B messaging environment to give transfer stations timely, structured information about connecting passengers. It is generated by the departure-control system of the inbound flight and is addressed to the transfer/connecting station (and often to the operating carriers of the onward flights).

It is used in conjunction with:

• RP 1717 Teletype Passenger Manifest (TPM) – simple name list of disembarking passengers.
• RP 1715 Passenger Service Message (PSM) – special-service and assistance information for disembarking and transferring passengers.
• Baggage messages (especially BSM/BTM under RP 1745) that handle the corresponding transfer bags.
• Modern airport operational databases and AIDX/flight-message feeds that may ingest or re-publish PTM content.

The practice is Type B (recommended) and of indefinite duration. While many airports and airlines now also exchange transfer data via XML (AIDX) or proprietary interfaces, the PTM remains the universal Type B standard that every DCS can generate and every station can receive.

Purpose and Scope

The purpose of the PTM is to provide the transfer station with advance notice of:

• Which passengers (by name or by count) are connecting from a specific arriving flight.
• The onward flight(s) to which they are transferring.
• Basic passenger counts (adults, and in some implementations children/infants) per onward flight.

This information allows the transfer station to:

• Plan gate, bus, and staff resources for connections.
• Coordinate with the operating carriers of the onward flights.
• Support passenger and baggage reconciliation for connecting traffic.
• Feed airport operational systems and transfer-display products.

Scope is limited to transfer passenger data linked to a specific inbound flight segment. It is flight-segment-oriented: the message identifies the arriving flight leg and then lists the onward flights and the passengers (or counts) transferring to each of them.

Technical Structure and Message Format

The PTM follows the standard IATA Type B message conventions (addressing, communications reference, end-of-message indicators, multi-part handling). Core elements include:

Message Identifier
PTM

Flight Identifier (inbound)
Airline designator + flight number + scheduled local date of departure + boarding-point airport code + transfer-point airport code + part number (if multi-part).
Example form: mm(a)fff(f)(a)/ffaaa aaa PART1

Transfer-to (onward) data
For each onward flight:

• Operating connecting flight identifier (airline + flight number + optional date).
• Destination airport of the passenger.
• Passenger name string(s) as they appear on the ticket (can contain multiple names).
• Passenger counts (commonly adults; some implementations also carry child/infant counts).

Timing
The PTM is dispatched immediately after flight departure (doors closed / actual off-blocks or equivalent DCS trigger), the same timing used for the TPM.

Multi-part and cancellation logic
Long lists may be split into PART1, PART2, etc. Operational systems treat the absence of transfer-to data (or an explicit cancel) as an instruction to delete previously received PTM data for that inbound flight.

Modern airport data dictionaries (e.g., Avinor ADD) model the PTM as a FlightSegment-oriented entity containing one or more TransferTo data sets, confirming that the industry continues to treat the message as a structured transfer advice rather than a simple free-text list.

Implementation in Airline and Airport Operations

Airline / DCS side

• The departure-control system automatically builds the PTM from the final boarded passenger list and the recorded onward connections.
• The message is addressed to the transfer station’s Type B address (and often to the onward carriers).
• Generation occurs immediately after departure so that the connecting station receives the information before or shortly after the aircraft arrives.

Transfer station / airport side

• The PTM is ingested by the station’s DCS, airport operational database, or resource-management system.
• Counts and names are used for transfer-passenger planning, gate allocation, and connection monitoring.
• Data may be correlated with baggage transfer messages (BSM/BTM) and with special-service information arriving via the PSM.

Ground-handling context
The IATA Ground Operations Manual and airport Conditions of Use commonly list the PTM among the mandatory or expected post-departure messages that must be sent to the airport/handling agent (alongside MVT, LDM, PSM, etc.).

Benefits

• Transfer stations – Early, structured visibility of connecting passenger volumes and identities; better resource planning; improved connection success rates.
• Onward carriers – Advance notice of inbound connecting traffic.
• Airports – Feed for operational systems, transfer displays, and performance monitoring.
• Industry – A single, universally understood Type B format that every airline DCS can generate and every station can process, reducing the need for proprietary transfer advices.

Relationship to Other Messages and Modern Interfaces

The PTM focuses on transfer passenger identity and counts. Complementary information travels in:

• PSM (RP 1715) – special-service requirements of those same transferring passengers.
• BSM/BTM (RP 1745) – the corresponding transfer bags.
• TPM (RP 1717) – the full name list of all disembarking passengers (when required by governments).
• PAXLST (RP 1717a) – full API data for border authorities.

Many airports now also receive equivalent transfer data via AIDX or other XML/JSON interfaces; the PTM remains the fallback and the common denominator for interline and third-party handling environments.

Auditability and Compliance

Compliance is demonstrated by:

• Correct construction of the message according to RP 1718.
• Timely dispatch immediately after departure.
• Accurate reflection of the final boarded connecting passengers and their recorded onward flights.
• Proper addressing to the transfer station and relevant carriers.
• Message logs and retention in accordance with airline and station procedures.

Conclusion

Recommended Practice 1718 – Passenger Transfer Message (PTM) provides the standardised Type B mechanism for advising transfer stations of connecting passengers immediately after an inbound flight departs. By linking an arriving flight segment to the specific onward flights and the passengers (or counts) transferring to each of them, the PTM enables timely operational planning, supports passenger and baggage reconciliation, and remains a core element of interline and airport handling messaging. Even as richer XML interfaces proliferate, the PTM continues to serve as the universal, DCS-native transfer advice recognised across the industry.

Sources include the IATA PSCRM listing for RP 1718, operational descriptions and data-dictionary mappings of the PTM, airport Conditions of Use that mandate the message, IATA Ground Operations Manual references, and related Type B passenger-message standards. Full proprietary specifications reside in the Passenger Services Conference Resolutions Manual.