The slower-than-expected transition to ONE Record could be partly because the existing digital infrastructure continues to work. Cargo-IMP and Cargo-XML may have technical limitations, but they are deeply embedded, widely understood, and already integrated into operational systems. For many companies, ONE Record represents an additional investment before it represents a replacement or a saving. The lack of governmental regulation also reduces the urgency to change.
How an EDI connection works
EDI stands for Electronic Data Interchange and enables companies to exchange standardized electronic business documents between their systems.
IATA documentation describes PIMA (Participant Identification and Message Addressing) as one of the addressing mechanisms used for electronic connectivity in air cargo. Common messages are FWB (Air Waybill Data Message), FHL (House Waybill Data Message), and FSU (Status Update Message). PIMA addresses are issued and maintained by Cargo Community System (CCS) providers.
The format behind the message
Cargo-IMP remains in use, although its 34th edition, effective JAN15, was the last one published. Subsequent development of IATA cargo messaging standards shifted to Cargo-XML.
CHAMP introduced cargoJSON in 2017, as an air-cargo data-interchange format interoperable with Cargo-IMP and Cargo-XML through its Traxon cargoHUB. In 2020, Lufthansa Cargo’s then e-commerce subsidiary, heyworld, implemented Traxon cargoHUB using cargoJSON and an API interface.
The cost behind the communication
A forwarder does not simply buy the Cargo-IMP manual and then magically communicate with 100 airlines. It normally connects through CargoWise, CHAMP, Descartes, CCN, or another provider which can provide the messaging connectivity and, where applicable, issue and maintain the PIMA. Even if a user decides to use the free cargoJSON format, the relevant costs for their communication come from the messaging and network charges. That provider can charge for connectivity, transactions, messages, subscriptions, integration, and associated services.
If ONE Record is supposed to reduce those transaction and maintenance costs, we should look for actual evidence that a company moving from Cargo-IMP/XML to ONE Record has measured savings. So far, publicly available production use cases highlight operational benefits, but CFG found no implementation costs, measured savings, or payback periods.
From use cases to production
In 2024, IBS Software published a white paper describing several ONE Record use cases. Lufthansa Cargo also lists shipment tracking, shipment records, accompanying documents and external references.
One of the strongest examples comes from Cathay Cargo, which has published real operational implementations rather than just proposed use cases. Together with CHAMP, Swissport and WFS, Cathay put a ONE Record use case into production to exchange shipment pre-advice and booking information between the airline and ground handlers.
Cathay has also used ONE Record to provide customs-status information to forwarders. The question is whether those benefits are sufficiently different from, or better than, existing electronic exchanges to justify the investment required from each participant.
Operating with parallel systems
Despite these use cases, ONE Record can initially represent an additional cost rather than a replacement, as existing systems may need to continue operating in parallel.
IBS explicitly says in its white paper, that partners will not migrate simultaneously and that ONE Record servers therefore need to continue interfacing with legacy standards. The resulting legacy workarounds are likely to be labor-intensive and costly. IBS recommends operating ONE Record in parallel with existing systems until the new system is validated.
Benefits and regulations
ONE Record does solve problems that EDI does not: common semantics beyond individual messages, distributed data ownership, richer shipment information, standardized APIs, security and access control, and potentially better real-time data availability. Those benefits are real. But are they sufficiently valuable today, to justify the switching cost for each individual participant?
Companies do not ask whether regulations such as PLACI (Pre-Loading Advance Cargo Information) produce an attractive ROI before complying with them. If they operate in jurisdictions with PLACI requirements, compliance is mandatory. ONE Record, by contrast, has largely had to win investment through its business case. No country or regulation currently forces companies to adopt it. Without that regulatory push, each participant has to decide whether the benefits justify the cost of migration.
The transition may therefore depend on reaching a point where maintaining the legacy environment becomes less attractive than moving away from it. Until then, the question for individual companies remains the same: what measurable benefit do they receive from making the investment now?
Yes, traditional IATA Messaging called Type B (Cargo-IMP and Air IMP) have their drawbacks: Network-related transactional or link-management cost, capacity restrictions to 4K, limited data security, latency, and flexibility. This was identified in a white paper by IATA and also more recently by T2RL https://t2rl.net/insight/display?ID=831 and applies to Cargo as much as Passenger Distribution, or Flight Operations. OneRecord is an intriguing idea, yet only brings the desired effects, if EVERYONE in air cargo joined at the same time. To share status information and most other elements among participants could still be done with Cargo IMP. What people call ‘API’ is generally wrapping just Type B information through a fixed-link. Also, the management of access to everybody in the OneRechord supply chain is no easy feat as every shipment could have a completely different chain of stakeholders along its way. So it remains a one-to-one integration among the participants which only pays off the top tier parties in airlines, forwarders and ground handling. Local monopolies like Cathay or Singapore Airlines have a better sway to ‘convince’ the community. Our EDIfly community provides a one-to-many platform that takes Type B CIMP away from the legacy networks in SITA or Collins (ARINC): EDIfly provides: No capacity restrictions (1-2GB per transaction), real-time transmission, end-to-end encryption, no transaction-related cost, flexible integration of TypeB:JSON and Type B:XML, and seamless implementation based on the existing addresses in Type B using its smart and true community exchange mechanism automatically connecting every EDIfly user with any other user across the internet for limitless transactions without any changes to existing applications.