ION’s outage exposed a vendor no board had on its critical list

The week

On January 31, 2023, a company most executives outside the futures business had never heard of became, briefly, one of the most important names in finance. ION Group said its ION Cleared Derivatives business had suffered a cybersecurity event that affected some of its services.

ION Group is a privately held financial technology group that grew largely by buying established trading, analytics and post-trade software businesses. ION Cleared Derivatives sat within its ION Markets division. The company’s short statement said the incident was contained to one environment and that all affected servers had been disconnected. Remediation was under way, and it gave no timetable.

ION Cleared Derivatives makes software that many futures brokers and clearing firms use to process exchange-traded derivatives: standardized contracts, such as futures on oil, grain or interest rates, that are bought and sold on an exchange. After each trade, a lot of unseen work has to happen: confirming who bought what, at what price, and making sure everyone’s records agree. That behind-the-scenes work is called post-trade processing, and ION’s software did much of it for many firms.

The LockBit ransomware group claimed responsibility. Ransomware is malicious software that scrambles a victim’s computer files so they cannot be used, after which the criminals demand payment for the key to unscramble them. On its leak site, LockBit threatened to publish data stolen from ION on February 4 unless a ransom was paid. ION did not say how the attackers got in or what data was taken.

The effect rippled out quickly. Affected firms, including clearing units of large banks, lost access to tools for confirming and reconciling trades, which means checking that their records match their counterparties’ records line by line. They fell back on manual processing: people, spreadsheets and phone calls doing what the software normally did in seconds. Bloomberg reported that at least 42 of ION’s clients were affected, and that ION told clients its systems would not be fully working until February 6. A US Treasury official said publicly that the incident was confined to a small number of smaller and mid-sized firms and did not pose a systemic risk to the financial sector. The Futures Industry Association, the industry’s trade body, said the incident was affecting the trading and clearing of exchange-traded derivatives by ION’s customers.

The exchanges and clearinghouses themselves were not reported to have been hit. The disruption sat with the brokers and clearing firms between them and their clients, and it fell in a busy week for interest-rate markets: the Federal Reserve announced a rate decision on February 1.

Then the problem reached the regulator. On February 2, staff of the Commodity Futures Trading Commission, which oversees US derivatives markets, said the weekly Commitments of Traders report would be delayed because some firms could not submit timely, accurate data. That report is a widely watched snapshot of who holds which positions in the futures markets. Publication resumed on February 24 with the report originally due February 3, and the CFTC expected to clear the backlog of missed reports by mid-March.

The staff statement of February 2 came jointly from four CFTC divisions: Clearing and Risk, Market Participants, Data, and Market Oversight. It described ION Cleared Derivatives as a third-party provider of order management, execution, trading and trade processing for cleared derivatives. It said the incident was affecting some clearing members’ ability to give the CFTC timely and accurate data.

The statement also addressed the daily large trader reports that clearing members, futures commission merchants and foreign brokers file under Part 17 of the CFTC’s rules. Firms affected by the incident might not have enough information to complete them. Staff told those firms to file using best estimates, to work with Commission staff to stay as timely as possible, and to file revised reports once their systems were working again.

The weekly Commitments of Traders report is built from that large trader data. It normally appears on Friday afternoons and shows positions as of the preceding Tuesday, broken down by type of trader. With some firms’ inputs missing or estimated, the totals could not be relied on. Rather than publish figures it knew to be incomplete, the CFTC postponed the report altogether.

Exchange trading itself continued throughout. Buyers and sellers could still trade. What broke was the plumbing behind the trading floor, and it broke at many firms at once because they all depended on the same supplier.

Take a board meeting at a mid-sized bank in early 2023. The third-party risk report on the table lists the usual suspects: the big cloud provider, the core banking platform, the payroll firm, the companies that hold the most customer data and cost the most money. It is a sensible list. It probably did not include the name of a post-trade software unit that most directors had never heard of.

That gap is the story of the ION incident. 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. First, what actually went wrong.

The second life of a trade

Every trade has two lives. The first is the moment of the deal, when a buyer and a seller agree on a price. That part is visible and fast. The second life is everything that follows: recording the trade, confirming it with the other side, working out how much collateral each party must post, updating positions and reporting to regulators. This second life is post-trade processing. It is the accounting department of the markets, and like most accounting departments, nobody thinks about it until it stops.

Clearing is a key part of that second life. When two firms trade a futures contract, a clearinghouse steps into the middle, becoming the buyer to every seller and the seller to every buyer. That way, if one firm fails, the other is still protected. To make this work, the clearinghouse collects margin, which is a deposit of cash or securities that acts like a security deposit on an apartment. Margin is recalculated every day, sometimes more often, as prices move. Brokers and clearing firms sit between their clients and the clearinghouse, and they need software to track all of this.

ION Cleared Derivatives supplied that software to many of those firms. When ransomware locked it up, firms could still see that trades were happening, but they could not easily confirm them, reconcile them or report them. Reconciliation, in this context, means comparing two sets of records, yours and your counterparty’s, and making sure every line matches. Without software, that becomes a job for people with spreadsheets, and the volume in a busy futures market quickly outpaces what people can do by hand.

The steps that stopped

The work that broke is easy to underrate because it is so routine. Many futures trades are executed by one broker and then given up to another firm that clears them, so the two firms must agree on who now holds the position. Large orders placed for several clients are often executed as a block and allocated to individual accounts afterward. Each client must receive a confirmation, and each position must be matched to the clearinghouse’s own record before margin can be calculated.

When the software that drives those steps stops, trades keep arriving from the exchange. Allocations queue up. Give-ups go unclaimed. Client positions in the firm’s books drift away from the clearinghouse’s record. Every hour adds new items to match, and the old ones do not go away. A manual team can keep up for a while on a slow day, but it falls behind fast when volumes rise.

Why one firm’s outage became the regulator’s problem

The chain that reached the CFTC shows how far a back-office failure travels. Clearing firms report large traders’ positions to the Commission every day. The Commission aggregates those reports and publishes the weekly Commitments of Traders report from them. When some firms could file only estimates, the aggregate was compromised for everyone. One vendor’s outage at a subset of firms degraded a public dataset used by the entire market.

That chain has a general shape. Many regulatory reports are aggregates built from inputs filed by dozens or hundreds of firms. If a common vendor stands behind a meaningful share of those inputs, its failure degrades the aggregate even for firms that never used it. Supervisors increasingly care about this kind of dependency for exactly that reason. A firm’s reporting obligations are part of the public infrastructure, and they belong in its continuity planning.

Ransomware is worth one more word of explanation, because it shapes the recovery. Criminals get into a network, often through a stolen password or an unpatched weakness, spread unnoticed, then encrypt files so they cannot be read. Many groups also copy data out first and threaten to publish it. The victim must then decide whether it can restore from clean backups, and customers must decide when it is safe to reconnect to a system that was just compromised. Neither decision is quick.

For a vendor serving many firms, recovery has stages. It must find how the attackers got in, close that route, rebuild affected servers from clean images and restore client data. Then each client must decide whether to reconnect, test its own interfaces and reload whatever it processed by hand in the meantime. ION’s own target for full service was several days after the attack. The CFTC’s data took weeks to catch up, because the last stage, cleaning the records, belongs to every client separately.

An executive who will never open a margin report still feels the consequences, because they land in familiar places. Clients wait for confirmations and statements. Counterparties start asking questions. Staff work long nights on manual workarounds, and tired people make mistakes that cost money. Regulators want to know why reports are late. The trading floor never has to stop for the damage to be real.

Job one: finding the vendors everyone shares

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, more than the vendor’s security posture, is what turns a vendor incident into a market event.

If one restaurant’s refrigerator breaks, that restaurant has a bad night. If the only ice supplier in town has a fire, every restaurant has a bad night at the same time, and none of them can borrow ice from the place next door. The ice supplier may be small, well run and cheap. Its importance comes from how many people depend on it at once.

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 by function as well as by spend. Most vendor inventories are organized around purchasing categories such as “software” or “professional services.” Add a second label for the business function each vendor supports, such as trade confirmation, margin, or regulatory reporting. Suddenly a small line item can be seen sitting under a critical process.
• Ask the vendor about its footprint. Ask specialized vendors directly how many clients use them for that function and in which markets. A vendor that says “most of the market” is telling you something important.
• Use the industry’s view. Industry bodies, clearinghouses and exchanges often know which back-office platforms dominate a segment. They see the whole field in a way no individual firm can.
• Look one level down. A vendor that is not dominant itself may run on a hosting provider or component that is. Your supplier’s supplier can be your single point of failure.

The fourth-party question is easier to ask in a contract than in a crisis. Firms can require critical vendors to disclose the subcontractors and hosting providers that support the service, and to give notice before changing them. That list will not be complete. It is still more than most firms had in early 2023, and it shows where two apparently separate vendors share a common dependency.

The case for concentration

Shared vendors exist for good reasons. A specialist that serves much of a market can spread the cost of security, resilience and regulatory change across many clients. It can afford engineering talent that no mid-sized broker could hire alone. Standard platforms also make the market work more smoothly, because firms exchange data in the same formats. A firm that builds its own post-trade system to avoid concentration may end up less secure and less reliable than the vendor it avoided.

That case is strong, and it argues for planning around concentration rather than avoiding it. The firm keeps the efficiency of the shared platform. In return it pays for the knowledge of where it is concentrated, a fallback that works and contract terms that reflect the vendor’s importance. Treasury officials were right that ION did not pose a systemic risk. For the firms that could not confirm trades for days, the risk was still real.

Suppose a regional bank has a modest futures clearing business. Its vendor inventory lists more than a thousand suppliers. Sorted by spend, its post-trade software sits far down the list. Sorted by function, it is the only system that produces daily margin figures and position reports. And a call to its clearinghouse contact reveals that many of its peers use the same product. That twenty-minute exercise moves the vendor from invisible to near the top of the risk register.

What the rules already expect, by type of firm

Regulators had not ignored vendor risk, but their expectations differ by charter and registration, and firms should check the specifics with counsel.

• Banks. In June 2023 the Federal Reserve, FDIC and OCC issued joint guidance on third-party risk management. It asks banks to apply more rigorous oversight to relationships that support critical activities, a test based on consequences rather than spend. Separately, the agencies’ computer-security incident notification rule requires banks to notify their primary regulator within 36 hours of certain significant incidents. It also requires bank service providers to notify their bank customers as soon as possible when an incident disrupts covered services for four hours or more.
• Credit unions. NCUA’s cyber incident notification rule took effect in September 2023 and requires federally insured credit unions to report reportable incidents within 72 hours, including certain incidents at third parties. NCUA has long lacked the authority to examine credit union vendors directly, which leaves more of the diligence burden on each credit union.
• Broker-dealers. FINRA’s Regulatory Notice 21-29 reminded member firms in 2021 that outsourcing a function does not outsource the supervisory obligation for it. The notice set out practices for vendor due diligence, monitoring and contingency planning.
• Futures commission merchants. FCMs that are members of the National Futures Association must maintain written information systems security programs under NFA’s interpretive notice on the subject, and CFTC rules already require them to keep risk management programs. The ION incident tested how far those programs reached into vendors.

Each regime asks the firm to understand its critical third parties. None of them, at the time, asked any firm to know which of its vendors were also critical to its competitors. That knowledge sat with the vendor, the clearinghouses and, in fragments, with the regulators.

Concentration that no single firm can see

US bank regulators have long examined some large technology service providers directly. They do so through an interagency program run under the FFIEC umbrella, using the authority of the Bank Service Company Act. That program gives supervisors a partial view of shared dependencies. It does not reach most specialist vendors serving futures brokers, broker-dealers or asset managers, and its findings are not shared with the firms that use the vendor in the form of a concentration map.

A firm can partly fill the gap through its trade association, which can survey members on shared platforms without exposing any one firm’s contracts. Clearinghouses can do the same for their clearing members. The output does not need to be precise. Knowing that a function is served by three main vendors, and roughly which one the firm’s peers favor, is enough to change how the firm plans.

Job two: judging how critical a vendor really is

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.

Time to harm in a futures business

For a futures commission merchant, the clocks are short and largely set by rule. FCMs must send clients written confirmation of each trade, generally by the next business day. They must compute every day whether client funds held in segregated accounts cover what they owe clients, and file that computation with their regulators. Clearinghouses call for margin at least daily and can call intraday when prices move sharply. Large trader reports are due every business day.

Set against those clocks, a post-trade system has a time to harm measured in hours. A collaboration suite that goes down for a day is disruptive but rarely causes a regulatory breach. A firm that runs this exercise honestly will find its vendor ranking reshuffled: the system that produces the segregation computation outranks systems that cost ten times as much.

Time to harm is a simple idea that executives already use elsewhere. A hospital knows that a broken elevator is a nuisance but a failed oxygen supply is an emergency measured in minutes. A retailer knows a website outage on a slow Tuesday matters less than one on the busiest shopping day of the year. Applying the same logic to vendors gives a ranking that reflects real consequences rather than invoice size.

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. Directors do not need to understand margin calculations to ask the right question about that list: “If this one stopped tomorrow, what would we do by lunchtime?”

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, beyond a SOC 2 report. A SOC 2 report is an independent auditor’s review of a service company’s controls. It is useful, but it describes how a vendor manages risk in normal times. It says much less about how quickly the vendor can rebuild after an attacker has locked its systems, and that is the question that matters for a critical, widely shared service.

The case against ranking by time to harm

The method has critics, and they make fair points. Every business owner believes its own system is critical, so a time-to-harm exercise can inflate the list until it means nothing. Estimates of how long a function can run on workarounds are guesses until they are tested. Vendors may resist recovery commitments they cannot price, or charge heavily for them.

Those objections argue for discipline in the method, and they leave the method itself standing. Keep the short list short, perhaps a dozen names, and require evidence for each time-to-harm estimate from a rehearsal or a past incident. Revisit it yearly. Where a vendor will not commit to recovery terms, record that as a known gap and put the money into the firm’s own fallback instead. A ranking by spend avoids these arguments only by measuring the wrong thing.

Job three: a fallback that works under pressure

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.

A realistic rehearsal is specific. Pick a recent high-volume day. Cut the team off from the post-trade system in a test environment. Have it rebuild positions, confirmations and margin figures for a sample of that day’s real trades, using only exchange and clearinghouse files and the prepared templates. Record trades processed per hour, the error rate and how long it takes to reconcile the results against the system’s own output. Two or three of those numbers, repeated each year, show whether the fallback is improving or decaying.

A rehearsal that only confirms staff know the procedure is reassuring. One that shows where the backlog starts to build is useful, because it turns a vague plan into numbers management can act on.

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. Restarting the machine does not end an outage; cleaning up the records is the long tail.

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. Typical evidence includes confirmation of how the attackers got in, that the route is closed, that restored systems were rebuilt from clean backups, and that independent investigators have reviewed the work.

Telling clients, counterparties and regulators

A fallback plan also needs a communications plan, because silence creates its own losses. Clients want to know whether their positions are safe and when statements will arrive. Clearinghouses and counterparties want to know which records to trust. Regulators want early notice, a description of what reports will be late and an estimate of when they will be corrected. Prepared templates for each audience, with named approvers, let a firm say something accurate within hours instead of drafting from scratch while the backlog grows.

What a fallback costs, and who pays

Fallbacks carry real costs, and the choice among them is a business decision. A warm standby system from a second vendor gives the fastest recovery but means paying for two licenses, keeping two sets of data feeds alive and testing both. Splitting the business across two vendors limits any one outage to part of the book, but doubles integration work and complicates reporting. A rehearsed manual fallback is cheapest in licenses and most expensive in people, and it degrades as volumes grow.

Firms can also plan to shrink. During a long outage, a clearing firm might decide to stop onboarding new clients, cap new positions for some accounts or ask clients to route new business elsewhere. Those are painful choices with commercial consequences. They are far easier to make, and to explain to clients, if the triggers are written down in advance and agreed with the business.

Reconnection is a market-wide decision

When a widely used vendor is compromised, every client asks for the same evidence at once. The vendor’s team, already stretched, fields hundreds of overlapping questionnaires. Each client’s security team reaches its own judgment on its own timetable, and some reconnect days before others. That pattern slows recovery for everyone and gives no client a better answer than a shared one would.

A coordinated approach works better. Industry groups, clearinghouses or a group of the largest clients can agree on a common evidence package with the vendor. It would hold the forensic summary, confirmation of the entry point and its closure, and an independent attestation that the rebuilt environment is clean. Each firm still makes its own decision, but on the same facts and without duplicating the work. Firms can agree to that kind of arrangement in principle, through their associations, before any vendor is hit.

The firms that could answer quickly

A firm that has done this well can answer a handful of questions quickly. It knows which of its vendors are widely shared across its sector. It can rank them by time to harm. For each of the top names, it has a written fallback, a named owner, and the results of the last rehearsal. Its contracts set out recovery commitments and notice periods. Its board has seen the short list at least once a year.

The weaker programs fail in recognizable ways. They treat the security questionnaire as the control, though a thick questionnaire tells you how a vendor describes itself and nothing about what your firm will do when that vendor is dark. They write “revert to manual processing” into a continuity document without templates, data feeds or trained people, which is a hope rather than a fallback. They rely on a few long-serving staff who remember how things worked before automation, so that when those people retire, the fallback retires with them. They forget the regulator, although when firms could not report, the CFTC’s own data was delayed; reporting obligations belong on the day-one list alongside client and counterparty obligations. And they map direct vendors but not the platforms those vendors run on, leaving the deepest shared dependencies hidden.

Who owns a shared vendor

In weaker programs, ownership of a vendor like ION is split. Procurement owns the contract. The third-party risk team owns the questionnaire. Operations owns the daily use. The CISO owns the security review. Business continuity owns a plan that nobody has rehearsed. Each part is managed, and nobody owns the whole.

Stronger programs name one accountable executive for each shared critical vendor, usually the head of the business function it supports. That person answers for the fallback, the rehearsal results and the contract terms, and draws on the specialists for each. When the vendor goes dark, the same person runs the response. The arrangement costs nothing to set up and removes the most common delay in an incident: working out who decides.

Numbers a board can follow

A short set of measures turns the topic into something a board can track over time:

• The number of vendors on the shared-critical list, and how many have a written and rehearsed fallback.
• For each, the date of the last rehearsal and the manual throughput achieved, as a share of a normal day’s volume.
• The estimated time to clear a three-day backlog once the vendor returns.
• How many of those contracts include recovery commitments, notice periods and disclosure of key subcontractors.

The numbers do not need to be perfect to be useful. Their direction from one quarter to the next tells a board whether the work is happening.

Beyond derivatives: who else faces this

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. A core banking system is the central ledger that records every deposit, loan and payment; if it stops, the bank effectively stops. So does a wealth manager whose portfolio accounting runs on one specialist platform.

The pattern travels outside finance too. Consider a hospital that relies on one specialist vendor for pharmacy dispensing, or a county government that uses the same tax-billing software as its neighbors. Each has the same structure: an unglamorous, essential service, shared by many, rarely discussed at board level.

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. When everyone loses the same tool at the same time, there is no peer to borrow from, the industry’s shared experts are stretched thin, and regulators are dealing with the whole sector at once.

Smaller firms face a different calculation. A small introducing broker, a credit union or a regional wealth manager usually cannot pay for a standby system or a second vendor. Its realistic options are narrower. It can rehearse a manual process for the few outputs that matter on day one. It can agree with its clearing firm or service bureau on what help is available in an outage. And it can set clear triggers for slowing down new business. Those choices cost little, but they have to be made before the outage, because none of them can be negotiated on the morning it starts.

Where to look first, by type of firm

• Community banks and credit unions should start with the core processor and the providers of card processing, digital banking and payment connectivity. Many share the same small set of providers with hundreds of peers, and some run their core through a credit union service organization owned jointly with other credit unions.
• Broker-dealers and wealth managers should look at clearing and custody arrangements, portfolio accounting, trade order management and the vendors that produce client statements and regulatory reports.
• Insurers and asset managers should look at policy administration platforms, fund accounting and investment data providers, where a few firms serve much of the market.
• Health systems and public agencies should look at claims clearinghouses, pharmacy and dispensing systems, permitting and tax systems, and the shared hosting behind them.

In each case the starting point is the same: find the unglamorous functions that would leave the organization unable to meet an obligation within a day if they stopped. The list usually includes at least one vendor that has never appeared in a board paper.

Testing whether the back office could run without a shared vendor

None of these requires technical knowledge to ask, and the quality of the answers will tell a board a great deal.

1. Which of our vendors are used by a large share of our peers for the same function, and how do we know?
2. For each critical function, how many hours can we run without its main system before we breach an obligation to a client, counterparty or regulator?
3. For our top shared vendors, what exactly would we do on day one and on day five without them, and who is named to do it?
4. When did we last rehearse that fallback, and how many transactions per hour did the team actually manage?
5. What evidence would we require before reconnecting to a vendor that had been hit by ransomware, and who decides?

The ION incident did not stop exchanges from trading. It showed something less dramatic and more useful: the most dangerous vendor in a firm’s portfolio may be one that costs little, holds little data and is shared by nearly everyone. Finding it, grading it and rehearsing life without it are three separate jobs, each best done before the next morning the back office goes dark.

With hindsight

Later incidents confirmed the pattern. In November 2023 ransomware at ICBC’s US broker-dealer disrupted part of Treasury market settlement. Treasuries are the bonds the US government issues to borrow money, and their market underpins much of the financial system, so trouble in its settlement plumbing drew immediate attention. Again, the problem sat in the back office rather than on the trading screen.

LockBit claimed that attack too. Press reports described trades being settled through manual workarounds while the firm’s systems were down. The pattern was the same as at ION: a market that kept trading while one participant’s back office struggled to keep up.

The group itself did not last in its old form. In February 2024 an operation led by the UK’s National Crime Agency took over LockBit’s administration platform and leak site. For firms that depended on ION, that mattered less than it seemed. Their exposure had always been to the vendor, whichever gang came next.

In July 2024 a faulty CrowdStrike update crashed Windows systems worldwide, including at banks, with no attacker involved. CrowdStrike makes security software that runs deep inside computers. Microsoft estimated that about 8.5 million Windows devices were affected. A single bad update, pushed to many customers at once, showed that concentration risk does not need a cyberattack. A shared supplier making an honest mistake can have the same effect as a criminal gang.

The pattern reached other industries too. In June 2024 a ransomware attack on CDK Global, a software provider to car dealerships, disrupted sales and service operations at thousands of dealers across North America. The structure matched ION’s: a specialist back-office platform, invisible to customers, shared by much of an industry.

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 Digital Operational Resilience Act, known as DORA, the European Supervisory Authorities designated 19 critical ICT third-party providers in November 2025. The list included financial-sector technology firms as well as cloud hyperscalers, the handful of giant companies that rent out computing capacity. That mix matters: regulators were looking past the obvious cloud names toward specialist suppliers, much like the one at the center of the ION story.

DORA itself had applied from January 17, 2025. Among other things, it requires EU financial entities to keep a register of their ICT third-party arrangements and report it to supervisors. That gives regulators the cross-firm view of shared dependencies that no single firm had in 2023.

US regulators moved by other routes, alongside the banking agencies’ June 2023 guidance described above. In December 2023 the CFTC proposed an operational resilience framework for futures commission merchants, swap dealers and major swap participants that included a third-party relationship program. In May 2024 the SEC amended Regulation S-P. Broker-dealers, investment advisers and other covered institutions must now oversee their service providers, which must notify the firm within 72 hours of a breach affecting customer information. Larger firms had to comply by December 2025 and smaller ones by June 2026.

By 2026 the United States had not followed the EU and UK in creating a regime to designate and oversee critical third parties across finance. Its approach stayed centered on each firm’s own oversight duties, plus the bank regulators’ existing examinations of large service providers. For a US futures broker or broker-dealer, the work described above therefore remained the firm’s own job.

These regimes do not remove a firm’s own duty. A regulator overseeing a vendor does not run your fallback for you, reconcile your records or explain a missed obligation to your clients. The practical defenses remain rehearsed manual procedures and a clear test for reconnecting to a vendor after an incident.

The years since ION suggest that “third-party risk” is really two lists. One list holds the vendors that matter because of what they cost or the data they hold. The other holds the vendors that matter because everyone uses them and nobody can work without them for long. The second list is shorter, cheaper and easier to overlook, and it is the one most likely to turn a single firm’s bad day into a whole sector’s bad week.