What CrowdStrike, Travelex and Synapse tell us about blast radius in financial services.
CrowdStrike cost banking $1.149bn with no attacker involved. What Travelex and Synapse add, and why DORA now requires concentration risk assessment.
Parametrix put the direct cost of the July 2024 CrowdStrike outage to US Fortune 500 companies (excluding Microsoft) at $5.4 billion. Banking took $1.149 billion of it. Around three quarters of Fortune 500 banking firms recorded a quantifiable loss, and the weighted average across everyone affected came to $44 million.
Insurance only covered ten to twenty percent.
I keep coming back to the fact that institutions absorbed roughly four and a half billion dollars of an exposure nobody had sized, and the trigger was a content update from a vendor they were paying to make them safer. No attacker anywhere in it.
I spent a lot of years in third-party risk meetings at banks, and the assessment reliably stopped at the vendor. Is this supplier financially sound, do they hold SOC 2, what does the contract say about liability?
All reasonable questions, but nobody asked what the vendor's software was made of, because the framework had no box for it. Judging by the number of DORA sub-outsourcing templates that came back blank in the first collection, I do not think that has changed much.
Why the interval matters more than the trigger
The attack against Travelex is the smallest of the three examples. It was executed by the Sodinokibi ransomware on New Year's Eve 2019, most likely through an unpatched Pulse Secure flaw, CVE-2019-11510, after a researcher had flagged it the previous September. Seventeen days of customer-facing systems down in a business where availability is the product. Finablr projected a £25 million hit in Q1 2020 from the attack and the pandemic together, PwC were appointed administrators by August, and over 1,300 jobs went in the restructuring.
I am not going to pin the whole collapse on the attack, because the pandemic was doing its own damage that year. But seventeen days is seventeen days.
Synapse is the one I would actually spend time on, and it gets less attention than it deserves because nothing was hacked. Synapse Financial Technologies sat in the middle of the fintech stack, between applications and FDIC-insured banks. It held pooled customer funds in For Benefit Of accounts and maintained the sub-ledgers that recorded which individual customer owned what inside those pools. That is a mundane-sounding function. It is also the only place the mapping existed.
When Synapse failed in April 2024, more than 100,000 people lost access to roughly $265 million. Partner banks could not retrieve accurate balance records. The shortfall against customer claims came in somewhere between $65 and $95 million, and months later people were still waiting.
No breach, no ransomware, no CVE. The reconciliation between Synapse's ledgers and the banks' records broke down, and neither the banks nor the applications held direct access to the granular sub-account data. Every party in the chain was holding a partial picture and none of them could complete it from their own systems.
Something in the middle stopped working and the question of who was affected turned out to be unanswerable by anyone still standing.
Travelex spent weeks reconstructing. The CrowdStrike firms spent days. Synapse's customers waited months.
What DORA and NYDFS now require on concentration risk
DORA is the clearest of the current requirements. Financial entities have to assess concentration risk at least annually across four dimensions: internal concentration where multiple critical functions ride one provider, systemic concentration where the same providers serve competing institutions, geographic concentration, and interdependencies where the providers themselves depend on common underlying suppliers.
That last one is the interesting dimension and the hardest to actually do.
In November 2025 the European Supervisory Authorities designated 19 Critical Third-Party Providers across cloud, core banking, post-trade and enterprise software. If you use them, those contracts now face direct Lead Overseer review and your exit strategy has to be executable if a competent authority tells you to terminate.
NYDFS gets to a similar place through Part 500.13(a), which wants a recovery time objective (RTO) recorded per asset. An RTO is a promise about how fast you can restore something, and it is only worth the paper if you know what the asset contains.
Can you answer the blast radius question within the hour?
If a critical vulnerability drops tonight, can you say which systems are affected, which counterparties or customers are exposed, and what the fix path is?
Most teams cannot, and I do not think it is mainly a tooling gap. Scanners inspect the finished artifact and read its manifest, resolving the first couple of layers of the dependency tree and inferring the rest. J.P. Morgan's Eye on the Market put 95% of open source vulnerabilities in transitive dependencies, 683 per JavaScript project against 10 direct. So the tooling covers the shallow end while the exposure sits underneath it.
There is also the case CrowdStrike represents, which is not a vulnerability question at all. SolarWinds was signed and audited and trusted, and the artifact was the attack. The XZ backdoor shipped in the release tarball and never appeared in the git repository. Comparing the artifact against the source that produced it would have surfaced both, and that comparison is not part of most pipelines.
Kusari builds the dependency graph from source and build systems rather than reading it back from finished artifacts, which is what makes the blast radius answerable in seconds. Reachability then ranks what is actually live. At one health insurer with 6,000 employees that took 90% of findings off the queue.
Concentration risk has been an annual exercise on most calendars for years, and DORA has turned it from a memo into a filing.
For the bank and insurer security leaders reading this: when you did the last one, did you assess at the vendor level, or did you get underneath the vendors to the artifacts and components? And if you got underneath, what did you use to do it, because I have not found a good answer to that question that does not involve building something.
Quick answers
What does PCI DSS requirement 6.3.2 require?
PCI DSS 4.0 requirement 6.3.2 requires an inventory of bespoke and custom software, and of the third-party software components incorporated into that software. It became mandatory on 31 March 2025. The requirement covers transitive dependencies, meaning components that arrived as dependencies of other dependencies rather than ones a developer selected directly.
What is the DORA Register of Information?
The DORA Register of Information is a set of nine linked data templates that EU financial entities must maintain and submit annually to their national competent authority under Article 28. It covers every contractual arrangement with an ICT third-party provider, including the ICT assets associated with each service and the sub-outsourcing chains behind material sub-contractors. The first submission was due in Q1 2026, and the register must also be delivered on request at any time.
What does NYDFS Part 500.13 require?
NYDFS Part 500.13(a), effective 1 November 2025, requires covered entities to maintain written policies for creating and updating an asset inventory. Each asset must record its owner, location, classification, support expiration date and recovery time objective. The first certification covering this requirement was due 15 April 2026.
Why do most software inventories fail regulatory review?
Most inventories are produced by scanners, which inspect the finished artifact and read its manifest. Scanners typically resolve about two layers of a dependency tree and take the manifest's word for the rest, so deeper components are absent from the report rather than flagged as unknown. J.P. Morgan research found 96% of vulnerabilities sit at least two layers below the dependency a developer actually changed, which is the region these regulations ask about.
Do these regulations require an SBOM?
None of the three names SBOM as a required format. All three require the information an SBOM contains: a component inventory covering third-party and transitive dependencies, with provenance. SPDX and CycloneDX are the standard formats for producing that information in a machine-readable and independently verifiable way.