Aircraft Operational Data Access: Contract-to-Feed Checklist

Executive Summary

Aircraft operational data access is the ability to obtain specified aircraft-generated information, understand it, and use it for an agreed purpose in a ground system. Procurement should establish permission, documentation, delivery and permitted use separately. The International Air Transport Association (IATA) announced five principles with Airbus, Embraer and Rolls-Royce on 2 October 2024. ^[1] Their application is explicitly subject to regulations and contractual agreements. ^[1] The announcement does not establish that a particular operator already has a usable feed.

The first distinction is between raw data and derived analysis. IATA's statement excludes derived or inferred data and analysis from its aircraft operational data definition. A right to receive recorded parameters should therefore not be assumed to include a vendor's computed indicators, algorithms or application exports. ^[2] Delivery is another independent question: Teledyne Controls describes GroundLink flight data becoming available within minutes of landing, whereas Boeing describes its Airplane Health Management service delivering airborne faults and alerts. These are different documented capabilities, not interchangeable promises of a complete live sensor feed. ^{[3] [4]}

Safety-data permissions also need their own review. In the European Union Aviation Safety Agency (EASA) Air Operations rules, ORO.AOC.130 requires flight data monitoring (FDM) for the relevant aeroplanes with maximum certificated take-off mass above 27,000 kg, with safeguards for data sources. (Source: www.easa.europa.eu) The United States Federal Aviation Administration (FAA) describes its Flight Operational Quality Assurance (FOQA) guidance as supporting a voluntary programme. ^[5] Transport Canada's Advisory Circular (AC) 700-068, effective 15 September 2026, is guidance and expressly does not create or amend regulatory requirements. ^[6] These sources should not be merged into a universal airline obligation.

The practical decision is to use packaged access when its documented output meets the workflow, request a licensed export when approved data must move elsewhere, or build a bridge once permissions and technical documentation are settled. The contract-to-feed worksheet below records a source, evidence, decision owner and unresolved dependency for each field and use. Even apparently open ground data can have conditions: OpenSky requires consent for commercial API use, and EUROCONTROL restricts onward provision of Network Manager data. Software procurement should fund a defined access path, with acceptance evidence, rather than treating aircraft possession, a dashboard subscription or an application programming interface (API) as sufficient authority. ^[7] (Source: www.eurocontrol.int)

Introduction and Background

A proposed operations-control centre (OCC) dashboard may begin with a straightforward requirement: show the latest aircraft state alongside flight progress and safety indicators. The difficult procurement question comes earlier: which aircraft-generated fields can actually reach the operator's ground systems, through which parties, with what documentation and permissions?

The answer depends on the particular data product. A quick access recorder (QAR) is described in Transport Canada's guidance as an optional, non-crash-protected flight-data recording device. Its output is a different procurement object from an analytics result or a ground-network flight record. ^[6] IATA's aircraft operational data (AOD) statement covers aircraft-generated information after delivery to the operator, in flight or on the ground, but excludes derived analysis. ^[2]

This report examines aircraft data access rights, airline aircraft data ownership, aircraft data access agreements and integration readiness as of 27 October 2026. Its purpose is to help flight-operations data owners, safety managers and information technology (IT) procurement leads identify what must be established before an integration scope becomes credible. It does not infer contractual entitlements from product descriptions or treat an industry statement as legislation.

For a publisher focused on custom flight-operations software such as LANDING.AERO, the relevant perspective is the ground-system integration decision. The integration scope should begin with an evidenced input and a defined workflow. Where packaged software already supplies the required capability, the buyer should evaluate that category directly.

The analysis distinguishes source evidence from the report's proposed checklist. Regulatory and vendor statements below establish particular requirements or documented capabilities. Worksheet fields, procurement questions and go/no-go criteria are analyst recommendations. Their purpose is to expose unknowns early, rather than supply substitute contract language or replace an operator's approved procedures.

Define the Data and Map Every Party

Separate the objects being purchased

Start with a named data object, rather than the broad expression “aircraft data.” The IATA statement limits its AOD definition to readily available information that can be downloaded from aircraft to ground. It excludes design and production information as well as derived or inferred analysis. That boundary is narrower than everything a vendor might display in an application. ^[2]

For procurement, distinguish:

• Recorded parameters: Identify the actual recording, its parameter set and the configuration that produced it.
• Aircraft messages: Identify the message type and its intended ground recipient.
• Decoded engineering values: Identify the conversion documentation and the party permitted to apply it.
• Computed outputs: Identify the event, score, indicator or summary and its separate licence.
• External operational context: Identify the flight-plan, weather or network source independently of the aircraft recording.

The distinction between decoding and analysis is substantive. The FAA's FOQA circular describes a Logical Frame Layout as the map locating parameter bits in the recording. Safran's practitioner material recommends separating the decoding block from the analysis function. Receiving a file therefore leaves a further question: has the buyer also obtained the information needed to interpret it? ^[8] (Source: www.cassiopee.aero)

Build a source-to-recipient map

The proposed map should show the aircraft source, collection equipment, first ground holder, processing service, intended recipient and any onward recipient. Name the legal entity at each stage and attach the relevant agreement. The exercise is a procurement method, not a claim that every installation has the same architecture.

A useful real example is Teledyne's Data Delivery Solutions documentation. It describes distribution of agreed-to-share airline data to a consumer's cloud platform and filtering by aircraft tail number, consumer and frame-file format. That makes three matters worth checking independently: the selected aircraft, the selected recipient and the selected recording format. ^[9]

Keep technical pipeline roles separate from personal-data roles. In European Data Protection Board (EDPB) guidance, a controller determines processing purposes and means, while a processor acts on the controller's instructions. A diagram labelled “holder” or “analytics vendor” does not by itself settle those legal roles. (Source: www.edpb.europa.eu)

The map is complete enough for scoping when each transfer has an identified sender, receiver, object, permission and evidence owner. If a supplier cannot yet name an intermediate holder, record the gap explicitly. Do not let a generic architecture diagram stand in for the proposed delivery arrangement.

Use the Principles as Negotiation Prompts

IATA's current page identifies consent, transparency, sharing, accessibility and responsible use. Its accessibility principle includes documentation in a structured digital format supporting scalable processing. These are useful negotiation prompts, but the announced framework remains qualified by regulation and agreements. ^[10]

Table 1 translates the published principles into buyer questions. The questions are this report's proposed application, not quotations from a standard contract.

The table's value is the evidence column. A supplier's endorsement of a principle is useful context, but procurement still needs a defined application to the aircraft, fields, recipients and purposes in the proposed project.

Resolve raw, derived and sensitive boundaries

For OEM aircraft data access, request separate schedules for recorded data, decoding material and derived outputs. IATA's exclusion of derived analysis means that a proposal should not silently treat an analytics result as part of the same access request as the underlying aircraft recording. ^[2]

Sensitive-data handling should also be specific. IATA's current FAQ says categorization needs an explicit rationale documented contractually, and explains that accessibility and sharing restrictions should not abandon consent and transparency. Ask for an exclusion register with the field or dataset, rationale, contractual reference, permitted recipients and review route. ^[10]

Assess legal access separately

The European Commission's explanatory page says the European Union (EU) Data Act has applied since 12 September 2025. (Source: digital-strategy.ec.europa.eu) It lists planes among connected-product examples. (Source: digital-strategy.ec.europa.eu) It distinguishes readily available raw and pre-processed data from inferred or derived information. (Source: digital-strategy.ec.europa.eu) These are scope indicators for a legal assessment, not evidence that every aircraft feed is automatically deliverable.

Ireland's Competition and Consumer Protection Commission (CCPC) describes users as including owners, lessees and renters. (Source: www.ccpc.ie) It identifies an access-by-design stage for products placed on the EU market from 12 September 2026. (Source: www.ccpc.ie) Distinguish that later stage from the regulation's general application date.

For an actual transaction, counsel should check the governing text, territorial scope, product and service roles, applicable exceptions and interaction with existing contracts. Neither the industry principles nor explanatory guidance settles a particular dispute about ownership, confidentiality, access charges or redistribution.

Distinguish the Feed from the Transport

Airline operational data feeds should be classified by the information delivered, its ground recipient and its timing.

QAR access involves retrieval and interpretation

A QAR data access request should specify the recording, transfer path and decoder documentation together. The FAA circular describes FOQA data being periodically retrieved and sent for analysis; it does not define FOQA as a continuously live feed. It also links analytical usefulness to the available parameters, sampling rates and recording accuracies. ^[8]

Teledyne describes GroundLink Flight Data as compressing and encrypting data onboard, and advertises complete flight data within minutes of landing. Treat the latter as an attributed capability statement. A buyer should ask for the proposed installation's delivery trigger, coverage, receiving destination and measurable acceptance criteria rather than converting that wording into a contractual guarantee. ^[3]

A recording can be valuable for retrospective safety analysis while arriving too late for a particular OCC action. Establish the workflow's decision deadline first. Then ask the provider to demonstrate whether the proposed service delivers the necessary data before that deadline.

ACARS is a communication path with defined services

The Aircraft Communications Addressing and Reporting System (ACARS) should be scoped through the messages and services the operator is actually purchasing. SITA AIRCOM Cockpit Services documents aircraft-to-ground communications and ACARS over Internet Protocol (IP) through terrestrial cellular or cabin broadband. That describes connectivity options, not the buyer's complete parameter entitlement. (Source: www.sita.aero)

Collins Aerospace documents its ARINC GLOBALink qualification programme as supporting several communication subnetworks and providing end-to-end interoperability tests. Use that distinction in procurement: transport compatibility and successful application delivery need explicit evidence. Ask which aircraft configuration, message, ground address and receiving application the test covered. ^[11]

An API can expose different products

“Aircraft operational data API” is an interface description, not a complete definition of its contents. Airbus's historical Skywise launch announcement described tailored deliverables including analytics, applications and APIs. It is evidence of that original product concept, not verification of current export terms. ^[12]

Boeing's current Airplane Health Management page describes airborne faults and alerts for maintenance teams. Safran describes Cassiopée as transforming raw flight data into insights. These examples illustrate why a buyer should specify whether an interface returns a selected alert, a computed result or the original recorded series. This report uses them to clarify data products, not to recommend a maintenance workflow. ^{[4] [13]}

Finally, keep tracking and network feeds distinct from aircraft recordings. OpenSky identifies Automatic Dependent Surveillance-Broadcast (ADS-B) as its principal collection technology, while EUROCONTROL's Network Manager business-to-business (NM B2B) services include flight-plan and flight-data retrieval. Neither description establishes access to an operator's QAR parameter set. ^[7] (Source: www.eurocontrol.int)

Build the Contract-to-Feed Worksheet

Complete the worksheet per feed and aircraft configuration, assigning unresolved entries an owner.

Preserve OpenSky's distinct position-update and general-contact times, transponder address and nullable barometric altitude in metres. ^[14]

Table 2 is a proposed aircraft data integration checklist for a procurement workbook. Its evidence should be inspectable.

Each row should connect a requirement to evidence and a decision. Portal access does not answer whether an export is licensed; delivery does not answer whether a field can be interpreted. Settle both before acceptance.

Use a documented timestamp convention. Request for Comments (RFC) 3339 explains numeric offsets relative to Coordinated Universal Time (UTC). ^[15] Agree precision and source-time handling. Preserve original values needed to trace transformations; never silently treat unspecified local time as UTC.

Before closing the worksheet:

• Samples: Inspect each configuration and missing-value cases.
• Provenance: Trace selected values through decoding and transformation.
• Identity: Test aircraft identifier and configuration changes.
• Timing: Distinguish source-event age from ground-delivery delay.
• Decision owner: Assign an approver for unresolved rights, definitions and quality.

Ask the Contract Questions Before Buying the Bridge

Rights and personal-data responsibilities

“Who owns the aircraft data?” is too broad to complete an agreement. Ask instead who may extract a defined dataset, receive it, decode it, derive information, share it onward and retain it for a specified purpose. The IATA announcement's contractual qualification is precisely why each proposed use needs an evidenced answer. ^[1]

Where European personal-data rules apply, the EDPB says the controller-processor relationship must be governed by a contract. That is a separate assessment from the commercial licence for aircraft data or analytics. Establish the applicable processing roles and agreement rather than using “processor” as a generic label for any software supplier. (Source: www.edpb.europa.eu)

UK Information Commissioner's Office (ICO) guidance recommends identifying controllers at each sharing stage and establishing common retention and deletion rules. The page is marked under review, so use these as attributed checklist prompts and verify current UK requirements for the transaction. Do not transplant them into an EU or Canadian agreement without jurisdictional review. ^[16]

Questions by counterparty

The following are proposed procurement questions, not representations of standard vendor terms:

• Aircraft or engine OEM: Which raw recordings, dictionaries, configuration references and derived outputs are included?
• Aircraft or engine OEM: Which exclusions are designated sensitive, on what rationale, and under which agreement?
• Aircraft or engine OEM: May the operator appoint a ground-system recipient, and what documentation accompanies delivery?
• Connectivity provider: Which messages or files move over the purchased service, and to which destination?
• Connectivity provider: What happens to queued, duplicate, partial or unsuccessful transfers?
• Connectivity provider: Which proposed tests demonstrate the complete path to the intended application?
• Analytics vendor: Can raw inputs, decoded values and derived outputs be exported separately?
• Analytics vendor: Which export formats, recipient permissions, usage restrictions and fees apply?
• Analytics vendor: What happens to data, mappings and historical outputs when the agreement ends?
• All parties: Which processing locations, subcontractors, privacy conditions and potential export-control requirements need review?

The questions should produce a permission schedule, technical annex and unresolved-rights register. For each open issue, record the dataset, proposed use, relevant party, available evidence, required decision and consequence for scope. A register entry is closed only when the buyer has evidence of an answer, not merely a promise to discuss it later.

Keep safety-programme boundaries explicit

EASA's binding ORO.AOC.130 provision requires non-punitive FDM and safeguards for data sources. Its currently applicable Acceptable Means of Compliance (AMC) recommends restricting access to authorised persons and a written procedure protecting crew identity. Distinguish those AMC recommendations from the regulation itself. (Source: www.easa.europa.eu)

Transport Canada's AC 700-068 recommends developing data-protection policies with crew representatives and removing identifying information before routine safety analysis. For a safety-data export, ask the safety manager to approve the proposed purpose, recipient and identity handling before reusing the information in another operational application. ^[6]

Choose Packaged Access, Licensed Export or a Bridge

Select the delivery route after completing the rights and field review. Integration design should follow the approved data product and workflow. A bridge is justified when it performs a defined transformation or connection for which both the input and the intended output use are permitted.

Table 3 provides a proposed go/no-go decision framework. It compares procurement routes, not competing software products.

These routes can coexist. A packaged safety application might remain the system for its approved purpose while a separately licensed output supplies another ground workflow. The worksheet should record that separation, including the recipient and permitted use of each exported object.

EUROCONTROL NM B2B illustrates why access preparation belongs in the project plan. Its documentation specifies eligibility conditions, Extensible Markup Language (XML) payloads and a progression from pre-operational access to an operational certificate after acceptance validation. A technically plausible client is only part of the access path. (Source: www.eurocontrol.int)

Likewise, OpenSky's representational state transfer (REST) API documentation specifies OAuth2 client credentials. Authentication should therefore be checked against the current interface documentation rather than copied from an old example. This is an interface requirement, separate from commercial-use consent. ^{[14] [7]}

A proposed acceptance sequence is:

• Approve scope: Agree the dataset, covered configurations, recipients and purpose.
• Approve permissions: Close access, onward-use and processing issues that affect the selected route.
• Approve documentation: Inspect schemas, decoding references, identity rules and timestamps.
• Prove delivery: Demonstrate transfer through the intended production path with representative samples.
• Prove interpretation: Reconcile selected values and transformations against source evidence.
• Approve quality: Agree completeness measures, delay measures and handling of unavailable values.
• Approve operations: Assign change management, support, access removal and retention responsibilities.

Keep unresolved dependencies visible in commercial milestones. A useful outcome of discovery can be a smaller, well-defined integration or a decision to buy an existing service. The objective is a feed fit for an authorised workflow, rather than a predetermined amount of custom software.

Data Analysis and Evidence

The available public evidence supplies specific constraints and attributed capabilities, not a comparable market benchmark for airline feed entitlement. This research established no universal API price, guaranteed end-to-end delay or percentage of fleets implementing the IATA principles. The following numbers should be interpreted according to what they measure.

• Framework date: The IATA announcement dates to 2 October 2024 and names five principles. This dates the framework, not an operator's implementation or contract amendment. ^[1]
• EU access timeline: Commission guidance identifies 12 September 2025 as the general application date. (Source: digital-strategy.ec.europa.eu) CCPC guidance separately identifies 12 September 2026 for access-by-design requirements affecting newly marketed products. (Source: www.ccpc.ie) These are distinct applicability questions.
• Safety applicability: EASA's above-27,000 kg threshold is a rule criterion for the relevant aeroplanes under ORO.AOC.130. It is neither an API capability nor a universal global threshold. (Source: www.easa.europa.eu)
• Guidance timing: Canada's AC 700-068 is effective 15 September 2026. ^[6] EASA labels the existing AMC text applicable until 31 December 2027. (Source: www.easa.europa.eu) The report uses the currently applicable text, without treating future AMC provisions as current requirements.
• API resolution: OpenSky documents 5-second resolution for authenticated state-vector access ^[14] and 10-second resolution for anonymous access. ^[14] It also describes authenticated queries up to 1 hour into the past. ^[14] Resolution and query history are not promises of aircraft measurement frequency or end-to-end delivery delay.
• Service-scale claims: SITA reports around 10 million daily messages for AIRCOM Cockpit Services. (Source: www.sita.aero) Safran reports 500+ computed data points per flight for Cassiopée, ^[13] while GE Aerospace reports over 10,000 prebuilt analytics for its Event Measurement System (EMS). ^[17] These count different objects and should not be compared as accessible raw parameters.

A sizing calculation, not a product benchmark

Hypothetical Example: Suppose a proposed export contains 100 scalar fields, each sampled once per second, with 8 bytes per value, for an 8-hour flight. The assumed values alone occupy 23,040,000 bytes, or 23.04 decimal megabytes (MB): 100 × 1 × 8 × 28,800. This is an author-calculated illustration using stated assumptions, not a measured aircraft dataset or a vendor claim.

The calculation excludes timestamps, identifiers, quality flags, file structure, compression, encryption and transfer overhead. Its purpose is to make procurement specify what a volume estimate includes. A file's actual size and delivery time must be measured on representative exports.

For acceptance, measure the proportion of expected records received, missing intervals, duplicate records, decoding exceptions and delay to the intended recipient. Define the denominator and clock for every measure. Public product descriptions do not settle these project-specific metrics; the proposed service and sample evidence must do so.

Implications and Future Directions

The practical implication is to separate access discovery from implementation commitment. The discovery output should be a permission schedule, field inventory, representative dataset, delivery specification and unresolved-rights register. Those artifacts let procurement compare a packaged service, licensed export and ground-system bridge on the same intended outcome.

Documentation deserves a named owner. IATA's accessibility principle explicitly calls for structured digital documentation supporting scalable processing. A buyer can turn that principle into a concrete request for machine-readable definitions, configuration references and a documented change process, while leaving the actual contractual obligation to the agreement. ^[10]

More ground-system integration also increases the importance of preserving provenance. GE Aerospace EMS describes combining flight information with weather, navigation, flight plans and load sheets. In that kind of joined view, keep the origin and permission of each input visible rather than describing the combined output as one undifferentiated aircraft feed. ^[17]

The same discipline applies to new derived analytics. Safran's product description distinguishes transformation of raw flight data into insights. A proposed model or dashboard should therefore have separate questions for input access, processing permission, output rights and downstream use. Technical feasibility alone does not answer those procurement questions. ^[13]

Retention should remain tied to purpose. EASA's current AMC recommends keeping the full dataset until action and review are complete, then retaining a reduced dataset for longer-term trends. An integration should preserve the distinctions approved by the safety programme rather than imposing one storage policy on every raw, identified and derived dataset. (Source: www.easa.europa.eu)

For LANDING.AERO's ground-software perspective, the resulting boundary is straightforward: settle the usable input and authorised workflow before specifying the bridge. A narrowly defined integration can then be reviewed against evidence, and unresolved source-access questions remain visible to the parties able to resolve them.

Conclusion

Aircraft operational data access becomes a procurement-ready requirement when a buyer can name the data, source, aircraft coverage, recipient, delivery path, interpretation documentation and permitted purpose. A broad reference to ownership, an API or industry principles leaves too much of that requirement unspecified.

The proposed contract-to-feed worksheet makes those dependencies reviewable. It connects every important field and use to evidence, gives unresolved questions an owner, and separates permission from delivery and interpretation. The unresolved-rights register should influence the integration scope and commercial milestones.

The route decision then becomes clearer. Use packaged access when its documented output fits the authorised workflow. Request a licensed export when the required data exists but must reach another approved recipient. Build a ground-system bridge when permissions and documentation support a defined connection or transformation. Hold the dependent work while a material access question remains open.

The final procurement question is therefore concrete: can the proposed arrangement deliver this defined information, to this authorised ground system, in a form and timeframe that supports this approved use? A satisfactory answer consists of documents, samples and acceptance evidence. That is the foundation on which an OCC or safety integration can be scoped, tested and maintained. The resulting scope should remain traceable to that evidence throughout delivery.