NAT RCL Messages in OCC Software: Receipt and OCA Scope

Executive Summary

NAT RCL messages in OCC software should be represented as evidence with a defined source and scope. An operations control centre (OCC) needs to distinguish the submitted Request for Clearance (RCL), its receipt response, any subsequent air traffic control (ATC) amendment, and the communications provider's copy. ICAO's oceanic-clearance-removal bulletin explicitly says that an RCL or RCL RECEIVED is not a clearance. (Source: www.icao.int) Historical practitioner coverage already explains the receipt distinction; the ground-system problem is preserving that distinction across records and revisions. ^[1]

Applicability requires an edition as well as an oceanic control area (OCA). ICAO's September 2026 checklist still lists Revision 6, dated 25 February 2026. (Source: www.icao.int) NAT Doc 007 V.2026-1 applies from 19 March 2026. (Source: www.icao.int) The bulletin retains Shanwick oceanic clearances until further notice. (Source: www.icao.int) Iceland's supplement separately discontinues its RCL requirement from March 2026, illustrating why clearance removal and RCL removal need separate fields. (Source: eaip.avians.is)

Later sources also matter. NAV CANADA's supplement describes resumed controller-pilot data link communications (CPDLC) route amendments for specified eastbound Gander traffic before oceanic entry. ^[2] An OCC design should therefore preserve amendment channel and applicability evidence rather than infer either from an old rollout summary. This research did not complete a live Notice to Airmen (NOTAM) review or establish all-area operational applicability on the publication date. Canada's supplement itself gives NOTAMs precedence. ^[2]

The purchasing decision starts with the installed provider. Collins documents customer message logs; SITA describes ACARS information extraction; Gogo documents downloadable historical datalink reports. These capabilities justify a native-product evaluation, but do not establish a particular operator's RCL export coverage. ^[3] (Source: www.sita.aero) ^[4] The proposed evaluation has three outputs: a source-dated applicability register, a record-level evidence matrix, and a replay of ambiguous flight revisions. Configure a supported product when it supplies the required evidence. Consider a bounded custom ground interface only for a demonstrated residual gap. All proposed states and examples below are engineering hypotheses for validation with the operator and provider. They are not clearance decisions, crew procedures, or an ICAO interface specification.

Introduction and Background

An RCL label can be misleading when transported into a dashboard without its procedural context. Ireland's aeronautical information publication (AIP) describes the message as providing estimated arrival at the oceanic entry point (OEP), requested flight level and Mach through voice or the Aircraft Communications Addressing and Reporting System (ACARS). (Source: www.airnav.ie) Those requested values deserve their own record. They should not silently become the application's representation of an assigned route or level. In the proposed model, filed routes, NAT track publications and operator dispatch releases remain separate record classes. None substitutes for an RCL submission, observed response or ATC amendment.

The communications category also matters. Honeywell's historical technical explanation distinguishes ARINC 623 messaging from Future Air Navigation System (FANS) or Aeronautical Telecommunication Network (ATN) CPDLC. ^[5] Collins separately describes airline operational control messages carried by ACARS. ^[3] A shared transport or screen does not justify merging the business meaning of every message it carries.

Dated 28 October 2026, this report addresses airline and business-aviation OCC managers, flight-planning data owners and integrators evaluating ground evidence. Its intended deliverable is a procurement and reconciliation reference. The operator should validate terminology, ownership and permissions against its own arrangements before adopting any proposed state. NAT Doc 007 describes itself as guidance and points readers to the applicable source framework, including state publications and current NOTAMs. (Source: www.icao.int)

The report therefore separates documented facts, research gaps, and proposed controls. Specialist explanations remain useful background: OPSGROUP's historical article displays changing regional rollout dates, while NBAA discusses the distinction between receipt and a reroute clearance. (Source: ops.group) ^[1] Neither is treated here as a live applicability service. The practical question is narrower: can the installed system show what was submitted, what response was observed, which flight revision it concerns, and which source supports the interpretation?

Key Changes

Receipt meaning must survive ingestion

The core semantic boundary is simple: RCL receipt is not clearance evidence. The ICAO bulletin states this explicitly. (Source: www.icao.int) An engineering consequence is to preserve a receipt as a response to a particular submission, with its original wording and provenance, rather than as a general approval attached to a flight.

Even apparently affirmative text needs source context. Avinor's historical circular includes the response wording FLY CURRENT FLIGHT PLAN OR AS AMENDED BY ATC and separately explains the absence of a traditional ACARS clearance. (Source: partner.avinor.no) A parser that recognizes only a positive-looking phrase would lose that distinction. Proposed classifications should describe the record observed, such as “receipt response observed,” and leave operational interpretation to the authorized process.

Requested content needs the same separation. NAT Doc 007 describes storage of the requested flight level information. (Source: www.icao.int) A ground interface should retain the submitted value as requested content, without overwriting it with a later assigned value or treating storage as acceptance. This proposed separation makes changes explainable when a user inspects the record history.

Amendments need their own evidence chain

The bulletin describes route amendments separately from receipt of the RCL, using voice or a CPDLC loadable route clearance uplink. (Source: www.icao.int) That distinction supports separate amendment records, with an explicit channel and an accessible source copy where the provider makes one available.

More recent regional publications can refine that context. NAV CANADA's SUP 065/2026 addresses resumption of CPDLC route amendments for specified eastbound Gander OCA traffic before oceanic entry. ^[2] The system should preserve that narrower scope rather than promote it into a universal North Atlantic channel rule.

Message content cannot safely be reduced to a generic “route received” label. The FAA's explanation of UM80 identifies it as a new route rather than a cleared-as-filed message. ^[6] The proposed ground model should consequently retain message type and payload alongside the provider's transport event. If only a notification is available, its record should say that the amendment payload is unavailable.

Removal is not one region-wide flag

Iceland's official supplement distinguishes earlier oceanic-clearance removal from subsequent discontinuation of RCL. (Source: eaip.avians.is) It also specifies the automated response RCL NOT REQUIRED BY BIRD. (Source: eaip.avians.is) These are different changes, with different implications for what an OCC expects to observe.

New York requires its own source context. The FAA AIP says New York ARTCC no longer issues an oceanic clearance, and separately distinguishes filed level changes from cleared-as-filed treatment. ^[7] An application should therefore avoid promoting “clearance removed” into an assumption that every filed value is authorized or that every OCA has the same RCL process.

Source Editions and OCA Applicability

The proposed applicability register associates a procedure interpretation with an area, source edition, effective interval and validation owner. Its purpose is to expose uncertainty. A document's issue date, its stated implementation date and the time a provider imported it should remain separate fields.

Table 1 summarizes the source-dated evidence found for the named areas. It is an evidence register, not a determination of current operational status. Where a local source could not be fully checked, that limitation remains visible. The Revision 6 snapshot requires RCL for Bodø, Gander, Santa Maria and Shanwick, but not New York East or Reykjavik. (Source: www.icao.int)

The matrix intentionally contains unknowns. It does not assign an operational green status merely because a reference was found. Ireland's referral to the UK publication demonstrates why a source chain may cross publishing authorities. (Source: www.airnav.ie) The UK AIP portal also warns that its links change with each Aeronautical Information Regulation and Control (AIRAC) cycle. ^[8]

For each register entry, the proposed minimum is:

• Area identity: preserve the source's geographic terminology and any direction or boundary qualification.
• Source object: retain the complete URL, document identifier, edition and exact file variant.
• Date fields: distinguish publication, stated applicability, retrieval and internal review dates.
• Status: distinguish reviewed, unknown, superseded and awaiting source reconciliation.
• Dependencies: record the state AIP, supplement and NOTAM checks still required.
• Ownership: name the operator role responsible for approving the interpretation.

Exact source objects matter because ICAO's folder lists standard and sidebar versions of the manual. (Source: www.icao.int) A title alone is insufficient for reproducibility. Proposed storage should retain the fetched object's identity and relevant section, subject to retention rights, so that later reviewers can establish which publication supported a past display.

Implementation Considerations and Process Changes

Separate the record from its interpretation

The proposed data model keeps original provider evidence immutable and appends interpretation as a separately versioned result. This is a design hypothesis, not a documented ICAO schema. SITA's published extraction and integration capabilities make it reasonable to ask first whether existing provider configuration can expose the required fields. (Source: www.sita.aero)

Table 2 maps the principal records to the evidence an OCC would seek. Field names below are illustrative procurement terms. An operator should accept a provider's supported equivalent when its meaning is documented.

The table separates observation from conclusion. Collins' documented account logs and Gogo's historical reports are relevant evidence channels, but neither public description establishes all the fields in this matrix for a particular contract. ^{[3] [4]} The acceptance test should use representative provider records rather than assume that a marketing category guarantees a complete export.

Correlate flight identity and revision explicitly

A callsign alone is a weak proposed reconciliation key when identity can change. Honeywell's dated technical explanation specifically discusses matching variable callsigns with the flight plan. ^[5] The engineering response is to preserve identity history and provider identifiers, not to invent a universal concatenated key.

Relevant standards illustrate this distinction without proving RCL support. Flight Information Exchange Model (FIXM) includes a previous-aircraft-identification element. (Source: fixm.aero) EUROCONTROL describes the Globally Unique Flight Identifier (GUFI) as helping associate messages with the correct flight. (Source: www.eurocontrol.int) Neither fact establishes that a contracted RCL feed carries GUFI or that an OCC can use it without an agreed mapping.

The proposed correlation contract should state:

• Flight reference: which identifier remains stable across the provider's supported workflow.
• Identity history: how prior and replacement callsigns are retained.
• Revision reference: how submitted content links to the exact planning revision.
• Entry context: how OEP changes affect matching and applicability.
• Transaction reference: whether a response identifies a submission directly or requires a documented rule.
• Clock meaning: whether each timestamp represents creation, transmission, provider ingestion or OCC receipt.

Timestamp labels deserve particular care. FIXM's GUFI creationTime means the time the identifier was created. (Source: fixm.aero) It should not be relabeled as the arrival time of a later message copy. Equivalent distinctions should be documented for each actual provider field before users compare event order.

Replay ambiguity before accepting the interface

Hypothetical Example: delayed evidence after a revision. The following artificial sequence uses TEST-A and TEST-B as record labels, contains no flyable route, and defines no operational timeout:

• Submission A: TEST-A is associated with an initial planning revision and an artificial entry-point label.
• Receipt A: an observed response is explicitly correlated with submission A.
• Revision B: the planning owner creates TEST-B with a changed identity or entry context.
• Delayed copy A: an older receipt copy arrives after revision B.
• Amendment reference: a separate record indicates an amendment whose payload needs inspection.
• Voice reference: activity is recorded, but no accessible transcript is available.

The proposed result is to keep the receipt attached to submission A and expose the unresolved relationship to revision B. It must not become an all-purpose “current flight accepted” state. Boeing's RouteSync documentation concerns recorded airline operational control (AOC) messages, which further illustrates why a recorded route transfer and an ATC amendment require different classifications. ^[9]

Additional replay cases should exercise the same evidence boundary:

• Stale applicability: a retained source has been superseded or its review status is unknown.
• Changed area: a planning revision changes the applicable OCA.
• Changed identity: the earlier callsign still appears in an incoming copy.
• Contradictory copies: source records differ and neither can be silently discarded.
• Partial visibility: the feed covers submissions but not all responses or amendments.
• Unresolved voice content: the system displays an evidence gap rather than synthesizing a clearance.

These are proposed acceptance cases, not claims that any named provider exhibits those conditions. Their purpose is to make the operator's evidence expectations testable before implementation.

Evaluate Native Coverage Before a Custom Interface

Public product descriptions provide a starting point for procurement, with carefully bounded implications. Collins ARINCDirect documents message logs in customer accounts. ^[3] SITA AIRCOM ServerPlatform describes extracting ACARS information and integration through standardized formats and templates. (Source: www.sita.aero) Those are reasons to request a demonstration using the operator's own permitted records, rather than reasons to assume a NAT-specific interface exists.

Other providers document adjacent capabilities. Honeywell describes cockpit-to-ground datalink communications and integration with flight-planning providers. ^[10] AIR SUPPORT PPS describes third-party integration using application programming interface (API) or Simple Object Access Protocol (SOAP) interfaces. (Source: air-support.aero) An integration mechanism is not itself a contract for exporting RCL submission-response relationships.

Gogo's SD Pro brochure describes downloadable historical datalink reports. ^[4] Boeing RouteSync documents recorded route and ACARS data that can be shared with other operational systems. ^[9] Procurement should identify the exact product, module, entitlement and covered message categories before comparing these descriptions. The research found no public evidence establishing complete NAT RCL submissions, receipts, ATC amendments and voice transcripts in any particular operator's contracted feed.

Table 3 compares implementation paths rather than ranking communications products. LANDING.AERO appears as the publisher's custom-software position, not as a datalink, dispatch or clearance provider. The row specifies the proposed boundary of a potential project, without claiming an existing RCL product.

The preferred path is whichever supported arrangement satisfies the operator's requirements with explainable evidence and ownership. The table makes no claim that custom work is necessary. A missing configuration, entitlement or report can have a different remedy from an absent source record.

The proposed provider review asks for concrete deliverables:

• Coverage statement: identify included areas, directions, channels and message categories.
• Record samples: supply permitted submissions, receipts, rejections and amendment copies with original payloads.
• Identifier dictionary: explain message, flight, revision and transaction identifiers.
• Ordering statement: document duplicate, retry, replay and out-of-order behavior.
• Clock dictionary: define every exported timestamp and its provenance.
• Access agreement: establish permissions, retention, redisplay and deletion obligations.
• Voice boundary: state whether any transcript or amendment evidence is accessible.
• Exception owner: identify who resolves unmatched, contradictory or missing evidence.

These are proposed contractual questions, not undocumented provider commitments. EUROCONTROL's separate flight-data service guidance explicitly notes that customer arrangements with a service provider can differ. (Source: www.eurocontrol.int) The same procurement discipline is useful here: establish the actual arrangement before designing around it. A demonstration should finish with sample evidence and unresolved items recorded, not an unsupported statement that every oceanic message is covered.

Data Analysis and Evidence

Dates are evidence dimensions, not performance statistics

The numerical evidence available for this topic is primarily source chronology, not a market-size or latency dataset. ICAO's September checklist lists the clearance-removal bulletin at Revision 6 with its February 2026 date. (Source: www.icao.int) Iceland's supplement distinguishes clearance removal in spring 2024 from RCL discontinuation in March 2026. (Source: eaip.avians.is) Those source facts support edition-aware records; they do not support a numerical estimate of provider coverage.

NAV CANADA's SUP 065/2026 also shows why date normalization requires care. Its published and effective headers show 9 July 2026, while its body describes the resumption as effective 3 July 2026. ^[2] The proposed register should preserve both stated dates and flag the interpretation for the responsible owner, rather than silently substitute one. The supplement also gives associated NOTAMs precedence. ^[2]

Publication cycles add another distinction. NAV CANADA states that AIP Canada is updated every 56 days and distinguishes its current issue from the next issue. ^[11] The UK publisher warns of AIRAC-dependent links and offers an offline PDF option. ^[8] A stable-looking URL, a recently retrieved page and a future-effective publication are therefore different evidence attributes.

A bounded reconciliation calculation

Hypothetical Example: synthetic reconciliation dataset. Assume an authorized export contains 140 submission-event rows, of which 20 are documented duplicates. The eligible denominator is consequently 120 distinct submissions. Assume 96 have an unambiguous matching receipt by a defined extraction cutoff. The proposed observed matching completeness is 96 / 120 = 80%. The remaining 24 submissions are reported as having no matched response in this covered dataset.

Every quantity in this example is invented for arithmetic illustration. It is not measured provider performance, a clearance compliance rate, an operational threshold or a recommended waiting period. If 3 later responses match the same denominator, a subsequent snapshot becomes 99 / 120 = 82.5%. The earlier snapshot should remain reproducible rather than be retroactively presented as having had those responses.

Before using such a metric, the proposed analysis records:

• Eligibility: which submissions belong to the defined area, period and covered feed.
• Deduplication: which provider rule establishes that rows represent the same submission.
• Matching: which identifiers or validated rules establish a receipt relationship.
• Cutoff: the extraction instant and relevant timestamp semantics.
• Unknowns: unlinked responses, inaccessible channels and unsupported applicability.
• Revisions: whether the linked response concerns the current planning version.

Provider historical reports may provide material to test, but public descriptions do not establish this denominator or matching rule. ^[4] No numerical latency target, coverage percentage, customer result, search volume or growth estimate is asserted in this report.

Implications and Future Directions

The useful future improvement is more explicit evidence, not a stronger-looking status label. A provider-supported export could make submissions, responses and amendment copies easier to inspect, but its coverage still needs documentation. Boeing's sharing of recorded route and ACARS data illustrates an existing integration building block, not proof of an end-to-end NAT RCL evidence service. ^[9]

For the operator, the proposed governance model keeps applicability ownership separate from feed maintenance. A source reviewer decides which publication supports an interpretation. A data owner validates correlation and coverage. An exception owner resolves records that the interface cannot reconcile. The application records these decisions and their provenance without changing operational authority.

Version-aware flight identification may help where contracted systems support it. FIXM's previous-identification field and EUROCONTROL's description of GUFI provide relevant reference concepts. (Source: fixm.aero) (Source: www.eurocontrol.int) They should be evaluated as supported inputs, not imposed on a feed that lacks them. Likewise, adding a natural-language classifier would not supply a missing message, missing permission or unavailable voice transcript. Any proposed automated classification needs validation against original records and an explicit unresolved state.

NATS states that links from its UK AIP page change with every AIRAC cycle. ^[8] Proposed acceptance example: load a retained procedure reference and a newer edition with a changed provision into a synthetic dataset. The OCC should flag the affected applicability entry for review rather than carry its interpretation forward automatically. After the designated reviewer confirms the change, mark the earlier interpretation as superseded, retain its source edition and effective interval, and associate the replacement interpretation with the new edition. Historical flight records should continue to show which interpretation supported their original display.

The proposed publication asset is therefore the dated matrix and its acceptance questions. It can be updated when a new primary source is verified, with old interpretations preserved as superseded. The practical decision remains whether native supported capabilities meet the operator's evidence needs and, if they do not, whether a precisely defined ground-data gap warrants additional integration.

Frequently Asked Questions (FAQs)

What does NAT RCL acknowledgement mean?

In this report, acknowledgement means an observed response associated with a submission, with its exact wording preserved. It should not become a blanket approval state. NBAA's explanation distinguishes the received response from a full clearance. ^[1] The provider must document which response records its product actually exposes.

Is an RCL the same as an oceanic clearance?

The distinction depends on the record and applicable procedure. A request, a receipt response and a separately issued clearance must retain separate meanings. Avinor's historical circular explicitly distinguishes its response from a traditional ACARS clearance. (Source: partner.avinor.no) Historical terminology in a product description is insufficient to establish current area-specific procedure.

Do RCL requirements apply throughout the North Atlantic?

No single RCL-required flag captures the source evidence. Iceland's supplement discontinues the requirement in its control area, while Ireland's AIP refers readers to UK procedures for specified RCL contexts. (Source: eaip.avians.is) (Source: www.airnav.ie) The register should retain area, source edition and unresolved applicability checks.

Can an OCC infer amendments from the filed route?

The proposed model does not make that inference. Filed data, requested changes, recorded AOC route transfers and ATC amendments are separate evidence categories. Boeing documents AOC message recording; the FAA separately explains the meaning of an actual route-clearance uplink. ^{[9] [6]} Only a validated source contract can establish what the OCC observes.

Conclusion

The decision about NAT RCL messages in OCC software is a decision about evidence boundaries. A useful ground record identifies the submission, preserves the response, links any independently observed amendment and states which source edition supports its interpretation. It also makes missing coverage and unresolved applicability visible.

The recommended procurement sequence is to define the evidence matrix, obtain representative records from the installed provider, replay ambiguous revisions and document the remaining gaps. Native configuration should be evaluated before a new interface. An integration proposal becomes reviewable when it names the exact missing capability, supported data source, permissions, matching semantics and exception owner.

The source register should distinguish historical explanations from primary publications, publication dates from applicability dates, and reviewed evidence from outstanding checks. A source change should create an explicit review item rather than silently alter the meaning of old records. A late copy should preserve its relationship to the original submission rather than acquire the status of a newer planning revision.

All interface states, acceptance cases and calculations in this report are proposed ground-system tools. They do not establish clearance, prescribe airborne action or replace an operator's applicable procedures. The strongest outcome is an explainable record: users can see what the system observed, what it matched, what it cannot establish and who owns the unresolved evidence.