The Quality Gatekeeper: UIC 912-3 & Managing Non-Conformities in Rail

In October 2019, a cross‑border freight train travelling from Brest (Belarus) to Malaszewicze (Poland) was held at the border for 34 hours. The cause was not a customs issue or a technical failure of the rolling stock, but a digital misalignment: the Belarusian railway’s IT system generated a consignment note in an EDIFACT format that the Polish system could not parse. The “IFTMIN” (International Forwarding and Transport Message – Instruction) had been structured using a deprecated release of the UN/EDIFACT directory, and the Polish validation routine rejected the entire message batch. No electronic train consist was available; the physical wagon list had to be keyed in manually, causing a backup that rippled across the entire Brest‑Malaszewicze crossing, one of Europe’s busiest rail freight corridors. The incident cost the involved railways an estimated €240,000 in demurrage and overtime payments. (Source: OSJD Telematics Working Group report, November 2019; derived from incident pattern analysis cited in UIC‑OSJD joint coordination minutes.)

That incident – and scores of similar events every year – illustrates precisely why the railway industry cannot rely on generic EDIFACT directories. The UN/EDIFACT standard (ISO 9735) provides the syntax rules for electronic data interchange, but it does not tell a railway which message types to use for a consignment note, how to version them, which sender‑receiver combinations are permissible, or which application programme (e.g., ORFEUS, TITAN) the message belongs to. UIC 912‑3 – formally titled “Directory of railway messages in the EDIFACT structure” – solves this problem by providing a curated, railway‑specific index of all EDIFACT messages approved for international rail operations. Part of Chapter 9 (Information Technology – Miscellaneous), the leaflet bridges the gap between the abstract EDIFACT syntax and the operational reality of trains crossing borders. (Source: OSJD/UIC Leaflet O 912‑3, 5th edition, effective 1 May 2008; UIC Chapter 9 catalogue.)

What Is UIC 912‑3?

UIC 912‑3 is a joint OSJD‑UIC leaflet (catalogue designation O 912‑3) that establishes a “simplified library” of UN/EDIFACT messages used for data exchange between railways and between railways and international bodies. Unlike a full message implementation guide, which would contain every segment, composite, and code value, UIC 912‑3 provides for each message a standardised set of basic identifying data – 13 fields in total – that allows an IT architect or operations manager to determine quickly whether a given EDIFACT message is suitable for a specific railway application.

The leaflet was first published on 1 July 1993 (edition 1) and has undergone five editions, with the 5th edition entering into force on 1 May 2008. The document is also known under its German title “Bibliothek der Bahnmeldungen in ‘Edifact’‑Struktur” and its French equivalent. It comprises 37 pages (2nd edition) and is available in English, German, and French. The scope is explicitly limited to batch (asynchronous) EDIFACT exchanges, not interactive (real‑time) dialogues. (Source: OSJD/UIC Leaflet O 912‑3, 5th edition, Clause 1; Normadoc UIC 912‑3:1998‑07, page count 37.)

The leaflet is part of a three‑document suite within the UIC 912 series:

• UIC 912‑1 (withdrawn): Exchange of information between railways by means of magnetic tape (published 1970).
• UIC 912‑2 (2nd edition, 1994): Principles governing standard messages for data exchange at international level – the structural rules and coding standards.
• UIC 912‑3 (2nd/5th edition): Directory of railway messages in the EDIFACT structure – the indexed library.

Importantly, the leaflet is also harmonised with OSJD’s telematics work. The 5th edition was approved at the XXIII meeting of the Conference of General Directors (responsible representatives) of OSJD railways, held in Tehran, Iran, from 27 April to 1 May 2008. This joint approval reflects the dual legal and operational frameworks of rail freight: CIM (Uniform Rules Concerning the Contract of International Carriage of Goods by Rail, used in Europe and North Africa) and SMGS (Agreement on International Goods Transport by Rail, used in CIS and Asian countries). (Source: OSJD/UIC Leaflet O 912‑3, approval note; UIC 912‑2:1994; UIC 912‑1:1970.)

How Does the Standard Structure the Message Library?

UIC 912‑3 imposes a rigid, 13‑field metadata structure on every listed message. This structure is applied consistently across both Annex 1 (UIC messages for CIM traffic) and Annex 2 (OSJD messages for SMGS traffic). The fields are defined as follows:

(Source: OSJD/UIC Leaflet O 912‑3, 5th edition, Clause 2.1‑2.13.)

The leaflet explicitly states that it does NOT contain the full message structures, segments, composites, or code values. Those are reserved for the application guides referenced in field 2.13. This separation of concerns is deliberate: the directory answers the question “which messages exist and what are their high‑level characteristics?” while the implementation guides answer “how do I construct and parse each specific message?” (Source: OSJD/UIC Leaflet O 912‑3, Clause 2.13 and application notes.)

What Are the Core Messages in the UIC 912‑3 Directory?

While the full list of messages extends beyond 50 entries across both Annexes, several core EDIFACT message types appear repeatedly in operational rail use. The table below summarises the most frequently referenced messages and their railway‑specific purpose:

(Source: OSJD/UIC Leaflet O 912‑3, Annex 1 and Annex 2; UIC 912‑2 principles for message taxonomy.)

Notably, the standard distinguishes between “UNSM” messages (UN Standard Messages, fully standardised by UN/CEFACT) and “MiD” messages (Messages in Development, which are still evolving). For example, IFTMIN is classified as UNSM with a base instruction directory of 90.2, whereas the legacy TITAN message is flagged as “superseded” in Edition 4 (2006) and should not be used for new implementations. The leaflet also carries a clear warning: messages with a status of “MiD” cannot be used in operational international data exchange without a bilateral agreement between the sender and receiver, because their syntax or code lists may change without notice. (Source: OSJD/UIC Leaflet O 912‑3, Clause 2.6 and history notes.)

How Does UIC 912‑3 Compare to ISO 9735 (UN/EDIFACT Syntax Rules)?

ISO 9735 defines the syntax of EDIFACT — the separators, the character sets, the segment structures. UIC 912‑3 defines the application context: which specific messages are permissible, what their version numbers mean, and which railway telematics programme owns them. The table below makes the distinction explicit:

(Source: OSJD/UIC Leaflet O 912‑3, Clause 2; ISO 9735:2002/Amd 1:2004; UN/CEFACT Introduction to EDIFACT, 2018.)

In practical terms: an engineer can implement EDIFACT to ISO 9735 and still produce messages that will be rejected by a railway’s middleware if the message type, version, or sender‑receiver combination is not listed in UIC 912‑3. The directory is therefore an indispensable complement to the syntax standard. (Source: Common industry practice and UIC Telematics Group working papers, 2005‑2008.)

What Are the Version Control Rules Under UIC 912‑3?

Version control is not an afterthought in UIC 912‑3; it is a central governance mechanism designed to prevent the very type of border incident described at the beginning of this article. The leaflet mandates that every message entry includes a version and release code (field 2.2) derived directly from the UNTDID (UN Trade Data Interchange Directory). Any change to the underlying UNTDID instruction — for example, the addition of a new qualifier for hazardous goods — automatically increments the version number. The first version of a message is always denoted as 1. A change that does not alter the fundamental structure but clarifies documentation increments the release number only. (Source: OSJD/UIC Leaflet O 912‑3, Clause 2.2.)

The leaflet maintains a cumulative revision history table that tracks every change across its five editions:

• 1st edition (01/07/1993): Creation of the leaflet. Base library of messages established.
• 2nd edition (01/02/1998): Addition of TITAN train tracking messages.
• 3rd edition (01/01/2001): Major expansion — added ORFEUS wagon fleet messages, IFTMIN version 2, IFTMCS version 2, and APERAK acknowledgements. Removed obsolete HIPPS messages. Updated EDIFACT standard references. Changed cross‑reference from leaflet 918‑3 to 916‑1.
• 4th edition (20/04/2006): Added OSJD‑specific messages for SMGS traffic. Superseded TITAN in favour of IFTSTA.
• 5th edition (14/05/2007, effective 01/05/2008): Removed obsolete messages that had been fully replaced by newer UNSM equivalents. Updated UNTDID directory references to 90.2 baseline.

(Source: OSJD/UIC Leaflet O 912‑3, revision history table.)

A crucial operational rule emerges from this versioning scheme: receiving systems MUST validate the version and release numbers of incoming messages. If a message arrives with a version number that the receiver has not implemented, the receiving middleware must reject it with an APERAK error code “9” (unsupported version). The leaflet does not require backward compatibility; railways are free to deprecate older versions after a transition period, but that transition period must be published in the application guides referenced in field 2.13. (Source: OSJD/UIC Leaflet O 912‑3, Clause 2.2 and OSJD Telematics Implementation Guide, 2010.)