ION’s outage exposed a vendor no board had on its critical list
The ransomware attack on ION’s cleared derivatives software showed that sector-wide disruption often starts at specialized post-trade vendors that many firms share and few rank as critical. Finding them, grading them and rehearsing life without them are three separate jobs.
Looking Back revisits one week at a time, from January 2020 to today, and asks what it meant for the banks, health systems and public agencies we serve. The series was written in 2026, with the benefit of hindsight, and each article says which week it looks back on.
The week
ION Group said its ION Cleared Derivatives business had suffered a cybersecurity event, beginning on January 31, 2023, that affected some of its services. The unit supplies software that many futures brokers and clearing firms use to process exchange-traded derivatives. The LockBit ransomware group claimed responsibility. Affected firms, including clearing units of large banks, lost access to tools for confirming and reconciling trades and fell back on manual processing. The Futures Industry Association said the incident disrupted some members’ trade processing and reporting. On February 3 the Commodity Futures Trading Commission said it would hold its weekly Commitments of Traders report because some firms could not submit accurate data. Publication stayed suspended through February, and the CFTC began releasing the missed reports in sequence in March. Exchange trading itself continued throughout.
Concentration risk in financial services is usually discussed in terms of cloud providers and a few dominant platforms. ION Cleared Derivatives was neither. It was a specialized post-trade system that many firms happened to run, each after assessing the vendor on its own. When it stopped, the disruption spread across all of them at once and reached the regulator’s own data. The work this exposes splits into three jobs that most third-party programs handle unevenly: identifying shared dependencies, judging how critical they are, and preparing a fallback that works under pressure.
Identifying shared dependencies
Third-party programs assess vendors one relationship at a time. A firm reviews the contract, scores the risk and sets a review cycle. What no single firm can see from its own inventory is how many peers rely on the same vendor for the same function. That property, not the vendor’s security posture, is what turns a vendor incident into a market event.
Shared dependencies cluster in specialized functions. Post-trade processing, collateral and margin management, payment messaging, regulatory reporting, market data, and core processing for community banks and credit unions are the usual places. The vendors there are often mid-sized firms with deep domain expertise and a handful of products. Their names rarely appear in board papers.
Finding them takes a few deliberate steps. Tag each vendor in the inventory by business function as well as spend category. Ask specialized vendors directly how many clients use them for that function and in which markets. Use industry bodies, clearinghouses and exchanges, which often know which back-office platforms dominate a segment. Finally, look one level down: a vendor that is not dominant itself may run on a hosting provider or component that is.
Judging criticality
Most programs grade criticality by spend, data sensitivity or customer visibility. A post-trade platform can score modestly on all three. It holds little consumer data, clients never see it, and it may cost far less than an enterprise suite. Yet if it stops, the firm cannot confirm trades, calculate margin or report positions, and each day of backlog compounds the next.
A better test is time to harm. How long can the function run without the service before an obligation to a client, a counterparty, a clearinghouse or a regulator is breached? For trade confirmation and margin, the answer may be hours. For many higher-profile services, such as collaboration tools, it is days. Ranking vendors by time to harm, and then by how many peers share them, moves specialized operational systems toward the top.
This ranking changes what the board sees. A typical third-party report lists the top vendors by spend and by data held. A useful one adds a short list of low-spend, short-time-to-harm, widely shared vendors, with the fallback status of each. It also changes contracts. Firms can ask such vendors for recovery time commitments, notice obligations measured in hours, and evidence of tested restoration from clean backups, not only a SOC 2 report.
Preparing a fallback that works
Affected firms fell back on manual processing. That kept the market functioning, but it was slow, error-prone and dependent on staff who still knew how to do by hand what the system normally did. Manual fallback is a real control only if it is designed and rehearsed.
Designing it starts with outputs. Decide which outputs are essential on day one: trade confirmations, positions, margin calls and regulatory reports. Then decide how each will be produced without the system. Options include exchange and clearinghouse files, validated spreadsheet templates, or a secondary tool held on standby. Each option needs access rights, data feeds and named staff set up in advance, because none can be arranged in the first hour of an outage.
Rehearsing it means running the procedure on a schedule and measuring throughput. How many trades per hour can the team process manually, and at what point does the backlog exceed what can be cleared before the next settlement cycle? Those numbers tell management when to escalate, when to ask clearinghouses or regulators for relief, and when to limit new business.
Reconciliation deserves its own plan. When the vendor’s system returns, its records must be matched against everything done manually in the meantime. Data quality after recovery was the drag on the CFTC’s reports, which stayed delayed for weeks while firms submitted corrected positions. Firms should also decide in advance what evidence they need before reconnecting to a vendor that has been compromised. That decision is easier to make calmly, before the vendor is pressing everyone to reconnect.
The same three jobs apply well beyond derivatives. A community bank whose core, card and digital banking come from a small set of providers faces a version of the ION problem. So does a wealth manager whose portfolio accounting runs on one specialist platform. The vendor may be well run. The exposure comes from many firms stopping at once, each needing to know what it will do on day one and on day five.
With hindsight
Later incidents confirmed the pattern. In November 2023 ransomware at ICBC’s US broker-dealer disrupted part of Treasury market settlement. In July 2024 a faulty CrowdStrike update crashed Windows systems worldwide, including at banks, with no attacker involved, showing that concentration risk does not need a cyberattack. Regulators moved toward direct oversight of shared providers. The UK’s critical third parties regime came into force on January 1, 2025, though obligations apply only once the Treasury designates a provider. Under the EU’s DORA, the European Supervisory Authorities in November 2025 designated 19 critical ICT third-party providers, a list that included financial-sector technology firms as well as cloud hyperscalers. None of these regimes removes a firm’s own duty. The firms that coped best with later outages were the ones with rehearsed manual procedures and a clear reconnection test.