GDS (Global Distribution System)

GDSs aggregate content filed via ATPCO and schedules, calculate prices using sophisticated fare/rule engines and provide mature servicing flows around PNRs, tickets and EMDs. They also carry agency constructs such as pseudo city codes (PCCs), queues and profiles that many back‑office tools expect.

Strengths include breadth of airlines, robust exchange/refund tooling, and predictable settlement paths. Limitations are tied to EDIFACT era constructs that do not natively express branded fares or airline‑controlled dynamic pricing. In practice, both worlds coexist for years.

A pragmatic architecture treats the GDS as one of multiple sources. At search time, normalise and deduplicate against NDC and LCC. At booking time, orchestrate through the GDS when it is the better path (for servicing coverage or content parity) while keeping an internal order that looks the same whichever route issued the document.

Operationally, keep PCCs, office IDs and other GDS credentials in the connectivity layer, not in the UI or order schema. Expose a simple “source” tag to agents and retain all PNR and ticket references on the order for audit. Mid‑office teams should not have to understand which queue a change was processed in to reconcile finance.

Common pitfalls: mixing PNR‑centric and order‑centric assumptions inside the same code path; data loss when mapping EMDs; and brittle scraping of agent desktop flows. Prefer APIs and structured data wherever possible and isolate platform differences behind one model.

When adding NDC beside GDS, teach the agent screen one mental model and rely on routing and capability flags to pick the pipe. Success is measured in servicing consistency and fewer dead‑ends, not in eliminating GDS overnight.

In the Elkanio platform, Synapse treats the GDS as one source alongside NDC and LCC. Results arrive in a single schema, while PNRs, ticket numbers and EMD references are preserved on the order so Vector can reconcile BSP/ARC cleanly.

Where GDSs came from: early airline reservation systems evolved into neutral networks so agencies could shop and ticket many carriers in one place. Over time, fare filing (via ATPCO), schedule distribution and sophisticated pricing engines were layered in, along with mature mid‑office workflows built around PNRs, queues and documents.

How a fare reaches the screen: airlines publish base fares and rule categories; GDS pricing combines those with availability and taxes to return itineraries with a priced construction. Booking classes (RBDs), combinability and surcharges determine which fares are valid. For audit, store the fare basis, ticketing carrier and tax breakdown alongside the PNR and ticket.

EDIFACT vs NDC: EDIFACT encodes availability, faring and servicing around PNRs and e‑tickets. NDC moves retailing to airline‑controlled offers and orders, enabling branded fares, rich media and more dynamic price points. Agencies rarely choose one or the other; they blend them, deduplicate results and keep one order model underneath so servicing is consistent.

Agency and airline roles: airlines control inventory, fare filing and settlement rules; agencies hold credentials (PCCs/office IDs) that govern access, queues and profiles. Corporate programmes may add eligibility attributes that influence pricing and display. Keep these credentials and identifiers in the connectivity layer, not sprinkled through the UI.

Servicing patterns are PNR‑centric: exchanges reprice remaining coupons against rules, refunds respect penalty and no‑show logic, and ancillaries may be fulfilled as EMDs. Consistency comes from mapping all of these into one internal order view while preserving supplier references for downstream tools.

Typical failure modes: autopricing discrepancies when fare rules or surcharges are interpreted differently; partial coupon states during irregular operations; losing EMD links in mapping; and queue blindness (actions taken in one office ID not visible to another). The antidote is structured capture of documents and rigorous mapping with tests.

Commercially, negotiated and public content both flow through the GDS. Some contracts are filed as private fares with designators or tour codes; others appear via separate pipes. Label the source and the commercial model so agents and finance know how invoices and statements should look.