Cargo-IMP — the IATA messaging standard that still runs air cargo

Why a TELEX-era format still matters

Cargo-IMP — the IATA Cargo Interchange Message Procedures — is a flat-text, line-oriented messaging standard that IATA defined in the 1980s for sending air cargo information between parties. It was designed for TELEX. It still runs on TELEX-style transports at some carriers. And it is still the default on every airline ops desk on the planet.

Newer formats — CargoXML, ONE Record — exist and are slowly displacing parts of Cargo-IMP. But “slowly” is the operative word. A handler that wants to take cargo from any airline today needs Cargo-IMP support that is hardened, dialect-tolerant, and round-trippable. Pretending otherwise means rejecting flights.

Inbound FWB / FHL from forwarders and airlines; outbound FSU / FFM from the handler. Skidd sits in the middle as parser, canonical model, and composer.

The message family

The Cargo-IMP standard defines a family of message types, each with a three-letter code and a fixed structure. The ones a handler actually deals with daily:

Code	Name	What it carries
FWB	Freight WayBill	Air waybill details from forwarder/airline to handler — the start of every shipment. See the FWB primer.
FHL	Freight House List	House waybill manifest when the FWB is a master AWB consolidating houses
FFM	Flight Manifest	Per-flight roll-up of every shipment on board, sent at manifesting cutoff
FFR	Freight Forwarder Reservation	Booking request from a forwarder
FSU	Freight Status Update	Status transitions emitted on every state change — the spine of the 21-state workflow
MVT	Movement	Flight movement events (off-blocks, airborne, arrived)
UCM	ULD Control Message	ULD inventory and transfers between stations
UWS	ULD Stock	ULD stock balance reports
CPM	Container/Pallet Message	Loading plan for a flight — what goes in which ULD
LDM	Load Distribution Message	Weight distribution data for the flight crew

Plus a long tail of less-frequent message types — the IATA Cargo-IMP Manual runs to several hundred pages and covers every edge case from charge corrections to embargo declarations.

What a Cargo-IMP message looks like

The shape is consistent across types: a slash-separated header, then a line-by-line body. Example FSU/RCS:

FSU/16
LH4567/24APR/LHR
180-12345678LHRFRA/T2/K12
RCS/24APR0812LHRT2/12K240/M.BERG
SI/HANDLED BY SKIDD-NCE

Line 1: message type and version
Line 2: flight context (carrier, flight number, date, origin)
Line 3: AWB and routing
Line 4: status code, timestamp, location, pieces, weight, operator
Line 5: free-text supplementary information

Every message type has its own line layout, but the principle is the same: structured prefix, structured body, optional supplementary information.

Why it’s harder to parse than it looks

Cargo-IMP is a textbook example of “the standard is one thing; the production reality is another.” Forty years of accumulated dialect drift means real-world messages routinely contain:

Optional separators that one carrier emits and another forbids
Date formats that mix 24APR, 24APR26, and 2026-04-24 — sometimes in the same airline’s output
Field reordering in optional segments
Custom three-letter codes beyond the IATA-defined set, because some carrier needed a status the standard didn’t cover
Whitespace handling that varies between TELEX-origin and SMTP-origin transports
Embedded continuation lines when a message exceeds TELEX line length

A textbook parser handles 60% of real traffic and explodes on the rest. A production parser is corpus-driven — built against actual messages from actual carriers, with named test cases for each known dialect.

Transports

Cargo-IMP messages move over a few transport mechanisms, varying by airline:

Type B (SITA / ARINC) — the original TELEX-grounded carrier; still in use widely
Email (SMTP) — many carriers send Cargo-IMP messages as email bodies or attachments
SFTP — bulk delivery for high-volume integrations
Direct API push — less common for Cargo-IMP specifically; more common for ONE Record

The transport doesn’t change the message body; it just changes how the message gets from sender to receiver. A handler’s ingestion needs to handle all of them.

How Skidd handles Cargo-IMP

Three concrete commitments:

Hardened parsers across the message family. FWB, FFM, FSU, FHL, FFR, MVT, ASM are live and corpus-tested. Every parser carries named test fixtures for the dialects we’ve hit in production.
Single canonical model. Whatever message type, whatever dialect, the parsed result lands in a consistent internal shape. The 21-state engine, the rate-card matching, the storage clock, the audit log — all read the canonical model, not the raw message.
Round-trip emission. Every inbound message type can be emitted outbound in the same dialect family. FWB in, FWB out (with e-CSD OCI fields populated for EU departures). FSU in, FSU out. The same model serializes both ways.

What’s not in production: FHL/FFR outbound emission (inbound parsing is live; outbound composition is roadmap), UCM entirely (no parser yet), and CargoXML as a parallel transport (roadmap).

Where Cargo-IMP is going

ONE Record is the long-term replacement — REST-and-JSON-LD instead of flat TELEX. See the ONE Record primer for what that looks like and what Skidd ships today.

But ONE Record adoption requires both sides of every interface to support it. As long as a single major airline still ships FWBs over Type B (and they will, for years), every handler needs Cargo-IMP. The two will run in parallel for the rest of the decade. Plan accordingly.

Where to read the source

The IATA Cargo-IMP Manual is the canonical reference; it’s subscription-only and dense. IATA Resolution 670 covers the broader Cargo-IMP framework. For specific message types, individual IATA resolutions apply (e.g. Resolution 833a for FWB OCI fields). Most of what you need to know operationally, however, comes from working with real production messages — which is why Cargo-IMP work is corpus-driven, not spec-driven.