New Distribution Capability

Like time, technology waits for no one. Today’s newest tech becomes tomorrow’s legacy systems, and there are some interesting stories to be told when the two meet. The banking, gambling, and travel industries all have examples of this, and not just at the technical level (think about the regulations and laws that were written for these industries as they existed decades ago, but that are still in place today). For this post, we’ll focus on an example from the travel domain, specifically the New Distribution Capability (NDC). To start, let’s first look at how things worked before the NDC was introduced.

A brief history on flight reservations

Air travel of course existed before the mid 1900s, but it was around that time that it became more comfortable and affordable. Booking a flight in those early days was a manual process. Paper ledgers of various kinds were used to track reservations, and phone calls or visits to a travel agent were pretty much mandatory. As you can imagine, those processes were time consuming and error-prone, and automated systems entered the scene in the 40s and 50s. It wasn’t until the 1960s that the first computerized reservation system was introduced. This system, called SABRE (Semi-Automatic Business Research Environment), was originally developed by American Airlines and IBM.

SABRE was operational in 1964, and other reservation systems were developed throughout the years by other airlines and companies in the travel industry. These systems evolved largely independently until the late 1970s, although many were based on IBM’s products. In 1978, the US deregulated the airline industry which introduced more competition, but it also created an opportunity for airlines to share their reservation systems and data with others. It was around that time that some of those systems went from being computer reservation systems (CRS) to global distribution systems (GDS). CRSs still exist today, but they’re supplier-specific, whereas GDSs pull in data from multiple suppliers.

The EDIFACT standard

The Electronic Data Interchange for Administration, Commerce, and Transport (EDIFACT) standard is a structured way for computer systems to communicate. It was created around 40 years ago because all of those systems we just mentioned (among others) didn’t have a standard way of sharing data. Each system used its own naming and formatting for orders, invoices, etc., which made exchanging data across systems difficult and error-prone. EDIFACT established a standard format for sharing travel data, which helped reduce the friction.

EDIFACT is a text-only way for sharing information. It can handle things like airport codes and customer ID numbers, but not images or videos. This wasn’t an issue when EDIFACT was created, but images and videos are a huge part of advertising and selling travel these days (think about all the visuals used for displaying seat charts, meals, hotel amenities, etc.).

While it defined a standard, EDIFACT is implemented in different ways. There are numerous optional fields, and some implementations require certain fields that others don’t. These discrepancies resulted in companies writing message implementation guides (MIGs) explaining how their implementation of EDIFACT worked. Even with these MIGs, if you have to integrate with multiple systems, each with their own EDIFACT implementation, it can be a big pain. On top of that, the standard itself isn’t human-readable, so it’s difficult to work with.

1UNB+UNOA:1+US::US+50138::THEM+140531:0305+001934++ORDERS'
2UNH+1+ORDERS:91:2:UN'
3BGM+220+A761902+4:20140530:102+9'
4RFF+CT:EUA01349'
5RFF+AAV::C'
6TXT+THIS IS WHAT AN EDI MESSAGE WOULD LOOK LIKE... '
7NAD+BY++OUR NAME PLC::::+++++EW4 34J'
8CTA+PD'
9COM+01752 253939:TE+01752 253939:FX+0:TL'
10CTA+OC+:A.SURNAME'
11COM+2407:EX'
12CTA+TI+:B.BROWN'
13COM+0:EX'
14CTA+SU'
15COM+0161 4297476:TE+01752 670633:FX'
16UNT+15+1'
17UNZ+1+001934'

Example EDIFACT message (source)

EDIFACT is still entrenched in the travel ecosystem in spite of the difficulties of working with it. You may not have integrated directly with a system that used the standard, but you might have integrated with an API that does. For example, many travel APIs provide endpoints for pulling flight times, seat charts, etc. Some of those APIs take in your request and then transform it into EDIFACT-compatible messaging to retrieve the information from downstream systems.

Even though EDIFACT is still used today, it’s not the only standard for exchanging travel data. Over a decade ago, an updated approach was kicked off that resulted in the NDC.

New Distribution Capability

The International Air Transportation Association (IATA) established the NDC standard in 2012. This association recognized the difficulties with EDIFACT, and set out to create an updated standard that was technologically up to date and that better fit how travel is sold.

On the technology side, NDC is essentially an XML standard. This has huge benefits because it supports rich content. XML is also widely used so it’s familiar to developers, and it’s machine and human-readable.

1...
2<Party>
3    <Sender>
4      <TravelAgencySender>
5        <Name>JR TECHNOLOGIES</Name>
6        <IATA_Number>20200154</IATA_Number>
7        <AgencyID>00010080</AgencyID>
8      </TravelAgencySender>
9    </Sender>
10  </Party>
11  <Query>
12    <Order>
13      <Offer OfferID="PRICEDOFFER1" Owner="C9" ResponseID="213-9b453cddea3f4fae95fc7c057bf1b1f2">
14        <TotalOfferPrice Code="EUR">746.09</TotalOfferPrice>
15        <OfferItem OfferItemID="OFFERITEM1_1">
16          <PassengerRefs>SH1</PassengerRefs>
17        </OfferItem>
18      </Offer>
19    </Order>
20...

Truncated NDC example

The NDC standard is structured around concepts like offers and order management, which align with how travel is currently sold. Offers can be updated in real time, have dynamic pricing, and can be tailored to specific customers. They include options like seat selection, baggage limits, and other add-ons and product offerings. Order management relates to the full booking lifecycle. It involves creating and modifying bookings, coordinating payments, and fulfilling travel.

What all this means for airlines is that they can control how their products are packaged and sold. In EDIFACT-based flows, airlines can only pass on a limited set of data (basic flight and fare information, static prices, etc.). This data typically goes to a GDS who then builds the offer and shares it with travel sellers. In NDC-based flows, airlines create their own offers and share them with OTAs, GDSs, etc.

From the travel seller side, you generally access NDC data through an API regardless of the provider. The differences are in who built the API and how they’ve designed it. The core options are:

• Integrating with a GDS that, in turn, has integrations with individual airlines. You only maintain the integration with the GDS.
• Integrating with an aggregator that, in turn, has integrations with individual airlines. You only maintain the integration with the aggregator.
• Integrating directly with airlines that have NDC APIs. You maintain integrations with the individual airlines.

One of the challenges for OTAs and other travel sellers is that they have to integrate with so many partners. They usually work with multiple GDSs and numerous suppliers (individual airlines, hotels, etc.) to provide their customers with the most options. This is where Evervault comes into the picture.

How Evervault helps businesses sell travel

Travel sellers often partner with multiple suppliers to fulfill bookings. OTAs, for example integrate with airlines, hotels, car rental agencies, etc. The data requirements for building those integrations vary greatly, and often include raw card data (although it doesn’t have to anymore) or personally identifiable information (PII). Evervault helps bridge the gap between these integrations while reducing compliance scope.

On the payments side, Evervault has UI components for collecting card information, as well as a secure proxy for sharing card data downstream with suppliers, payment service providers, and related parties. These solutions help reduce PCI DSS scope because you don’t interact with raw card information.

While Evervault supports straightforward proxying, that’s often not enough. If you need to transform sensitive data (e.g., reformatting PANs for your PSP, generating credit card authorization forms), you can use Evervault Functions instead. Functions allow you to work with sensitive data within Evervault’s ecosystem without touching the raw data yourself. As long as you can write the logic in Python or JavaScript, you can run it in Evervault’s secure environment and share the result with any downstream partner.

If you want to learn more about the use cases Evervault enables, check out our website, reach out to us, or see our developer documentation.