The CUSS Handbook / The CUSS standard (IATA RP 1706c)

The CUSS standard

CUSS stands for Common Use Self Service. It is published by IATA as Recommended Practice 1706c, and it is the document that makes a shared airport kiosk possible without every airline writing bespoke code for every machine.

What it is

The Recommended Practice describes how multiple airlines can share physical kiosks or other hardware devices in order to offer self-services to their passengers — principally check-in, and increasingly self-service bag drop. It is accompanied by a technical specification that carries the detail: the interfaces, the data model, the behaviour a conforming platform must exhibit and the behaviour a conforming application may rely on.

The current technical specification version is 2.3.2, as listed on IATA's common use standards page. Responsibility for the Recommended Practice and for maintaining its technical specifications sits with the CUSS Task Force, and the wider standards work is developed through IATA's Customer Journey Delivery Working Group, which draws its membership from airlines, airports, IATA strategic partners and industry associations.

Detail of an unbranded kiosk fascia showing scanner, card reader and document slot

The core idea

A CUSS platform is a piece of software that owns the kiosk. It presents a launch screen, it knows which airline applications are installed and available, and it brokers access to the physical devices bolted into the enclosure — the boarding-pass printer, the bag-tag printer, the barcode and document scanners, the card reader, the display.

An airline application does not talk to those devices directly and does not need to know what they are. It asks the platform for a printer; it receives an interface with defined semantics. This is what makes an application portable: the same certified application can run at an airport whose kiosks came from an entirely different manufacturer, because the platform absorbs the difference.

The consequence is that the standard's real subject is the contract between platform and application, and that contract is the part worth reading. Everything else in a deployment — hardware choice, enclosure design, network topology, commercial model — sits outside the specification.

What the standard covers

Architecture. The components a conforming platform must provide, and how an application obtains and releases them. See how a CUSS platform is put together.
Interfaces to devices. Abstractions over printers, scanners, readers and the display, so that applications are written against capabilities rather than models.
Application lifecycle. How an application is launched, how it takes and surrenders control of the kiosk, and what must happen when a session ends abnormally.
Conformance and certification. The process by which a platform is shown to run multiple applications, and an application is shown to run on multiple platforms. See certification and interoperability testing.
Operational expectations. The administrative side — availability, support and the service level agreement between the parties who share the machine.

What the standard deliberately leaves alone

It is as useful to know the boundaries. CUSS does not specify:

The airline's business logic. Fare rules, seat assignment, document checks, bag allowances and every other commercial decision belong to the carrier's own systems.
The user interface. Beyond the launch screen owned by the platform, what a passenger sees is the airline's design. This is intentional; carriers will not surrender brand presentation, and a standard that demanded it would not have been adopted.
Hardware. There is no CUSS kiosk chassis, no mandated printer and no reference enclosure. Physical design is a procurement matter, constrained instead by accessibility law and by whatever the airport specifies.
Commercial terms. Who pays for what, and how usage is recharged, is left entirely to the parties. This is one of the more common surprises for people new to the subject.
Accessibility. Conformance to CUSS says nothing about whether a machine meets the legal accessibility requirements in the jurisdiction it is installed in. Those are set by regulators, and in the United States they are set out in 14 CFR Part 382.

Versions and the generational break

CUSS has had two distinct technical generations. The first, the 1.x line, was built on interface technology of the late 1990s and early 2000s: it defined fixed interfaces using CORBA, which gave system independence and interoperability between different implementation languages, and which was a perfectly sensible choice at the time. The second, CUSS 2, is a rebuild on modern web technologies. IATA's own position is direct: most of the technologies that CUSS 1.x depended on have already reached end of life.

That transition is the single most consequential thing happening in the category, and it has published dates attached to it. It gets its own page: CUSS 2 and the move to web technologies.

Getting the document

The Recommended Practice and its technical specification are IATA publications, available through the IATA store listing for CUSS. IATA also publishes a CUSS toolkit containing the CUSS 2 specification, the API and data model definitions in YAML, a certification document template and a development guide — which between them are what an implementer actually works from.

This handbook summarises. It does not substitute. Anyone writing a requirement, building a platform or certifying an application needs the published text.