IATA FOX Data Sharing Requirements and Export Checklist

Executive Summary

IATA FOX data sharing requirements begin with airline participation and access to operational source records. The International Air Transport Association (IATA) describes Flight Operations Data eXchange (FOX) as a voluntary airline initiative within Global Aviation Data Management (GADM), linking planning inputs with operational performance. It should be evaluated as a data-sharing commitment with accountable owners, agreed uses and repeatable exports. ^[1]

The FAQ specifies operational flight plans (OFPs) in ARINC 633 and Load Final Figures (LDFs) in Airport Handling Manual (AHM) 17, both using Extensible Markup Language (XML), plus aircraft configuration in comma-separated values (CSV). It describes typically weekly File Transfer Protocol (FTP)-based submissions, no joining fee, and a 45-day onboarding target after agreement signing. Confirm acceptance details in the agreement and receiving specifications; the target does not establish the airline's integration cost or guarantee its delivery date. ^[2]

The recommended readiness decision has three dimensions: authority to share, reliable source exports, and controlled delivery. A familiar format name does not establish the accepted schema revision or required content: XML Schema constrains document structure, while a documented vendor interface may refer to particular ARINC revisions. Obtain an accepted sample and run the airline's own files through the agreed checks before choosing between packaged exports and a limited adapter. ^{[3] [4]} Privacy review remains necessary even where recipient-side de-identification is offered. The European Data Protection Board distinguishes anonymisation from pseudonymisation, and United Kingdom guidance asks organisations to identify controllers throughout sharing. (Source: www.edpb.europa.eu) ^[5]

A practical approval package should therefore identify source owners, preserve record provenance, document missing-record handling, and restrict export access. Lineage documentation supports tracing transformations, while least privilege limits access to what an assigned task requires. ^{[6] [7]} Avoid assuming that FOX alone earns subscription savings: the separate incentive program requires Schedule Data Exchange and Incident Data Exchange (IDX) contributions. ^[8] The participation decision is ready when airline sponsors can demonstrate an authorised, reproducible contribution and explain the benefit sought. An existing export is sufficient when it passes those tests; a narrow bridge is justified when a specific, documented gap remains.

Introduction and Background

FOX addresses a practical airline question: how can planning data be examined alongside what actually happened? IATA describes a voluntary contribution covering operational flight plans, weight-and-balance information and aircraft configuration, intended to enrich planned-versus-actual analysis. Its stated audience is airlines, ideally already participating in related GADM programs. This report addresses that airline decision rather than extending the program to charter or business-aviation departments outside its stated audience. Confirm organisational eligibility with IATA before signing; existing membership or another data contribution should not be treated as acceptance. ^[1]

The useful starting point is a participation readiness assessment, not a software procurement exercise. An airline should first define the analysis it wants, identify who can authorise disclosure, and establish where the relevant records originate. Only then can it decide whether existing exports suffice. Public product descriptions can show that a system integrates operational data: for example, Lufthansa Systems describes NetLine Load bringing together booking estimates, check-in figures, fuel, baggage, cargo and mail. Such a description does not establish the airline's contractual export entitlement. ^[9]

This report uses public sources checked on 22 October 2026. It separates program descriptions from recommended airline controls. It does not reproduce an IATA participation agreement, accepted schema package or airline-specific vendor licence. Where those materials determine acceptance, the checklist identifies an item to obtain rather than supplying an assumed answer. XML Schema's role in constraining document structure illustrates why a file's appearance alone cannot establish conformance to a recipient's specification. ^[3]

LANDING.AERO's perspective here is limited to integration and data governance. The airline remains the decision owner. The intended readers are flight-operations and dispatch leaders, safety and fuel analysts, and the information-technology (IT) or data owners supporting them. The central question is whether those owners can approve and reproduce the contribution with evidence. A data-sharing agreement should make the parties' roles explicit, and the disclosure assessment should ask how little personal data can achieve the intended purpose. ^{[5] [10]}

Key Changes: What FOX Adds to the Decision

Planning inputs are a distinct contribution

FOX adds planning and aircraft-specific inputs to IATA's operational analysis proposition. That makes source selection important: an airline needs to identify the planning record it intends to contribute and retain the reason that record was selected. Treating every file associated with a flight as equivalent would leave the analysis unable to distinguish the intended plan from an intermediate calculation. This is a recommended provenance control, informed by the broader data-lineage practice of recording origins and transformations. ^[6]

Flight Data eXchange (FDX) is different. IATA describes it as an aggregated, de-identified flight-data database within GADM, using recorded flight data for safety and operational comparisons. A working FDX contribution does not by itself demonstrate that the planning and load-control exports needed for the proposed FOX contribution are available. The airline should inventory them separately. ^[11] FuelIS is IATA's fuel-efficiency intelligence solution, with analytical filters and benchmarking functions. It is an analytical product, rather than a substitute name for the FOX source-file contribution. ^[12]

Operational messaging is adjacent evidence

Aviation Information Data Exchange (AIDX) is an XML messaging standard for exchanging flight data between airlines, airports and third parties. Its operational flight-leg scope helps explain why an airline may already have a substantial data interface without having the particular files needed for FOX. An AIDX interface should be assessed on its actual contents and purpose, rather than treated as an interchangeable planning export. ^[13]

Likewise, the Standard Schedules Information Manual (SSIM) addresses airline schedules, airport coordination information and minimum connecting-time data. Schedule sharing can support another business purpose, but the existence of that feed is not evidence that an OFP or load-final export is available. Keep the program contribution, the message standard and the source-system entitlement as distinct entries in the inventory. ^[14]

Standards access belongs in the approval package

SAE International's ARINC 633 description covers Aeronautical Operational Control (AOC) communications and includes XML schema definitions. That is evidence of the standard's scope, not a public grant to redistribute its materials. Obtain the applicable edition, permitted use and any sharing rights from the relevant licence holder or vendor. This research did not retrieve usable ARINC licence terms, so no redistribution entitlement is asserted. ^[15]

IATA's Ground Operations XML Messaging (GOXML) toolkit page ties access to customers obtaining the latest digital Airport Handling Manual (AHM) or Baggage Reference Manual. That access model is a reason to check entitlement before copying a schema package into an integration project. The public page does not establish that every toolkit message is accepted by FOX, or that an airline may pass the materials to any contractor. ^[16]

Source Inventory and Record Provenance

The public FAQ identifies the source families and formats summarised in Table 1, with configuration supplied at onboarding and updated as needed. The ownership assignments and acceptance questions are recommendations for the airline, rather than additional published IATA requirements. The airline should assign a configuration owner and record how updates will reach the recipient. ^[2]

The matrix directs questions to the people who can answer them. A dispatch team may select the planning record while IT operates the export. That allocation keeps operational interpretation with the source owner. The distinction between document structure and content constraints also supports separate technical and operational acceptance checks. ^[3]

Establish the authoritative record

For the OFP final version, ask what the source system means by released, accepted, revised and superseded. Do not invent a universal FOX final-version rule: the public material reviewed did not settle that selection policy. Agree it with IATA and the airline's planning owner, then record the source version and selection reason. Lineage should permit a later analyst to trace the delivered record back through any transformation. ^[6]

Apply the same discipline to LDF final-version selection. Ask the load-control owner how post-release amendments are identified and whether the export exposes status explicitly. The availability of approved load sheets in a vendor workflow is useful context, but it does not prove availability of the required machine-readable export. Lufthansa Systems, for example, describes pilots reviewing fuel figures and approving load sheets within NetLine Load CockpitMobile. ^[9]

Test the join before automating delivery

Table 2 is a Hypothetical Example of an airline reconciliation record. Every identifier, date and version is synthetic. It demonstrates a proposed control, not an IATA message, accepted filename or required FOX key.

The example makes ambiguity visible: an otherwise valid record should be held for review if its sector or tail conflicts with the selected plan. A configuration join should use the version effective for that operation. Preserve the source values alongside any normalised join key so that a correction can be explained. This follows the purpose of lineage, including tracing transformations, without prescribing a particular database or cloud product. ^[6]

Implementation Considerations and Process Changes

Agree the receiving specification

Before configuring a recurring export, obtain the accepted schema versions, required fields, sample files, configuration columns and rejection feedback from the receiving team. ARINC 633 describes a communications family; the name alone is not a sufficient acceptance specification. The SAE page reviewed contains inconsistent status labels, so this report does not nominate a current revision for FOX. ^[15] Public Jeppesen interface documentation illustrates the version question by describing an OFP response in particular ARINC revisions. Its availability does not establish applicability to the airline's current installation. ^[4]

CSV compatibility also needs an explicit agreement. Request for Comments (RFC) 4180 is an informational document, not an Internet standard, and notes variation between implementations. Agree headers, delimiters, quoting, encoding, empty values and date representations with the recipient. A file that opens successfully in a spreadsheet has not thereby passed a recipient's import rules. ^[17]

Use the following recommended acceptance sequence:

• Extract: retain the source identifier, extraction timestamp and selected source version.
• Parse: confirm that each file is the expected document type and can be read safely.
• Validate: check the agreed schema, required columns and permitted value representations.
• Reconcile: compare flight identity, sector, operating date and tail across sources.
• Review exceptions: separate missing records, superseded versions and unit conflicts from accepted records.
• Approve: record the operational owner's decision on unresolved ambiguity before submission.

XML Schema supports structural and content constraints, but an airline still needs its own operational acceptance criteria. Secure parsing is a separate concern: the Open Worldwide Application Security Project (OWASP) recommends restricting external access during schema validation. An export bridge should use the agreed local schema and explicitly configured parser behaviour. ^{[3] [18]}

Make the weekly process observable

For the typically weekly contribution, agree the cut-off, delivery window, transport protocol, credentials, acknowledgement and correction process before scheduling a job. The public FTP-based description does not establish the encryption protocol. ^[2] Secure Shell (SSH) File Transfer Protocol (SFTP) is a distinct technical option: OpenSSH documents encrypted remote file transfers and SFTP support. That describes an available mechanism, not the configuration of IATA's receiving service. ^[19]

Recommended weekly controls should be small enough to operate consistently:

• Expected population: obtain the airline's list of in-scope operated legs for the submission window.
• Coverage: identify which expected legs have the required operational records and configuration match.
• Versions: identify late amendments and the previous submission they replace.
• Units: reject ambiguous mass, fuel or time representations rather than silently guessing.
• Delivery: log filenames, record counts, checksums and receiver acknowledgements where provided.
• Recovery: give every rejection or missing record an owner and a documented next action.

A checksum verifies byte-level integrity rather than the presence of every expected flight. Amazon's storage documentation illustrates that distinction by describing checksum comparison for uploaded objects. Use source-to-export reconciliation for completeness and a checksum for transfer integrity; neither result replaces the other. ^[20]

Privacy, Data Rights and Approval Ownership

Review disclosure before recipient processing

IATA's FAQ says airlines need not de-identify before submission and describes IATA-side de-identification, anonymisation and protective controls. Treat that as IATA's assertion about processing, not as the airline's completed privacy assessment or permission to disclose every available field. ^[2] The European Data Protection Board (EDPB) distinguishes reduced linkability through pseudonymisation from true anonymisation. A transformation's label alone should therefore not determine the airline's classification of its outgoing files. (Source: www.edpb.europa.eu)

The French data protection authority (CNIL) advises against treating raw datasets as anonymous by default and recognises indirect identifiers as well as directly identifying data. Review actual sample fields, including free text and attachments, to establish what the proposed export contains. Do not assume a field is anonymous simply because it omits a person's name. ^[21] The UK Information Commissioner's Office (ICO) checklist offers a useful minimisation question: could the objective be achieved with less personal data, or none? Apply it before building a broad export. ^[10]

Assign the approval, not just the account

A recommended airline participation sponsor should own the decision and the benefit sought. Dispatch, load control and the configuration custodian should approve their source selections. Legal, privacy, procurement and security owners should review the agreement within their responsibilities. This allocation is a proposed governance model, not a public FOX organisational requirement. ICO guidance supports documenting the controllers at each stage of sharing. ^[5]

The approval record should answer these questions:

• Purpose: what analysis is sought, and what subsequent uses does the agreement permit?
• Authority: who can authorise sharing of the airline's records and commercially sensitive material?
• Roles: who determines purposes and means, and who processes on whose instructions?
• Scope: which fields, attachments and identifiers are necessary for the contribution?
• Location: where will processing occur, and who may receive or access the records?
• Retention: when are staging files, recipient copies and logs deleted or retained?
• Assurance: what evidence, inspection rights and escalation channels can the airline use?
• Change: what happens when fields, recipients, purposes or source systems change?

These questions draw on guidance rather than proving that a particular legal regime applies. ICO sharing-agreement guidance covers roles and retention, but is marked as under review following United Kingdom legislative change. Its checklist remains a useful review aid; jurisdiction-specific conclusions require the airline's own legal assessment. ^{[5] [10]}

For Canadian organisations, the Office of the Privacy Commissioner (OPC) guidance on processing transfers under the Personal Information Protection and Electronic Documents Act (PIPEDA) emphasises continuing accountability and audit rights. Its outsourcing context should not be treated as automatically covering a recipient's independent analytical reuse. Confirm the actual relationship before relying on that guidance. ^[22]

Restrict the approved pipeline

Use a dedicated service identity, limited source access and an approved destination. The United States National Institute of Standards and Technology (NIST) defines least privilege around the minimum access needed for assigned tasks. This is a useful security principle, not a FOX-specific mandate. ^[7] Protect staging copies as well as the transfer: the Cybersecurity and Infrastructure Security Agency (CISA) recommends encryption of stored files and devices. Apply retention decisions to those copies too. ^[23]

Packaged Export or Narrow Adapter?

Test the existing capability first

An airline should request a real sample from its licensed deployment before commissioning an adapter. Relevant public vendor evidence is informative but limited. Lufthansa Systems documents NetLine Load integration with operational data sources. ^[9] Jeppesen's public ElectronicFlightFolder specification describes an ARINC-formatted planning response and a wrapped flight-plan element. ^[4] IBS Software describes open application programming interfaces (APIs) and messaging capabilities for iFlight Core. None of these public sources establishes the airline's right to disclose records to IATA or demonstrates FOX acceptance. ^[24]

A packaged export is a candidate when it supplies the agreed fields, exposes the selected record status, runs under the airline's licence, and can be operated with appropriate monitoring. Validate it against the receiving schema rather than treating a product label as evidence. The World Wide Web Consortium (W3C) XML Schema describes a validation mechanism, not a certification of an operational workflow. ^[3]

Before selecting the route, document:

• Entitlement: the contract or written vendor confirmation permitting extraction and intended sharing.
• Coverage: the fields and versions demonstrated in an actual export sample.
• Gap: the precise mismatch between that sample and the accepted receiving specification.
• Transformation: each mapping, conversion or wrapper removal needed to close the gap.
• Ownership: who approves mappings and who operates the scheduled delivery.
• Exit: how the airline can reproduce the contribution when the source system changes.

A narrow adapter is justified by a documented gap, such as assembling authorised exports, applying a verified mapping or adding reconciliation and delivery controls. It should preserve source values and record transformations. Microsoft's data-lineage documentation describes tracing data movement and transformation; that is the relevant principle, rather than a requirement to adopt Microsoft's platform. ^[6]

Keep the bridge bounded and reviewable

The adapter's acceptance record should show that valid source information survives the transformation. For XML, combine the accepted schema with safe parser settings. OWASP recommends restricting external access in schema validation; that recommendation applies to parser configuration even when the business documents come from a trusted workflow. ^[18] Also verify content rather than relying on a filename or a claimed media type: OWASP notes that uploaded Content-Type values are supplied by the sender. ^[25]

Keep access separate from scheduling convenience. A job that reads selected exports does not automatically need permission to change planning or load-control records. Amazon Web Services (AWS) Identity and Access Management documentation describes granting only permissions needed for a task, consistent with NIST's least-privilege principle. Equivalent controls can be implemented in the airline's existing environment; no particular cloud is required. ^{[26] [7]}

Transfer acceptance should remain distinct from analytical usefulness. A checksum can demonstrate that delivered bytes match the selected file. It cannot establish that the correct planning version was selected or that a configuration attribute was effective on the flight date. The first question is a documented transport-integrity check; the latter questions require the source owner's reconciliation and lineage evidence. ^{[20] [6]}

Data Analysis and Evidence

What the public numbers actually support

The available quantitative evidence is program information rather than measured airline outcomes. The FAQ statements consolidated below are planning inputs. They do not quantify internal labour, vendor charges, validation effort or achievable fuel savings. Establish those separately from the airline's own scope and sample validation. ^[2]

Table 3 separates those statements from decisions the airline still has to make. The incentive information comes from its separate program page, which identifies the required core contributions and lists FOX as new in 2026. ^[8]

The table should prevent false precision. In particular, neither an onboarding target nor a no-fee statement measures the work required to reconcile existing sources. Detailed interface evidence is more useful for that estimate: a documented ARINC response can identify a candidate extraction path, but the installed version and entitlement still need confirmation. ^[4]

Measure the contribution, not an assumed benefit

A pilot should evaluate the contribution before estimating a financial benefit. This report does not calculate a return-on-investment percentage. Instead, a recommended pilot should establish a baseline using the airline's own approved scope and exceptions. The method should distinguish technical validity from operational completeness, since XML Schema constrains documents rather than defining the expected population of operated flights. ^[3]

Useful pilot measures include:

• Source coverage: expected in-scope legs with the selected operational records available.
• Join coverage: exported legs linked unambiguously to the applicable configuration.
• Validation results: accepted files and classified rejection reasons under the receiving specification.
• Correction workload: manual decisions required to resolve missing, amended or inconsistent records.
• Delivery evidence: acknowledged batches, retransmissions and checksum comparisons where supported.

Keep the measurement definitions with the pilot results. For example, a checksum comparison concerns the selected object's bytes, as illustrated in Amazon's documentation; it should not be reported as flight coverage. ^[20] Record selection and transformations belong in the lineage record so later reviewers can reproduce the population used in the analysis. ^[6]

Implications and Future Directions

The useful readiness outcome is an evidence package, not an assumption that more integration is always beneficial. Existing vendor interfaces may already expose useful records, but standards references require version-level checking. Jeppesen's published interface is a concrete example of why an airline should ask about the format actually returned by its installation. ^[4]

A proposed progression is:

• Decision scope: record the intended benefit, participating airline entity and approval owner.
• Source proof: obtain authorised samples and document record-selection policies.
• Receiving proof: obtain accepted specifications and resolve sample validation issues.
• Governance proof: approve purpose, roles, access, retention and relevant transfer arrangements.
• Operational proof: demonstrate monitoring, acknowledgement handling and correction ownership.

The governance stage should precede broad extraction. The ICO minimisation checklist asks whether less personal data can achieve the objective, while CNIL advises against assuming raw datasets are anonymous. A bridge should implement the approved field scope rather than make disclosure choices implicitly. ^{[10] [21]}

Change management then becomes part of participation. A source-system upgrade, new field or modified configuration mapping should trigger the relevant acceptance check again. Preserve enough lineage to identify which transformation produced a contribution. ^[6] For CSV, maintain the agreed import conventions rather than assuming every tool interprets the format identically. RFC 4180's informational status and compatibility discussion make that a practical concern. ^[17]

Security ownership should also survive staff and supplier changes. Keep service permissions aligned with the task, protect stored staging files and verify the agreed transfer mechanism. NIST's least-privilege definition and CISA's stored-data encryption guidance support these controls without making them universal FOX rules. ^{[7] [23]} The resulting participation decision is narrower and more defensible: approve a contribution whose provenance, authorised use and repeatable delivery can be demonstrated, then assess its analytical value from actual experience.

Frequently Asked Questions (FAQs)

Does an existing operational flight plan export suffice?

It may, if the licensed export matches the accepted receiving specification and the airline can select the appropriate source record. XML format by itself is insufficient evidence: XML Schema can constrain structure and contents, but acceptance also depends on the particular agreed schema and operational selection policy. Request validation of an actual sample. ^[3]

Is a load sheet the same as a load-final export?

Do not assume equivalence. A user-facing approval workflow and a machine-readable export are different capabilities to verify. NetLine Load's public description, for example, discusses load-sheet approval and integrated data sources without establishing a FOX-compatible export for an individual airline. Ask the load-control owner and vendor for the specific file and amendment semantics. ^[9]

Can configuration CSV be accepted without a mapping exercise?

A CSV file still needs agreed column meanings, missing-value handling and parsing conventions. RFC 4180 documents compatibility issues and does not claim to be an Internet standard. Confirm the recipient's layout and the airline's effective-date logic instead of inferring acceptance from the extension. ^[17]

Does recipient-side anonymisation remove the approval step?

No such conclusion follows from the public material. EDPB guidance distinguishes anonymisation from pseudonymisation, and ICO guidance asks organisations to identify the controllers throughout sharing. The airline should determine its disclosure authority and applicable obligations before transferring personal data, with jurisdiction-specific advice where needed. (Source: www.edpb.europa.eu) ^[5]

Conclusion

An airline can make a useful FOX readiness decision before committing to a substantial integration project. The recommended test is whether it can identify authorised source records, explain version selection, reconcile flight and configuration identities, and operate an approved delivery process. Document structure is only part of that evidence; lineage supplies the explanation of how records moved and changed. ^{[3] [6]}

Use the source matrix to locate the accountable owners and the synthetic matching example to expose ambiguity in a proposed join. Validate licensed exports against the receiving specification before deciding whether to add an adapter. Where a bridge is needed, keep its responsibilities explicit: authorised extraction, documented transformations, safe parsing, reconciliation and observable delivery. OWASP's guidance on external access during XML validation provides a concrete technical control to include in that design review. ^[18]

Approval should remain proportionate to the data being shared. Record purpose, roles and retention decisions, then give the delivery identity only the access needed for its task. ICO sharing-agreement guidance and NIST's least-privilege definition support those separate governance and security questions. ^{[5] [7]} The decision is strongest when each unresolved item has an owner and a resolution criterion. That makes existing-export sufficiency or the need for a limited bridge reviewable, while leaving participation benefits to be assessed from evidence rather than assumed results.