CrowdStrike outage of 19 July 2024: what Channel File 291 means for payment and banking tests

The CrowdStrike outage timeline, from the vendor and the regulators

On 3 June 2026, Frank Elderson, Vice-Chair of the ECB Supervisory Board, cited the outage in a speech on operational resilience: "Another example is the CrowdStrike incident in 2024, when systems using a major operating platform crashed and displayed the 'blue screen of death'. The disruption affected firms across sectors, including financial services." The same speech states that banks "increasingly rely on external providers for some critical functions that are difficult or impossible to replace". The Federal Reserve Board's October 2025 operational risk model documentation also uses the outage as an example of an operational event, so we set out the public record and the tests it points to.

The PIR limits the impact to "Windows hosts running sensor version 7.11 and above that were online between Friday, July 19, 2024 04:09 UTC and Friday, July 19, 2024 05:27 UTC and received the update. Mac and Linux hosts were not impacted." Microsoft put the count at "8.5 million Windows devices, or less than one percent of all Windows machines."

The RCA gives the defect. "The new IPC Template Type defined 21 input parameter fields, but the integration code that invoked the Content Interpreter with Channel File 291's Template Instances supplied only 20 input values to match against." Tests and the earlier Template Instances used a wildcard for the 21st field, so nothing read it. On 19 July, one new Template Instance "introduced a non-wildcard matching criterion for the 21st input parameter", and the out-of-bounds read "resulted in a system crash." The Content Validator passed the content because it expected 21 inputs. The PIR explains the release decision: "Based on the testing performed before the initial deployment of the Template Type (on March 05, 2024), trust in the checks performed in the Content Validator, and previous successful IPC Template Instance deployments, these instances were deployed into production." RCA finding 6 reads: "Each Template Instance should be deployed in a staged rollout."

For the financial sector, the FCA wrote: "As CrowdStrike is widely used, we saw varying degrees of operational impact on regulated firms, with no sector more impacted than others, and minimal consumer harm." A footnote in the Federal Reserve Board document states: "The CrowdStrike incident created transactions processing problems at some financial firms." Neither source quantifies payment losses, and we do not either.

Why the Channel File 291 failure matters for fintech testing

We read two failure classes in the sources. The first is a producer and consumer contract mismatch hidden by test data: the content defined 21 fields, the sensor supplied 20, and tests used a wildcard on the field that differed. The same pattern appears in fintech when a processor adds a field to a webhook or settlement file and the test fixtures never populate it. The second is a single update reaching every host at once. The FCA's advice covers both: "Firms should ensure adequate testing of updates before deployment and consider phasing releases across user groups to support containment of any failures."

A firm cannot test its vendor's code, but it can test its own exposure. The FCA observed that "Firms that had conducted detailed mapping of third and nth party relationships were able to quickly understand exposure and take mitigating actions to manage the impact." For EU financial entities, DORA Article 28 puts ICT third-party risk inside ICT risk management, and Commission Delegated Regulation (EU) 2024/1774 Article 25(2) names failure of an ICT third-party service provider as a continuity test scenario. Our DORA testing requirements page maps those articles to tests and evidence.

What to test after the CrowdStrike outage

These three tests are our practice; no regulation prescribes them.

1. A canary ring for vendor updates. The RCA states that after the incident "Customers can choose where and when Rapid Response Content updates are deployed." Endpoint agents, operating system patches, and payment terminal firmware all ship updates that a firm can often schedule. We run each update on a canary ring of hosts that carry real payment workloads in a test environment, then run a payment smoke suite before promotion.

The last row is the Channel File 291 lesson in fintech form: a wildcard or null in a test fixture proves nothing about the field it hides.

2. Offline and degraded mode. A card terminal or SoftPOS app that depends on a back-office Windows host or gateway needs a tested path when that host fails. We cut the connection mid-sale, keep the store-and-forward queue through a reboot, and replay it. Each queued sale must post once, so the replay test uses the checks in our payment idempotency testing guide. A queue that holds cardholder data must stay encrypted while offline. The scheme time limits for offline sales are on our POS and merchant services testing page.

3. Recovery time per business service. Microsoft's figure of 8.5 million devices tells a firm nothing about its own recovery time; only a test does. We start the clock when the host fails and stop it at the first successful authorisation or transfer after recovery, not at host boot. The result is compared with the recovery objective the firm set for that service and with the impact tolerance the FCA asks UK firms to review. The operational resilience testing service delivers "Failover and recovery time results" and "Third-party provider outage simulations" for this test.