The Boeing 737 MAX: An Operational Risk Case Study

Two 737 MAX aircraft crashed within four and a half months of each other, on 29 October 2018 and 10 March 2019, killing 346 people. The fleet was then grounded for 619 days, and the legal consequences ran until a federal judge dismissed the remaining criminal charge in November 2025, seven years after the first accident.

It is studied as an operational risk case because almost nothing about it was an accident in the ordinary sense. The exposure was created by a commercial decision, carried into the design by an engineering accommodation, concentrated onto a single sensor, and hidden from the people who would have had to respond to it. Every one of those is a control point, and each one is recognisable inside a bank.

Key Takeaways

• The exposure originated in a commercial commitment, that pilots would not need simulator training, which became a binding design constraint on the engineers.
• MCAS acted on a single angle of attack sensor, so one faulty input could command a nose-down trim against the crew, with no redundancy behind it.
• The system was absent from the flight manual and from pilot training, leaving the last line of defence uninformed of what it was defending against.
• Certification relied on manufacturer employees delegated by the regulator, the same structural weakness as a model validation team that reports to the desk it validates.
• The FAA grounding ran 619 days, from 13 March 2019 to 18 November 2020, and stopped the deliveries on which an aircraft manufacturer is paid.
• Settlements of over 2.5 billion dollars in 2021 and about 1.1 billion in 2025 are small against direct costs estimated near 20 billion, so the fines are the visible part rather than the large part.
• A firm with 40 years of loss data topping out at 80 million cannot produce a 20 billion figure from any percentile of that history, which is why scenario analysis exists as a separate input.

What happened, and in what order

The sequence matters more than any single date, because the interval between the two accidents is where the operational risk lesson sits.

Read the first three rows again. Four and a half months separated the two accidents, and the aircraft kept flying through them. That interval is the part of the case that belongs to risk management rather than to engineering, because by then the firm had a loss event, an investigation, and a known failure mode, and the fleet was still in service.

The decision that created the exposure

The 737 MAX was a re-engining of an airframe first certified in the 1960s. The new engines were larger and more efficient, and fitting them under a wing designed for smaller ones meant mounting them further forward and higher. That changed how the aircraft behaved at high angles of attack.

The design response, according to the accident investigations and the regulatory reviews that followed, was a software system called the Manoeuvring Characteristics Augmentation System, or MCAS, which trimmed the horizontal stabiliser nose-down when it judged the angle of attack to be too high. The purpose was to make the new aircraft handle like the old one.

The commercial reason for wanting that is the part worth dwelling on. If the MAX handled like earlier 737s, it could share their type rating, and airlines could move pilots onto it without simulator training. Simulator training is expensive and slow, and avoiding it was a genuine selling point against the competing aircraft. A cheaper transition for the customer was, in effect, a design constraint on the engineer.

One sensor, and the anatomy of the control failure

The investigations into both accidents found that MCAS acted on the reading from a single angle of attack sensor. If that sensor gave a faulty reading, the system responded to a condition that was not occurring, and pushed the nose down against the pilots who were trying to raise it.

Aviation design is built on redundancy, and a single input driving an authority of that kind is the sort of arrangement redundancy exists to prevent. Two further conditions turned a design vulnerability into an accident: MCAS was not described in the flight manual, and pilots were not trained on it, so the crews encountering it had no name for what was happening to their aircraft.

Figure 1. Four controls, all pointing the same way

Note what that chain implies for measurement. There is no single cause to attach a probability to. There are four control points, each of which would have broken the sequence, and the event required all four to fail together. Operational risk failures are almost always shaped this way, and it is why control self-assessment asks about layers rather than about causes.

The regulator inside the firm

Aircraft certification in the United States has long relied on delegation. The regulator authorises employees of the manufacturer to perform specified certification work on its behalf, because the manufacturer holds the technical expertise and the regulator does not have the staff to duplicate it. The arrangement is not a secret and it is not unique to aviation. Model validation, internal audit and internal ratings-based credit models all run on some version of it.

The difficulty with delegated assurance is structural rather than personal. The people performing the check are paid by the organisation being checked, and they sit inside its schedule pressure. Independence in that setting depends on reporting lines and on culture, not on job titles, and both of those are difficult to observe from outside.

This is the closest the case comes to a directly transferable lesson for a financial institution. A bank that lets the desk that owns a model choose who validates it has built the same arrangement, and will discover the same thing about it under the same conditions: when the calendar is tight and the finding is inconvenient.

Where it sits in the operational risk taxonomy

The standard taxonomy classifies operational loss events by cause. This one is not a rogue trader, not a system outage, and not external fraud. It is a failure in the design, delivery and management of a product, which is the category most often skipped in a risk taxonomy discussion because it sounds like someone else’s problem.

How the loss actually arrived

A risk manager reading only the settlement figures would draw the wrong picture of the loss. The legal penalties are the visible part and the smaller part.

The estimates in the last two rows are analyst figures rather than reported ones and should be read as orders of magnitude. Even so, the shape they describe is unambiguous: the fines are a rounding error against the operational consequences. The 619-day grounding stopped deliveries, and deliveries are when an aircraft manufacturer is paid.

The 2024 door plug event belongs in the same account for a different reason. Nobody died, and by the standards of the earlier accidents it was a minor event. Its significance is that it arrived while the firm was operating under a compliance agreement arising from the first losses, and the Department of Justice subsequently determined that the compliance obligations of that agreement had been breached. That is what turned a settled matter back into an open one four years later.

What a risk manager takes from it

Five points survive the transfer from aviation to finance.

A commercial promise is a risk decision. When a commitment about cost, speed or continuity is made before the technical work is scoped, the constraint it creates is real and someone downstream will absorb it. Risk functions that review products after design see this too late.

Redundancy is worth its cost precisely on the inputs that seem reliable. A single input driving an automated action with real authority is an exposure whether that input is a sensor, a price feed, a rating, or a single approver.

Assurance that reports to the business it assures is not assurance. Delegated checking works while the calendar is comfortable and stops working when it is not, which is exactly when it is needed.

The last line of defence has to be told what it is defending against. The flight crews were the final control and were not informed of the system they were fighting. The equivalent in a bank is an operations team executing a process whose failure modes have never been explained to it.

And the interval between the first loss and the second is the part to study. There was a loss event, an investigation and a known failure mode, and the fleet continued flying for four and a half months. Whether a firm can stop something profitable while it does not yet know how bad the problem is, on incomplete information and with the commercial cost immediate and certain, is the question this case actually asks. Most risk frameworks are written as though that decision is procedural. It is not, and the interval is where the framework is tested.

The short version

• The chain ran from a commercial constraint, to a software workaround, to a single sensor input, to an undisclosed system, and every link was a control point that could have broken it.
• Four and a half months and one investigation separated the two accidents, and the fleet kept flying through them. That interval is the risk management question the case actually poses.
• Delegated certification puts the checker inside the schedule pressure of the checked, which is the same structure as assurance functions that report to the business they assure.
• The event type, failure in product design and delivery, is the one least represented in internal loss data and the one carrying the fattest tail.
• Legal settlements totalled a few billion dollars. The grounding, the production halt and the lost orders were an order of magnitude larger.
• A minor incident in January 2024 reopened a matter settled in 2021, because it happened under a compliance agreement the Department of Justice later found had been breached.

Frequently Asked Questions