The NDC capability matrix
The certification levels people still quote were retired in 2022. What a flight product needs instead is a matrix: the dimensions on which one carrier's NDC connection differs from another's, because those differences decide what your checkout and your support team can do.
“Is this airline NDC?” is a question with no answer in it. The useful question is a list of about eleven, and the level number people still quote to avoid asking them stopped existing four years ago.
The levels are gone, and have been since 2022
On 19 November 2021 IATA announced it was scrapping the NDC certification process and replacing it with the Airline Retailing Maturity index, folding the ONE Order registry into the same new registry. Travel Weekly reported that the existing NDC registry would be sunset the following October. IATA's own ARM index factsheet now states the outcome flatly: “the former NDC and ONE Order certification registries have now been superseded by the ARM index.” IATA's NDC registry and NDC certification URLs both return 404.
What was retired is narrower than the shorthand suggests. By IATA's 2019 programme guide, Level 1 had already been withdrawn; what remained was NDC Certified at Level 2, 3 or 4 for airlines, sellers and aggregators, NDC Capable at the same levels for IT providers, plus NDC@Scale as a separate top status first awarded to British Airways and Iberia on 19 December 2019. Level 4 meant eight XSD files: AirShoppingRQ and RS, OrderCreateRQ, OrderViewRS, OrderChangeRQ, OrderReshopRQ and RS, and OrderChangeNotif. The guide is unusually blunt about scope: it validated that message structure followed the schema, and “does not validate the content of the Applicant's messages, or the quality or other aspects of the Applicant's activities or products.” Eligible schemas ran from PADIS 17.2 to ATSB 19.2.
So a 2026 claim of “IATA NDC Level 4 certified” points at a programme IATA stopped running in 2022 and describes a structural test against schemas from 2017 to 2019. It is not a lie. It is simply not about anything your product does. We have used the level vocabulary as shorthand ourselves, in why NDC will not solve your immediate problems, and it has aged out.
What replaced it is a matrix, on purpose
ARM measures three things, of which one is public. Capabilities Verification is published. Partnerships Deployment, covering connectivity, volumes and partner feedback, and the Value Capture Compass, a self-assessment survey, are visible only to the airline itself. IATA refuses a single number because “a single score would mask the areas in which an airline has made progress.” That refusal is correct, and it is why nobody quotes ARM the way they quoted Level 4: there is nothing to quote.
The public half is genuinely useful. On 5 August 2026 the registry listed 184 companies: 82 airlines, 49 system providers for sellers, 32 system providers for airlines and 21 sellers, with 20 rows expired. Capabilities Verification covers 75 codes across six streams, weighted 22 Shop, 22 Order, 12 Pay, 12 Setup, 4 Settle and 3 Account. An entry is a dated capability table: workflow group, capability, schema version, entry date, confirmed-live tick, plus a named partner list. No level, no grade, no score.
Two caveats before anyone treats it as gospel. IATA “does not re-verify the capabilities or supporting documents in question at any time after the initial capability entry date,” and annual renewal is self-attestation, so a 2021 entry date against a 2026 expiration means verified once, five years ago. And participation is voluntary: Delta, JetBlue, Southwest, Ryanair, easyJet, Air New Zealand, Norwegian, Volaris, Azul and GOL return zero matches, while several are bookable NDC content elsewhere. The registry is a floor, not a census.
The cliff is in the data
Read the airline column and the shape of the problem falls out. Eighty of the 82 listed airlines have verified “Shop for Flights.” Forty have verified “Seller-Initiated Change to an Order Requiring a Reshop.” Servicing is verified for exactly half as many carriers as shopping.
It thins further down. Only 16 airlines hold reshop, cancel and refund at once, and 17 can reshop a change with no verified refund behind it. Fifty-five can notify a seller of an airline-initiated change, but 21 of those have no verified way to reshop afterwards: a disruption message arriving with no API path to rebook. Three have verified “Historical Information on Orders,” the message an agent uses to catch up on changes nobody told them about. And zero have verified the three capabilities covering commercially messy servicing: change or cancel with penalties applied, with forfeited amounts, or producing a reusable amount. Those are exactly the cases where money moves in a direction someone has to explain to a customer.
Those zeroes mean not verified, not proven impossible. That is the point. Nobody publishes what you need, so you derive it.
The matrix
Here are the dimensions that separate carriers, what varies on each, and what to make someone show you. I am deliberately not scoring named airlines: any such table is stale within a release cycle, and the honest version is the one you build from your own tests.
| Dimension | What varies between carriers | What good looks like | Evidence to ask for |
|---|---|---|---|
| Shopping and content parity | Per-bound versus whole-itinerary offers; whether the direct channel's full fare range reaches the API; brand inclusions written as free text inside the price class | Whole-itinerary offers with explicit combinability, brand contents as coded services | Responses for a return, an open jaw and a multi-city, plus the fare families not in NDC |
| Ancillaries and seats | IATA calls this the area with the most variation: services can arrive in five different messages, packaged or a la carte, and baggage is often disclosed with no purchasable item behind it | Everything sellable available from the offer you already priced, with taxonomy codes | The ancillary catalogue, the message each item comes from, and whether ServiceList is required |
| Order creation | Instant payment versus hold; one offer per transaction on some platforms; group and infant limits; OrderID format, which IATA says only a handful of implementations follow | An order you can create, retrieve by your own reference and reconcile | Production hold duration, the offer time limit returned in shopping, and a real OrderID |
| Servicing depth | Whether post-sale actions are symmetric with booking. On one widely deployed platform you can add seats and ancillaries to an order but not change them, and cannot void after a reissue | Every action available at booking still available after it | A written list of post-sale actions supported in the API, by fare type and market |
| Involuntary and disruption | OrderChangeNotif implementation differs airline by airline; waiver codes block automation; most sandboxes do not support disruption at all | Notification and rebooking on one connection, no waiver code, no portal | A sandbox disruption run: cancel a segment, rebook, watch the paid seat and bag |
| Refunds and exchanges | IATA's refund-processing accelerator says airline solutions for voluntary changes vary and scenarios are “not always supported in the API, requiring TMCs to use airline portals and phones”; it asks airlines to support refunds for partially flown segments and refunds including ancillaries, which implies neither is a given | Refund quote and execution in-API, with tax, fee and penalty breakdown | A refund on a partially flown itinerary carrying an ancillary, end to end |
| Interline and codeshare | ARM defines an interline capability in the Shop stream and none in the Order stream: there is no box to tick for servicing an interline order. Travelport's developer documentation states plainly that “NDC does not support interline connections” | Honest scoping: interline shopped, or not offered | Which segments this connection can service after departure day, in writing |
| Payment model | Set by airline policy under Resolution 890, not by the schema. One major platform takes one form of payment per transaction, cash or card only, no vouchers or multi-FOP | Your settlement method, in your markets, with 3DS handled | Accepted forms of payment by market, and whether agency cards are permitted |
| Ticketing authority | An explicit per-airline switch held in BSPlink; your accreditation tier gates which forms of payment you may use at all | Authority granted before you build, not after | Ticketing authority and BSP or ARC status confirmed per airline, before integration |
| Schema version and cadence | Entries span 17.2 to 26.1. Backward compatibility is guaranteed only from 21.3 forward, only for seller-to-airline offer and order messages, never for interline. Deprecation runs at XPath level | 21.3 or later across the whole surface, with a stated upgrade path | Version per message, not per airline, and the deprecation list for fields you map |
| Sandbox and certification | Documentation ranges from PDFs to wikis to Postman collections; some sandboxes lag production; some carriers publish the certification scenario list and some do not | Sandbox parity with production, published scenarios and limits | The test scenario list up front, plus rate limits and error-case guidance |
What the matrix cannot see from outside
Two carriers on the same platform can be a schema generation apart. Singapore Airlines publishes an Amadeus Altéa NDC OrderChange guide at 18.1; TAP Air Portugal publishes the same message at 21.3, and the documents are 78 and 209 pages, stamped February 2022 and May 2024 respectively. Even inside one airline the surface is not uniform: Singapore Airlines' NDC catalogue lists its message guides at 18.1, with OfferPrice additionally published at 21.3 and AirlineProfile at 20.2, and it keeps OrderCancel because 18.1 predates the decommission of OrderCancelRQ/RS in 21.3. “We integrate Amadeus NDC” tells you nothing about which XML you will parse. Nor is a version label sufficient: the older releases put plain message names under a per-release namespace, so Singapore's 18.1 OrderChange sits in http://www.iata.org/IATA/2015/00/2018.1/OrderChangeRQ, while TAP's 21.3 equivalent is IATA_OrderChangeRQ under the EASD namespace. Different element naming, different hierarchy, and migration is a breaking change at the parser. And 17.2 is still the centre of gravity, verified by 92 of the 184 ARM entries.
IATA has written the rest down already. Its implementation-variations paper reviewed more than 90 specific integration challenges caused by airlines implementing the same standard differently, and traces them to duplication, optionality and interpretation. The sharpest line is about absence: when a field is missing, a seller has no protocol-level way to tell whether that is a technical failure, genuine unavailability, or deliberate omission to shrink a payload, and there is no mechanism to find out. IATA's own conclusion is that “each integration requires customization on a per-airline basis.”
Disruption is where the matrix earns its keep
Lufthansa Group publishes a two-column matrix comparing NDC 17.2 with 24.1. Involuntary cancellation after a change and involuntary date change are marked not supported in 17.2 and supported in 24.1; ancillary reassociation after a change is work in progress in both. The same carrier group behaves differently for the same disruption depending on which version you integrated against. The same matrix notes that its SPRK agent interface is “usable, but may break Order integrity,” which is a candid way of saying the manual fallback is not free.
Its 24-page schedule-change and irregularity policy for travel agents does not mention NDC once, and its refund appendix is a table of waiver-code entries for Amadeus, Sabre, Galileo/Travelport, Infini, TravelSky and SPRK. That is the waiver-code problem IATA names in its own accelerator list, sitting in a live carrier policy, and it is why aggregator promises to normalise servicing across participating airlines rest so heavily on the last two words. Normalisation at the aggregator layer cannot manufacture a capability the airline API does not expose.
None of this is fringe. NDC was 21.6% of all ARC-settled transactions in June 2026, and range-bound for months: 20.8% in March, 20.1% in April, 21.6% in May. Roughly one in five settled US agency transactions sits in an order whose servicing depth varies carrier by carrier.
What to put in the RFP
Most carrier questionnaires ask which version and which messages, get an answer and learn nothing. The questions that separate carriers are narrower and more awkward:
- Show me a full change on a paid order in the sandbox, including the seat and bag I bought, and tell me what happens to them.
- Which post-sale actions require a waiver code, a portal login or a phone call? Name them.
- What is your refund coverage on partially flown itineraries, and on ancillaries?
- If the traveller changes the booking on your website, do I keep receiving updates?
- Which segments of an interline or codeshare itinerary can this connection service after departure?
- What is the schema version per message, and what is the upgrade schedule?
- Which forms of payment are accepted, in which markets, and are agency cards permitted?
- What does your sandbox not support that production does?
Every one of those has a disqualifying wrong answer, and none can be satisfied by a badge. If a carrier or an aggregator will not answer in writing, that is the answer.
The line worth holding
The industry glosses over the fact that the comparison a product team needs is a commercial asset. Travelport publishes a public NDC matrix, but it covers a couple of dozen carriers on shopping-side attributes; the detailed per-airline capability articles sit behind a customer login. IATA's registry shows only what each company self-declared and never re-checked. So every integrator rebuilds the matrix privately, at cost, and then treats it as proprietary. That is a bad equilibrium and it is worth naming.
What follows is unglamorous and durable: assume the matrix is jagged, keep it out of your checkout, and make every capability a property of the order rather than of the protocol. Where that abstraction belongs is argued in NDC, GDS or LCC direct; here it is why 517+ carriers across NDC, GDS and LCC sit behind one offer and order shape. A checkout that asks “can this order be changed” survives the next schema generation. A checkout that asks “is this NDC” was already wrong in 2022.
Sources
- IATA, Guide to NDC Certification Program (the retired programme, levels and message lists)
- Travel Weekly, IATA replacing current NDC certification process, 19 November 2021
- IATA ARM index registry
- IATA, Airline Retailing Maturity index programme terms and conditions, May 2026
- IATA, Airline Retailing Maturity index factsheet (three pillars, what is public)
- IATA, Implementation Variations in Distribution Standards
- IATA AIR Tech Zone, Accelerating TMC Adoption
- IATA, 21.3 Enhanced and Simplified Distribution implementation guide
- British Airways, BA and Iberia achieve IATA NDC@Scale certification, 19 December 2019
- Singapore Airlines, NDC API catalogue (message guides by version)
- TAP Air Portugal, Amadeus Altéa NDC OrderChange 21.3 implementation guide
- Lufthansa Group, NDC capabilities matrix
- Lufthansa Group, schedule change and irregularity policy for travel agents
- Travelport, NDC guide
- ARC, June 2026 air ticket sales
- ARC, March 2026 air ticket sales
- ARC, April 2026 air ticket sales
