← Back to Jetstream Projects

Knowledge Base

An Introduction to IATA Baggage Messaging

Every checked bag at every major airport in the world is tracked by a messaging system built on a standard most passengers have never heard of. This is how it works.

---

The Problem Messaging Solves

When a passenger checks in a bag at London Heathrow, that bag must be screened, sorted, reconciled against the passenger's boarding status, loaded onto the correct aircraft, and — if the passenger is connecting — transferred to a different flight at a different terminal or a different airport entirely. All of this happens in a physical system of conveyors, screening machines, tilt-tray sorters, and container loading stations. None of it works without data.

The data travels as baggage messages — structured text messages exchanged between airline systems, airport systems, and baggage handling infrastructure. These messages tell automated systems which flight a bag belongs to, where it needs to go, whether the passenger has boarded, and what to do if something goes wrong.

Type B: The Transport Layer

Baggage messages travel over Type B infrastructure — the aviation industry's dedicated messaging network. Type B predates the internet. It was originally designed for teletype communication between airlines and has evolved into the backbone for operational data exchange across the industry. SITA and ARINC are the principal Type B network providers.

Type B messages are plain text, fixed-format, and line-oriented. They are not XML, not JSON, not an API call. A Type B message looks more like a telegram than a modern data payload — and that is by design. The format is compact, unambiguous, and proven across decades of operational use in safety-critical environments.

IATA RP1745: The Standard

IATA Recommended Practice 1745 (RP1745) defines the format and content of baggage messages. Published by the International Air Transport Association, RP1745 specifies three message types, a library of data elements, and the rules governing how they are assembled, transmitted, and interpreted.

The current standard is based on the PSC(30) Data Dictionary Version 1. It defines over twenty data elements — each identified by a dot-letter code (.F, .N, .S, and so on) — that can be combined in a prescribed sequence to describe every aspect of a bag's identity, routing, handling, and status.

---

The Three Message Types

RP1745 defines three message types. Together they cover the complete lifecycle of a checked bag, from check-in to arrival.

---

Message Elements

Each message is built from a sequence of elements — discrete data fields identified by a dot-letter code. Elements are assembled in a prescribed order, and each carries a specific type of information. Some are mandatory, some conditional, some optional — depending on the message type and operational context.

The most important elements:

Element	Name	Purpose
.V	Version	Message version, source type (local, transfer, terminating), originating airport, and message reference
.F	Outbound Flight	Flight number, date, destination, and class of travel for the outbound leg
.I	Inbound Flight	Flight the bag arrived on — used for transfer and terminating bags
.O	Onward Flight	Connections beyond the outbound flight
.N	Baggage Tag	The 10-digit licence plate code (LPC) that uniquely identifies the bag
.P	Passenger Name	Surname, given name, and title of the passenger
.S	Reconciliation	Authority to load (ATL), passenger boarding status, seat number, and security clearance
.D	Check-in Details	Where and when the bag was checked in, including off-airport locations
.J	Processing Info	Scan type, device ID, timestamp, and location — tracks physical movement through the BHS
.W	Weight & Type	Piece count, weight, dimensions, and bag type code for load planning
.E	Exception Data	Special handling codes: RUSH, IROP, HVY, FRAG, SCON, SPEQ
.B	Irregularities	BPM only — reports offloads (OFF), unauthorised loads (NAL), and unseen bags (UNS)
.X	Security	Baggage security screening status and results

---

What a Real Message Looks Like

A BSM for a passenger checking in two bags at Heathrow for a flight to New York:

When the bag is successfully sorted and loaded, the BHS sends a BPM back to the airline:

If the passenger fails to board, a BUM instructs the system to offload the bag:

---

The Lifecycle of a Bag

Messaging follows the bag through every stage of its journey:

At check-in, the airline's DCS generates a BSM containing the bag's tag number, the passenger's name, the outbound flight, and reconciliation data. This message is transmitted over the Type B network to the airport's baggage handling system.

As the bag moves through screening, sortation, and loading, the BHS generates BPMs at each processing point — confirming the bag's physical location and status. These messages flow back to the airline, building a complete audit trail.

If the bag is a transfer — arriving on one flight and connecting to another — the BSM includes both the inbound flight (.I element) and the outbound flight (.F element), giving the BHS the routing information it needs to move the bag between terminals or aircraft.

At gate close, the system performs reconciliation: every loaded bag must have a corresponding boarded passenger. If a passenger fails to board, the airline sends a BUM with Authority to Load set to N, and the bag is offloaded. This is not optional — it is a security requirement.

---

Why It Matters

Baggage messaging is invisible to passengers but fundamental to airport operations. A major hub like Heathrow processes tens of millions of bags per year. Every one of them is tracked by these messages. When the messaging works, bags arrive. When it doesn't — when a BSM is late, a tag number is wrong, a reconciliation message is lost — bags are mishandled, flights are delayed, and passengers are left waiting at empty carousels.

Getting this right requires deep knowledge of the standard, the systems that generate and consume the messages, and the operational reality of a live airport. That is what Jetstream Projects does.

---