Recommended Practice 1717 (Passenger Services Conference, IATA), formally designated PSC(30)1717, is the industry recommended practice that standardises the Teletype Passenger Manifest (TPM). The TPM is a structured Type B teletype message that provides a name list of disembarking passengers when required by government authorities. It is classified as Type B and appears in the Passenger Services Conference Resolutions Manual (PSCRM) as part of the family of passenger-handling messages that also includes RP 1717a (PAXLST Message), RP 1718 (Passenger Transfer Message), and the RP 1719 series.
Although ICAO Annex 9, Chapter 2, states that Contracting States shall not require the presentation of a Passenger Manifest, some governments continue to request a name list of arriving or disembarking passengers. RP 1717 ensures that, when such a list is required, airlines transmit it in a single, globally recognised format rather than in varying national or ad-hoc formats.
Origin, Status, and Relationship to Other Standards
The TPM was developed as a practical operational message within the classic IATA Type B teletype environment. It complements the more data-rich UN/EDIFACT PAXLST message standardised under RP 1717a, which is the preferred vehicle for modern Advance Passenger Information (API) programmes. Where a simple name list is still mandated, the TPM remains the industry standard.
It is used alongside other post-departure messages such as the Passenger Transfer Message (PTM – RP 1718), Passenger Service Message (PSM), and various reconciliation and sales messages in the 1719 series. Construction rules for individual elements (especially the Name Element) cross-reference RP 1707b (Data Element Directory for DCS Passenger Messages).
The practice is of indefinite duration. While many carriers have migrated API reporting to PAXLST or interactive API, the TPM continues to be generated and transmitted by departure-control systems for destinations that still require a basic name-list manifest.
Purpose and Scope
The purpose of the TPM is to provide a standardised name list of disembarking passengers to government authorities (or, in some operational contexts, to the destination station for handling purposes) immediately after flight departure.
Scope is limited to a passenger name list. It does not carry the full suite of biographic, document, or itinerary data found in PAXLST/API messages. It is intended solely for those situations in which a government requires a simple list of names of passengers who will disembark at a given station.
Technical Structure and Message Format
Recommendation
In order to provide government authorities requiring a name list of disembarking passengers, Members shall use a standard Teletype Passenger Manifest (TPM) as described in the Recommended Practice.
1. General Description
- Definition – The Teletype Passenger Manifest (TPM) provides a name list of disembarking passengers where required by governments.
- Time of Dispatch – The TPM is dispatched immediately after flight departure.
2. Detailed Specifications – Message Elements
A TPM message consists of the following mandatory elements (constructed according to the rules in RP 1707b where referenced):
| Element | Description | Notes |
|---|---|---|
| Address Element | Destination address(es) of the message | Standard IATA Type B addressing |
| Communications Reference Element | Originator address and timestamp | Standard Type B format |
| Message Identifier Element | “TPM” | Identifies the message type |
| Flight Element | Flight number, date, destination station, and part number (if multi-part) | e.g. NW055/13MAR MSP PART1 |
| Name Element | One passenger (or family group) per line | Surname/First name or initials/Title; family groups may be listed together with a leading count |
| End Element | “ENDTPM” (or ENDPARTn for multi-part messages) | Closes the message |
Name Element Rules
- Mandatory.
- List on a separate line for each passenger the surname, first name/initials/title.
- Construction follows RP 1707b Name Element rules.
- Examples:
1NIGHTINGALE/FRANKMR4HOPKINS/GEORGEMR/MARYMRS/DAVIDMSTR/SUSANMS
Multi-part Messages
When the passenger list is long, the TPM may be split into PART1, PART2, etc., each ending with the appropriate ENDPARTn indicator; the final part ends with ENDTPM.
Example Message
FIHKPSR
.ZRHKMSR 260710
TPM
2R345/29NOV FIH PART1
1GAMBOT/JANICEMS
1HIGGINS/HENRYMR
4KOCH/RICHARDMR/DIANAMRS/KRISMR/KIMMS
ENDTPMImplementation in Airline Operations
Departure Control Systems (DCS) automatically generate the TPM from the final boarded passenger list once the flight has departed (doors closed / actual off-blocks or equivalent trigger). The message is addressed to the government authority or station address that requires the manifest and is transmitted over the Type B network (or equivalent modern gateway).
Operational notes typically include:
- Generation only for stations/governments that still require a name-list manifest.
- Immediate post-departure timing so that the destination has the list before or shortly after arrival.
- Retention of the message (or the underlying data) in accordance with airline record-keeping and any applicable regulatory retention periods.
- Coordination with ground-handling agents at stations where the DCS is operated by a third party.
In modern environments the same data source that feeds the TPM often also feeds PAXLST/API messages; the TPM is simply the residual simple-name-list format retained for legacy government requirements.
Relationship to ICAO Annex 9 and Modern API
ICAO Annex 9 explicitly discourages the requirement for a passenger manifest. Where States nevertheless continue to request one, RP 1717 provides the only standardised industry response. For full biographic and document data, governments are expected to use the PAXLST message (RP 1717a) or interactive API in accordance with the WCO/IATA/ICAO API Guidelines. The TPM therefore functions as a minimal, legacy-compatible solution rather than a substitute for proper API programmes.
Benefits
- Airlines – Single, predictable format instead of multiple national list formats; automated generation from the DCS; reduced risk of non-compliance where a name list is still mandated.
- Governments – Receipt of a consistently structured name list immediately after departure.
- Industry – Clear demarcation between the simple name-list requirement (TPM) and the richer data requirements of modern API (PAXLST), supporting orderly migration toward electronic passenger data exchange.
Auditability and Compliance
Compliance is demonstrated by:
- Correct construction of the message elements according to RP 1717 and RP 1707b.
- Timely dispatch immediately after departure.
- Accurate reflection of the final boarded passenger list.
- Proper addressing to the required government or station addresses.
- Message logs and retention records.
Conclusion
Recommended Practice 1717 – Teletype Passenger Manifest (TPM) remains the industry standard for transmitting a simple name list of disembarking passengers when a government still requires such a list. By defining a clear message structure, mandatory elements, naming conventions, and immediate post-departure timing, it ensures consistency and operational efficiency in a residual use-case that ICAO Annex 9 itself seeks to eliminate. In the broader passenger-data landscape it coexists with the far richer PAXLST message (RP 1717a) and the interactive API programmes that have become the norm for border-control data exchange.
Sources include the published text of RP 1717 (PSC(30)1717), related RP 1707b element definitions, IATA Ground Operations Manual references, ICAO Annex 9, and operational implementations of Type B passenger messages. Full proprietary specifications reside in the IATA Passenger Services Conference Resolutions Manual.
