{"id":29597,"date":"2026-01-30T08:55:25","date_gmt":"2026-01-30T13:55:25","guid":{"rendered":"https:\/\/ops.group\/blog\/?p=29597"},"modified":"2026-03-19T10:42:52","modified_gmt":"2026-03-19T14:42:52","slug":"new-nat-doc-007-north-atlantic-changes-from-march-2026","status":"publish","type":"post","link":"https:\/\/ops.group\/blog\/new-nat-doc-007-north-atlantic-changes-from-march-2026\/","title":{"rendered":"New NAT Doc 007: North Atlantic Changes from March 2026"},"content":{"rendered":"

A new NAT Doc has landed, effective 19 March 2026.<\/strong> As ever, it\u2019s a meaty sucker, and probably not something you\u2019ll want to read cover to cover. So we\u2019ve done that part for you. We\u2019ve gone through it and pulled out the changes that actually matter operationally, plus a few important \u201cthis hasn\u2019t changed\u201d reminders. If you\u2019re crossing the North Atlantic, this is the stuff worth knowing.<\/p>\n

You can access the new 2026 version<\/strong> of the doc here<\/a>, and the old 2025 version<\/strong> here<\/a>, if you want to compare the two.<\/p>\n

\"\"<\/p>\n

Shanwick OCR delay<\/h5>\n

The new NAT Doc now clearly states what operators have known for a while: Shanwick has not implemented Oceanic Clearance Removal.<\/strong> A specific note states that, due to delayed OCR implementation, Shanwick will continue issuing oceanic clearances following submission of an RCL, until further notice.<\/p>\n

The document itself does not give a timeline. However, Shanwick has separately confirmed that OCR is not expected to go live before summer 2026.<\/strong> Operationally, nothing changes at Shanwick for now – crews must still request and fly an oceanic clearance. The key point is that, despite much of Chapter 6 reading like an OCR-style environment, Shanwick is explicitly not there yet.<\/p>\n

Ref: Chapter 6, Section 6.3.<\/em><\/p>\n

RCL timing switches from ETA to ETO – new terminology<\/h5>\n

The new 2026 edition introduces ETO – Estimated Time Over Significant Point<\/strong> for the Oceanic Entry Point in RCLs, replacing the way ETA was used in previous editions.<\/p>\n

Doc 007 doesn\u2019t explicitly explain the change, but the logic is pretty clear. ETA can be vague and is often taken as a general arrival estimate. ETO is much more precise – it\u2019s the FMS-predicted time over a specific waypoint. That\u2019s what ATC actually uses for longitudinal separation in procedural airspace.<\/p>\n

The shift also lines up with two big themes in the new doc: the move toward OCR-style operations, and growing concern about time accuracy after GNSS jamming and spoofing.<\/p>\n

Ref: Chapter 6, Sections 6.3.23-6.3.25<\/em><\/p>\n

Reykjavik no longer requires an RCL<\/h5>\n

Reykjavik effectively steps away from the RCL process altogether in the 2026 edition. Doc 007 now says that an RCL is not required for Reykjavik, and that if one is sent anyway, crews will be told it wasn\u2019t needed.<\/strong><\/p>\n

The main issue with RCL was confusion with some crews about what it actually meant. In some cases, crews assumed that once they\u2019d sent it, they could climb or descend to the level in the message without first receiving an ATC clearance. So Reykjavik have decided to discontinue RCL altogether for safety reasons.<\/p>\n

Other NAT OCAs still require RCLs, so this doesn\u2019t simplify things overall. It just means procedures are even more mixed than before. The main risk for operators is assuming the same process applies everywhere across the NAT, when it very much doesn\u2019t!<\/p>\n

Ref: Chapter 6, Section 6.3.24<\/em><\/p>\n

Bigger push on FMS waypoint and route verification<\/h5>\n

The 2026 doc puts much more weight on careful FMS programming and verification. It highlights known traps with half-degree waypoints, ARINC 424 coding, and CPDLC route amendments that arrive in full LAT\/LONG and don\u2019t visually match stored waypoint names.<\/p>\n

There\u2019s a strong emphasis on independent PF\/PM crosschecks and verifying expanded coordinates, courses, and distances. This isn\u2019t theoretical – it\u2019s a direct response to navigation errors seen since OCR and more frequent CPDLC route changes.<\/p>\n

Ref: Chapter 6, Sections 6.3.18-6.3.32<\/em><\/p>\n

GNSS interference treated as a routine NAT problem<\/h5>\n

GNSS jamming and spoofing are no longer treated as rare edge cases.<\/strong> In the 2026 doc, they\u2019re framed as a normal operational hazard. The guidance highlights how GNSS interference can quietly degrade aircraft time, with knock-on effects to ADS-C, ADS-B, CPDLC, and longitudinal separation – even after position accuracy appears to have recovered.<\/p>\n

The practical takeaway is simple: \u201cit recovered\u201d doesn\u2019t mean \u201cit\u2019s fine\u201d.<\/strong> So operators need to think about downstream impacts before entering the NAT. More detailed guidance is in NAT Ops Bulletin 2025-001<\/a>, which sets out what to watch for and what to do if you\u2019re entering the NAT with GPS problems. This mainly affects westbound flights coming out of spoofing or jamming areas. Bottom line – tell ATC early in your RCL if there are any issues. Doing so can help avoid off-track reroutes, step-downs, and delays.<\/p>\n

Ref: Chapter 1 and Chapter 6 (Plus referenced NAT Ops Bulletin as above)<\/em><\/p>\n

Flight Level Allocation Scheme (FLAS) – now gone<\/h5>\n

Until now, NAT Doc 007 included a Flight Level Allocation Scheme (FLAS)<\/a>. It was a simple table that gave crews and dispatchers a sensible planning starting point for random routes outside the OTS, mainly by biasing eastbound and westbound traffic onto different flight levels.<\/strong> It wasn\u2019t mandatory, but if you planned within FLAS, you were usually aligned with what ATC expected.<\/p>\n

\"\"<\/a><\/p>\n

In the March 2026 edition, FLAS has quietly disappeared. The attachment has been removed and there\u2019s no replacement scheme. Instead, the new wording says that random-route flights can plan any flight level<\/strong>, as long as it works with traffic flows and ATC can make it fit. \ud83e\udd14<\/p>\n

\"\"<\/a><\/p>\n

So there’s nothing in the new Doc to say that the old FLAS separation logic has disappeared – it’s just no longer explicitly written down! We’re guessing the practical impact will be less predictability up front and more tactical level changes, especially if you\u2019re flying counter-flow or close to track changeover times.<\/p>\n

What didn\u2019t change<\/h5>\n

Despite all the discussion around NAT procedures lately, the new NAT Doc does not introduce new requirements in several key areas:<\/strong><\/p>\n