Three Rule Books. One Controller.

The Multi-AOC Problem Nobody Budgeted For

The commercial model made sense when it was one AOC and one client.

A charter operator with a single operating certificate, a homogeneous fleet, and a single set of EASA crew rules is a manageable operation. The crew system carries the rules. The planner builds the roster. The controller manages disruptions. The compliance trail is clean.

Then the second client arrived. Then the third. Then the wet lease contract that required a separate AOC in a different jurisdiction. Then the ACMI arrangement that brought a fourth client’s crew hour limitations into the mix.

Each addition was a rational commercial decision. None of them arrived with a budget line for the operational complexity they introduced. That budget line exists. It is just on the Hidden Ledger.

The Fleet and the People Running It

A seventy-five-aircraft ACMI operator running multiple AOCs employs approximately 788 crew. At charter and ACMI utilization rates, which run higher than scheduled operations, the crew ratio sits slightly below the full-service scheduled benchmark: approximately 5.0 pilots and 5.5 cabin crew per aircraft. That produces 375 pilots and 413 cabin crew across the combined operation.

The crew pool is not one pool. It is three or four pools, segmented by AOC employment terms, client qualification requirements, and the collective agreements that govern each entity. A crew member employed under AOC-A terms cannot always be assigned to an AOC-B service without a contractual review. A crew member qualified under Client 1’s training program may not satisfy Client 2’s currency requirements even if the underlying EASA qualification is identical.

The crew controller managing a seventy-five-aircraft ACMI disruption does not have one standby list. She has several, each with its own eligibility rules, and no system that shows her which crew member can cover which service under which contract without a manual cross-reference.

The Three-Minute Check That Takes Twenty-Three

A B737 service operating under Client 2’s ACMI contract has gone technical at an outstation. The crew controller needs a replacement crew qualified on the B737, legal under EASA FTL, available within positioning range, employed under an AOC whose terms permit assignment to Client 2’s services, and within Client 2’s monthly crew hour ceiling for the current contract period.

She opens the crew system. It shows available B737-qualified crew. It does not filter by AOC employment terms automatically. She applies the filter manually, eliminating crew employed under AOC-C whose CBA does not permit cross-assignment to Client 2 services without a forty-eight-hour notice period.

Remaining candidates: six. She opens the client compliance module, which runs on a separate database. She cross-references the six names against Client 2’s crew hour ledger. Two are within three hours of the monthly ceiling. She eliminates them.

Four candidates remain. She checks positioning. Two can reach the outstation within the required window. She confirms the first available.

Elapsed time: twenty-three minutes. The departure has been holding for sixteen of those minutes.

The three steps that consumed twenty minutes of that twenty-three -- AOC eligibility filter, client crew hour cross-reference, positioning calculation -- are three separate manual queries across two systems. On a purpose-built crew management platform that carries AOC employment parameters, client crew hour limits, and real-time positioning simultaneously, the same process takes under two minutes.

At seventy-five aircraft running multiple ACMI contracts, this scenario occurs multiple times per day during peak disruption periods. The annual direct operating cost of the twenty-minute manual process versus a two-minute integrated query, at EUR 100 per minute: EUR 3.65 million per year in direct delay exposure from the search gap alone. In total disruption cost terms -- EU261 compensation, client contract penalties, hotel accommodation, and repositioning -- the annual figure from this single process gap runs EUR 10 million to EUR 18 million.

The Reduced Rest Variation Nobody Updated

One of the AOCs holds a national CAA-approved variation for reduced rest at specific outstations where the scheduled rotation requires a hotel stop shorter than the EASA standard minimum. The variation was approved four years ago. It covers seven specific stations. It has been renewed twice. The current approval expires in five months.

The variation is managed in a supplementary document maintained by the compliance team. The crew system does not carry it as a configurable rule. The crew planner applies it manually when building rotations that touch the seven stations. The controller applies it manually when managing disruptions that produce unplanned overnights at those stations.

The variation expiry in five months is known to the compliance team. It is not surfaced in the crew system as an approaching constraint. It is not flagged in the roster building workflow. It will be managed through the supplementary document process, as it has been managed before.

When the variation expires, if the renewal is delayed, the seven stations become non-compliant for the rotation pattern that the variation currently supports. The rotations will need to be rebuilt. The crew pool availability at those stations will change. The client contracts that depend on those rotations will need to be reviewed.

None of this is catastrophic. All of it is expensive and preventable. A rules engine that carries the variation as a configurable parameter, flags its expiry ninety days in advance, and surfaces the affected rotations for review converts a compliance event into a managed project rather than a reactive crisis.

The Co-Pairing Problem Across Client Contracts

The ACMI operation requires flight deck and cabin crew to be co-paired: the same crew depart together, operate together, and return together. This is standard ACMI practice driven by client contracts, operational control requirements, and the practical reality of managing crew at outstations far from the home base.

The co-pairing requirement sounds simple. Its implementation across multiple AOCs and multiple client contracts is not.

Client 1 requires co-pairing at the rotation level: the same crew for the full rotation, with no mid-rotation replacement unless operationally necessary. Client 2 requires co-pairing at the duty level: the same crew for each duty day, with flexibility to reassign between duty days. Client 3 has no co-pairing requirement but pays a premium rate for consistent crew assignment across the contract period.

The crew system carries one co-pairing model. The crew planner applies the three client variations manually, using a reference document that was accurate when it was written and has been partially updated twice since. The controller managing a mid-rotation disruption checks the client contract reference before deciding whether to replace the full crew or just the affected crew member.

In one in five disruption events involving ACMI services, the controller makes the wrong call because the reference document is not the current version. The client raises a contract compliance query. The compliance team investigates. The investigation takes four hours. The commercial team documents the response. The event is resolved without penalty but at a cost of approximately EUR 3,500 in management time per occurrence.

At seventy-five aircraft running three client co-pairing models, this occurs approximately forty times per year. Annual cost: EUR 140,000. Over five years: EUR 700,000. From a reference document version control problem.

The Leave Planning Collision

Every year in January, the crew planning team builds the annual leave plan across all three AOCs. The process requires cross-referencing the leave entitlements under three different collective agreements, the minimum crew availability requirements for each client contract’s peak periods, the simulator availability constraints for annual recurrent training across two aircraft types, and the route authority requirements that mandate minimum crew numbers at specific bases throughout the year.

The process takes three weeks. It is performed manually using a master spreadsheet that the most experienced crew planner maintains and that no other member of the planning team fully understands.

The output is a leave plan that is approximately correct. It is correct enough that the operation runs. It is not optimized. Peak period availability is managed conservatively, which means more crew than necessary are constrained from leave during commercial peaks. Off-peak availability is managed liberally, which means leave clusters develop in specific months that create coverage problems the planner then manages through supplementary standby allocations.

The cost of the unoptimized leave plan is not visible as a line item. It is distributed across twelve months of slightly higher than necessary standby costs, slightly lower than possible crew utilization, and the annual three-week planning exercise that consumes the most experienced planner’s entire working capacity.

An optimizer that carries all three collective agreements, all client availability requirements, and all training constraints simultaneously does not eliminate the judgment required for annual leave planning. It makes the judgment available earlier, at a higher quality, and without three weeks of manual construction.

What the Ledger Says at 75 ACMI Aircraft

A seventy-five-aircraft multi-AOC ACMI operator running 788 crew under multiple EASA and national frameworks has a five-year Hidden Ledger that runs EUR 115 to EUR 175 million at conservative estimates.

The integration tax category is the dominant contributor at this tier. Every AOC addition, every client contract layer, and every supplementary rule document is a node in an architecture that was never designed as a whole. The maintenance cost of keeping the architecture functional -- the reference documents, the manual cross-references, the compliance queries, the version control failures -- is the integration tax compounded across three commercial structures.

The operational inefficiency category runs EUR 25 to EUR 40 million. The twenty-three-minute crew replacement search, the annual leave planning cycle, and the co-pairing reference document management are each individually manageable. Together they represent a systematic overhead that scales with every new AOC and every new client contract added to the operation.

The talent attrition category is the second-largest contributor. The crew planner who carries the leave planning spreadsheet and the compliance officer who maintains the variation documents are load-bearing knowledge holders in an architecture that has never been encoded in a system. When they leave, the knowledge leaves with them. At a seventy-five-aircraft multi-AOC operation, that knowledge is worth more than any individual’s salary.

The AI Question at Multi-AOC Scale

At seventy-five ACMI aircraft across multiple AOCs, the AI conversation takes its most commercially aggressive and technically most premature form.

AI-driven crew recovery optimization across multiple AOCs, client contracts, and co-pairing requirements is a genuine and valuable capability. It requires as its input a complete, integrated, real-time data layer that covers every AOC rule set, every client crew hour limit, every co-pairing model, and every collective agreement constraint simultaneously.

Most multi-AOC operators do not have this. They have a crew system built for one AOC, supplementary modules added as the commercial model grew, reference documents maintained by individuals rather than systems, and a controller who applies the integration layer manually on every disruption event.

The AI tool deployed against this architecture will be more confident than the manual process and no more accurate. It will recommend crew assignments that look correct in the crew system and need to be manually verified against two other sources before they can be actioned.

The homework at multi-AOC scale is not one project. It is an architecture review followed by a rule digitization project followed by a data integration project followed by the AI deployment.

Each step is the prerequisite for the next one. None of them can be skipped by buying the final step first.

---

Daniel Stecher is Vice President Business Development at IBS Software, representing iFlight Core globally. Over 20 years in aviation operations. 131 Operations Control Centers visited across 80+ countries. Founder of Airline Crewing and Operations Enigma, a community of 1,133 members across 261 airlines. Thinkers360 Global Top Influencer. All views his own.

Related reading: The Hidden Ledger / The Invoice Nobody Sends / The Cascade Nobody Saw Coming / Quo Vadis AI? / Five Quotients for the Age of AI / It’s Not the Big Who Eats the Small / The Bull in the China Shop Flies a Desk