What is SRSIA and Why It Matters

Executive Summary

• SRSIA is the commercial and operational agreement pattern behind interline retailing in an Offers and Orders world.
• The language changes from validating, marketing and operating carrier to Retailer and Supplier, which is closer to how digital commerce actually works.
• The agreement is valuable because it clarifies offer ownership, servicing rights, disruption accountability, data exchange and settlement responsibilities.
• The near-term reality is coexistence: airlines will use SRSIA concepts while some partners still rely on PNRs, tickets, EMDs and legacy interline settlement.

Why This Topic Matters

Airline partnerships are moving from static fare filing and ticket coupon mechanics toward retailing models where one party can sell a richer, contextual journey assembled from multiple suppliers.

Without a clear retailer-supplier operating model, modern offers can improve the shopping page while leaving servicing, disruption handling and finance teams with ambiguous ownership.

SRSIA matters most when the customer expectation is simple but the back end is mixed: one itinerary, two airlines, multiple products, several settlement records and different levels of order readiness.

Industry Background

IATA positions Modern Airline Retailing around Offers and Orders, with NDC, ONE Order, Dynamic Offers, Settlement with Orders and interline modernization as related programs rather than isolated standards.

The future-of-interline work introduces SRSIA as the foundation for a new framework that moves away from legacy ticketing concepts and toward Retailer and Supplier roles.

That does not mean every airline becomes order-native at the same time. It means commercial agreements, APIs, operational messages and settlement processes need an agreed bridge while the industry transitions.

The practical implication is simple: the customer promise has to be designed across offer, order, servicing, delivery and settlement, not only across shopping screens.

Detailed Explanation

Scenario: SRSIA replaces validating-carrier thinking with a Retailer and Supplier model for dynamic airline partnerships.

In a legacy interline model, the validating carrier normally anchors ticketing and settlement. The operating carrier delivers transport. Marketing and operating roles may be governed by codeshare or interline agreements. This model is reliable, but it was not designed for continuous offers, supplier-controlled bundles, post-booking ancillary retailing or rich servicing events.

SRSIA reframes the partnership around the party that owns the customer interaction and the party that supplies products or services. The Retailer can package, present and service a journey. The Supplier controls the product promise it is willing to make, including availability, price, fulfilment constraints and operational updates.

The most important design question is not "who issued the ticket?" but "who is accountable for the customer promise at each lifecycle step?" Shopping, pricing, order creation, payment, fulfilment, change, refund, disruption and settlement can each have different system owners while still being governed by one commercial model.

For architects, SRSIA is less a single API and more a boundary contract. It defines what the Retailer must know, what the Supplier must expose, what events must be exchanged and how exceptions are handled. The implementation may use NDC messages, order APIs, event streams, legacy PSS adapters, settlement files and manual fallbacks during migration.

For executives, the value is optionality. Airlines can build partnerships beyond classic interline, including LCC-full-service combinations, rail-air, ancillary partners and virtual interline constructs, while still forcing the hard questions of service, risk, payment and financial accountability.

Architecture and Operating Model Deep Dive

Offer and product governance

The offer layer is where the commercial promise is created, but it is also where many interline failures are introduced. In What is SRSIA?, the offer should not be treated as a screen-level response. It needs supplier provenance, expiry, price guarantee, inventory constraint, product attribute, refundability and settlement intent. The key rule is that every product shown to the traveler must have a known fulfilment path and a known servicing path.

Retailer, with supplier-provided product and availability where needed That owner should decide which supplier details are displayed directly, which are normalized into the retailer brand, and which are suppressed because the downstream lifecycle cannot support them. The product catalog, offer engine and partner adapter should work together so that the offer is not richer than the operational reality behind it.

Order and record strategy

Retailer order, with supplier fulfilment records or order items This is the most important system-of-record decision in the scenario. Teams should not simply ask whether an order exists. They should ask which record is authoritative for passenger identity, itinerary, price, entitlement, fulfilment, supplier acknowledgement, payment, refund, exchange and settlement. In hybrid periods, more than one record may exist, but only one should be authoritative for each field.

A good order strategy keeps correlation visible. Offer ID, order ID, supplier order reference, PNR, ticket, EMD, payment reference, settlement reference and disruption event ID should be linked so customer service, airport, operations and finance teams can reconstruct the lifecycle without manual detective work.

Servicing and disruption design

Retailer for customer interaction; supplier for delivery commitments This responsibility must be translated into concrete permissions: retrieve order, change itinerary, add item, remove item, refund item, split passenger, reprice supplier product, accept involuntary alternative and close an operational case. If a team cannot say which party may execute each action, the customer experience will depend on manual escalation.

Operating supplier initiates operational alternatives; retailer presents the customer journey The supplier owns operational facts such as cancellation, delay, aircraft swap, seat map change or airport delivery failure. The retailer owns the customer journey view. A modern disruption design converts the supplier event into recovery offers, customer choices, order updates, supplier confirmations and settlement adjustments.

Settlement and revenue accounting

Order-linked settlement, legacy settlement translation, or both during coexistence Finance should be involved before launch because settlement fields are not back-office decoration. They determine whether a partner accepts the record, whether revenue can be recognized correctly, whether refunds are allocated to the right party and whether disputes can be resolved from evidence rather than email threads.

The finance-grade order item should carry product owner, seller, supplier, amount, taxes, commission, fulfilment status, refund status, change history and settlement reference. Where a legacy partner remains in the flow, the bridge must map those order item facts to ticket, coupon, EMD or billing records without losing commercial meaning.

Data, observability and audit

Every SRSIA explained implementation needs an observability model. Teams should trace search request, supplier response, offer construction, customer selection, payment authorization, order creation, supplier confirmation, delivery event, servicing action and settlement event. The audit trail should show what each party knew at the time the customer promise was made.

Operational dashboards should be organized by partner, readiness state, platform, market and relationship type. A spike in order-PNR mismatches, supplier timeouts, failed order changes or settlement rejects should be visible before customers and finance teams discover the issue manually.

Partner onboarding and governance

SRSIA onboarding should be a product process, not only a legal process. Each partner needs a readiness score, supported lifecycle actions, API version inventory, test cases, exception handling model, disruption SLA, settlement evidence checklist and executive escalation path. The output should be a go-live decision that everyone can defend.

The governance model should also define change control. If a supplier adds a new ancillary, changes refund rules, migrates a market to order-native servicing or retires a legacy bridge, the retailer needs advance notice, regression tests and customer messaging updates.

Operational Scenario Walkthrough

1. Search trigger: The customer asks for a journey and the retailer identifies whether the flow is interline, codeshare or virtual interline. At this point the system should already know the readiness state of each partner and which fallback rules are allowed.
2. Supplier content request: The retailer requests supplier content with enough context for the supplier to return a meaningful promise. That context may include route, dates, passengers, loyalty status, channel, currency, point of sale, baggage needs and servicing requirements.
3. Offer assembly: The retailer assembles a customer-facing offer using supplier constraints. The offer should not hide material differences in product, baggage, seat, refund, change or disruption treatment. If a feature cannot be fulfilled or serviced, it should be excluded or marked as conditional.
4. Acceptance and payment: The customer accepts the offer. Payment, fraud, tax, commission and settlement allocations should be captured before the order is confirmed so the financial record can be reconciled later.
5. Order creation: The retailer creates the order or legacy equivalent. The supplier receives a fulfilment request or mirror record. Correlation IDs are written at this stage because retrofitting them after failure is expensive and unreliable.
6. Post-booking servicing: A change, refund or ancillary request is evaluated against both retailer policy and supplier capability. The customer sees a simple servicing action, while the back end may execute order change, ticket exchange, EMD update or supplier authorization.
7. Disruption event: The operating supplier sends an event. The retailer determines whole-journey impact, requests alternatives if necessary, displays customer options and records the accepted recovery path as an order update or legacy servicing action.
8. Settlement close: The retailer and supplier reconcile sale, change, delivery, refund and disruption evidence. Exceptions are routed to a dispute process with enough order and legacy references to avoid manual reconstruction.

SRSIA Annex Blueprint

A strong annex for What is SRSIA? should begin with role definitions. Name the Retailer, Supplier, any selling intermediary, any platform provider and any operational delegate. Then define which role owns the customer relationship, which role owns the product promise and which role is allowed to make binding changes after purchase. This avoids the common situation where legal terms are clear but product teams still disagree on who may act.

The second annex area is product eligibility. List the routes, markets, passenger types, fare brands, ancillaries, bundles, loyalty benefits and service attributes that are allowed in the scenario. For each product, state whether it is searchable, sellable, changeable, refundable, disruptable and settleable. If an item is only supported in direct channels or only before ticketing, that limitation should be written into the operating model.

The third area is data exchange. The annex should specify mandatory fields for offer requests, supplier responses, order creation, supplier acknowledgement, servicing actions, disruption events and settlement evidence. It should also define timeout behavior, idempotency rules, duplicate message handling, version compatibility and minimum logging. These details are rarely glamorous, but they are what prevent operational disputes later.

The fourth area is customer treatment. Define what the traveler sees when a supplier product is unavailable, when a price changes, when confirmation is delayed, when a servicing action requires manual handling, or when disruption affects only part of the journey. The retailer should not have to invent customer language in the middle of an incident. The approved treatment should be part of the launch pack.

The fifth area is exception management. Every scenario needs named queues, SLAs, escalation paths and compensation authority. If a supplier cannot confirm, if order creation succeeds but settlement evidence fails, if a refund is accepted by one record and rejected by another, or if the customer is stranded between two partners, the annex should state who opens the case and who closes it.

The final area is change governance. SRSIA is not static. Airlines will migrate markets, retire bridges, add products, upgrade APIs and change servicing rules. The annex should require advance notice, regression testing, release notes, rollback procedures and joint operational readiness sign-off. This turns SRSIA from a launch document into a living operating contract.

Readiness Questions by Function

Implementation Roadmap

The roadmap should be repeated for each partner pair. One partner may be ready for shopping but not servicing. Another may support order events but still depend on legacy settlement. Treat readiness as a matrix by flow, not a binary partner label.

KPI and Control Framework

These metrics should be reviewed jointly by distribution, digital, operations, customer service and finance. SRSIA succeeds when ownership is visible across the lifecycle and failure modes are measured before they become structural cost.

Scenario Matrix

Comparison Table

Process Flow

1. Customer shops with Retailer
2. Retailer requests supplier content
3. Supplier returns product promise
4. Retailer creates combined offer
5. Retailer creates order and settlement references
6. Supplier receives fulfilment and disruption obligations

Mermaid Diagrams

Process Flow Diagram

flowchart LR
  C[Customer] --> R[Customer-owning airline or seller]
  R --> SRSIA[SRSIA responsibility layer]
  SRSIA --> S[Operating or product-owning airline]
  R --> O[Retailer order, with supplier fulfilment records or order items]
  S --> D[Delivery and supplier events]
  D --> R

Sequence Diagram

sequenceDiagram
  participant Customer
  participant Retailer
  participant SRSIA
  participant Supplier
  participant Settlement
  Customer->>Retailer: Shop and choose itinerary
  Retailer->>Supplier: Request supplier content and constraints
  Supplier-->>Retailer: Return product promise
  Retailer->>Customer: Present combined offer
  Customer->>Retailer: Accept and pay
  Retailer->>SRSIA: Create accountable order context
  SRSIA->>Supplier: Confirm fulfilment obligation
  Supplier-->>Retailer: Send delivery or disruption events
  Retailer->>Settlement: Generate settlement evidence

Swimlane Diagram

flowchart TB
  subgraph Customer
    c1[Search] --> c2[Accept offer] --> c3[Receive updates]
  end
  subgraph Retailer
    r1[Compose offer] --> r2[Create order] --> r3[Service customer]
  end
  subgraph Supplier
    s1[Return availability] --> s2[Confirm fulfilment] --> s3[Send operational event]
  end
  subgraph Finance
    f1[Capture price owner] --> f2[Allocate settlement] --> f3[Reconcile dispute]
  end
  c1 --> r1
  r1 --> s1
  c2 --> r2
  r2 --> s2
  s3 --> r3
  r3 --> f2

Risks, Benefits and Controls

Key Takeaways

• SRSIA is best understood as a role and accountability model, not just a legal document.
• The biggest near-term value is managing hybrid coexistence.
• The customer-facing retailer must own the journey narrative even when supplier systems vary behind the scenes.
• Settlement and disruption design should be part of the initial architecture, not deferred.

FAQ

SEO Metadata

Suggested Social Media Snippets

• What is SRSIA and Why It Matters: a practical SRSIA scenario for airline retailing teams. https://www.modernairlineretailing.com/blog/2026-06-10-what-is-srsia-and-why-it-matters.html
• If your interline roadmap stops at shopping, you are missing servicing, disruption and settlement. Read: What is SRSIA and Why It Matters.
• Retailer-Supplier design question: who owns the customer promise when platforms and readiness differ? What is SRSIA?

Interactive Graphic Specification

• Default state in the SRSIA Scenario Explorer should highlight What is SRSIA?.
• Controls: airline A state, airline B state, platform, relationship and transition maturity.
• Outputs: owner table, complexity heat map, Sankey flow, swimlane, sequence diagram, architecture diagram and readiness matrix.
• Primary KPI: time for a product manager or architect to answer who owns offer, order, servicing, disruption and settlement.

Image Prompts for AI Generation

• A clean executive aviation technology infographic showing What is SRSIA and Why It Matters, with two airline system blocks, an SRSIA layer, order items and settlement lines, realistic airport operations background, modern editorial style, no logos.
• A detailed airline retailing architecture diagram for What is SRSIA?, showing retailer, supplier, offer, order, disruption event and settlement evidence, high contrast, professional consulting visual.
• A product manager dashboard visualization for SRSIA explained, with readiness matrix, heat map and interline lifecycle timeline, modern airline technology aesthetic.

Internal Links and Related Articles

• SRSIA Scenario Explorer
• SRSIA & Interline Retailing Knowledge Hub
• Interline Offer & Order Architecture
• The Road to 100% Offers and Orders
• The Complete SRSIA Scenario Matrix

References

Only publicly available sources from the approved source set are used. The analysis above is independent and implementation details vary by airline, vendor and partner agreement.

• IATA Interlining with Offers and Orders
• IATA SRSIA overview and positioning paper
• IATA Airline Retailing
• IATA Distribution with Offers and Orders (NDC)
• IATA Fulfilment with Orders (ONE Order)