What DORA asks firms to check after the Crédit Mutuel Arkéa theft through a supplier

The money taken from Crédit Mutuel Arkéa did not come out of customer accounts. It came out of an account belonging to the bank itself. In its Q&A of 4 November, the French group said the attackers reached it through the platform of one of its service providers and used that position to send transfers to other banks. The next day, the bank put the loss at around €100 million, Reuters reported; until then it had only validated "the order of magnitude" of the €118 million ($133 million) figure in the press.

That one fact moves the spotlight. Fraud controls at a bank, and at any company with a sizeable treasury, are built mostly around customer channels: odd sign-ins, new payees, unusual amounts. Payments the organisation makes in its own name, through channels a supplier runs or connects, start from a presumption of trust. DORA, the EU's Digital Operational Resilience Act, does not let that trust go unexamined.

What follows sets out what is known about the case, what DORA requires when the way in is a third party, and which controls a regulated firm can test now, without waiting for Arkéa's forensic report.

What do we know, and not know, about the Arkéa attack?

Crédit Mutuel Arkéa is a cooperative banking group based in Brittany, with more than 5.8 million customers and €211.5 billion in assets, according to Help Net Security. Its published Q&A says the attackers used one of the group's own accounts to wire money to other banks, where it may then have been converted into cryptoassets. Accounts held by customers of its federations and subsidiaries were not involved, and the bank maintains that customer balances are untouched.

Arkéa calls it a sophisticated attack from outside and rules out internal human error. Its systems spotted the suspicious activity quickly, crisis procedures kicked in, and some transactions were paused as a precaution, which delayed customer transfers. Reuters reports that the bank informed the European Central Bank, French banking supervisors and prosecutors. The Paris prosecutor's cybercrime unit opened an investigation after receiving the complaint; the ACPR, France's banking supervisor, declined to comment.

The first public warning did not come from the bank. Blockchain investigator ZachXBT posted an alert about an unnamed European institution on his Telegram channel and later named Arkéa. His tracing, as reported by Help Net Security, shows more than $106 million withdrawn from several exchange accounts on 1 November, and on 3 November he reported a further $27 million. The funds left the exchanges as USDC and USDT stablecoins, were then swapped into ether, and part ended up in Monero. ZachXBT says the laundering pattern does not match Lazarus. The bank has not confirmed these figures in detail.

Plenty remains unknown. Arkéa has not named the provider or said what service it supplies, and it has denied French press reports pointing to a different entry point, as The Record notes. How access to the provider's platform was obtained, and for how long it stayed open, is also unclear. The analysis below does not guess at either; it works from what the bank has confirmed.

What does DORA require when the way in is a supplier?

DORA (Regulation (EU) 2022/2554) has applied since 17 January 2025 to banks, insurers, investment firms, payment institutions and other financial entities. Its third-party chapter rests on a plain principle: outsourcing a service does not outsource accountability. Article 28(1) states that a financial entity remains fully responsible for meeting all its obligations even when it relies on ICT services from others.

Article 30 turns that principle into contract terms. Every agreement with an ICT provider must oblige the provider to help the firm at no extra cost, or at a cost agreed in advance, when an incident related to the service occurs, and to cooperate fully with the competent authorities. Where the service supports a critical or important function, the contract must also set notice periods and reporting duties running from provider to firm, along with rights of access, inspection and audit.

The second strand is reporting. An incident counts as major when it affects critical services and either involves malicious unauthorised access that may lead to data loss, or crosses two or more of the thresholds in Delegated Regulation (EU) 2024/1772. One of those is economic impact, met when costs and losses exceed, or are likely to exceed, €100,000.

Once an incident is classified as major, Delegated Regulation (EU) 2025/301 allows four hours from classification for the initial notification, and never more than 24 hours from when the firm became aware of the incident. The intermediate report follows within 72 hours of that notification, and the final report within a month of the latest intermediate one.

Whether Arkéa has classified this as a major incident under DORA, or what it has filed, is not public. The structure is enough to see the obligations. If the provider the attacker came through supplies an ICT service within the meaning of Article 3(21), it sits inside the perimeter the firm must govern. Incident reporting does not depend on that question, and its outer deadline runs from when the firm becomes aware of the incident, not from when it understands the entry point.

Doesn't fraud monitoring already cover these payments?

Only in part, although inside many firms the argument sounds sensible. Fraud tooling scores transfers, the provider holds certifications and passes audits, and the contract has a security clause. Seen that way, DORA's third-party chapter looks like paperwork, mostly about the register of information and cloud agreements.

Part of the argument holds. No bank can audit every supplier in depth, and most certifications demand effective controls. Customer fraud detection has also improved a great deal, pushed along by PSD2 strong customer authentication and by the steady pressure of business email compromise scams.

Scope is where it breaks down. Those systems were designed to catch an outsider pretending to be a customer. When a payment instruction originates inside the firm, through a channel the bank treats as its own, most of the warning signs are missing: the sender is legitimate, the route is familiar, and the payee names look consistent.

Why does the Arkéa case undercut that confidence?

Because the money moved faster than the response, and because the loss falls on the firm even when the supplier fails. The best-known precedent is ten years old. In 2016, instructions sent from Bangladesh Bank's own systems moved $81 million out of its account at the Federal Reserve Bank of New York, a case Reuters revisits in its Arkéa coverage. That money went to casinos in the Philippines and took weeks to move. In Arkéa's case, according to published on-chain analyses, the funds became stablecoins and then other cryptoassets within hours.

Speed shrinks the window for recovery. The bank says part of the money has been frozen, but what can be recovered depends on what happens in the first hours outside the bank: the receiving banks, the exchanges, and the stablecoin issuers that are able to freeze balances. As of 5 November, according to Cryptoast, Tether had frozen $1.14 million in USDT and Circle had not blocked any of the identified USDC.

ZachXBT argues that more than $30 million was laundered before the incident became public and that European law enforcement could have frozen it with earlier notice. That is his hypothesis, not an established fact, yet it exposes a gap that few response plans address.

The third piece of evidence is legal, and it has already come up: Article 28(1). If the provider fails and money leaves the firm's account, the loss and the reporting duty belong to the firm. A supplier's certifications help with selection; they do not replace the firm's own controls over what that supplier can do on its behalf.

We have covered other links in this chain before, from suppliers holding troubleshooting copies of client data to a provider's application credential reused against customers' Microsoft 365 tenants. Arkéa adds a different kind of supplier: one that can move money.

Which controls and evidence should firms check?

None of the measures below depends on knowing exactly how Arkéa was breached. All of them begin with a single question: which third parties can originate, alter or transmit payment instructions from the firm's own accounts?

How can firms identify the providers able to move money?

With an inventory ranked by that ability. The DORA register of information lists ICT providers and the functions they support, but it often lacks a column for what each provider can do with the firm's own payments. Bank connectivity platforms, financial messaging bureaux, ERP systems wired to banking channels, reconciliation services with write access. Any provider able to issue or change an instruction supports the payments function, which a credit institution will usually classify as critical or important; in that case its contract must carry the terms of Article 30(3), even if the deal was signed as ordinary software.

Where should payment limits sit?

At a point the provider cannot reach, because if the provider is compromised, every control that depends on it is compromised too. Daily cumulative caps per payee, holds on first payments to new beneficiaries and dual approval above a threshold need to sit outside its reach. Near-real-time reconciliation between what the provider reports as sent and what the account shows is the second line: it shortens the gap between the first rogue instruction and its detection.

How should provider sessions be monitored?

With the same scrutiny as an internal administrator's: origin, timing, volume and type of operation for every connection into the firm's systems. User and entity behaviour analytics applied to those technical accounts can flag out-of-pattern payment batches, sign-ins from new locations or edits to payee tables. If the provider generates that telemetry, the contract has to secure access to it and its retention.

Which contract clauses need testing against an incident?

Three, and they are best read against a simulated incident: how quickly the provider must report an incident affecting the service, the Article 30(2) assistance at no cost or at a pre-agreed cost, and access to logs and forensic evidence. A contract that relies on the provider's "best endeavours" will not survive the first call at three in the morning.

Does the response plan cover the first hours outside the firm?

An incident response plan usually covers isolating systems and notifying the supervisor, but not the first hours outside the firm. For payment fraud it also needs recall requests to receiving banks, contacts at exchanges and stablecoin issuers, and an early police complaint with transaction data ready to hand. Rehearsing that sequence in a tabletop exercise is cheap; improvising it can cost part of what could still have been frozen.

What does inaction cost?

Arkéa's own figure gives the scale: around €100 million, at a group that says the loss does not threaten its solvency. For a mid-sized bank or a payment institution, a sum of that order would be existential.

DORA adds board accountability. Article 5(2) gives the management body ultimate responsibility for managing the firm's ICT risk, including approving and reviewing the third-party policy. When a supervisor asks why a provider able to move money was not treated as supporting a critical or important function, "the contract was categorised that way years ago" will not be a defensible answer.

Then there is reputation. Arkéa had to confirm the attack after an outside investigator made it public, and to deny reports about the entry point while still managing the crisis. Deciding in advance what gets said, by whom and when is part of the same work, as we discussed in our piece on handling an external compromise notification.

How should the board frame the decision?

As a governance choice, not a tool purchase: it decides whether providers that can move the firm's money are governed as supporting a critical or important function, with limits, telemetry and contracts to match, or remain filed as office software that happens to hold privileged access. At Hard2bit we address this within DORA compliance and third-party risk management engagements, and rehearse it with our incident response team. In late October, the Binance theft showed what happens when the system that signs withdrawals fails. Arkéa shows what happens when whoever issues the payment is not who they appear to be.

Sources and attribution: this case draws on Crédit Mutuel Arkéa's public disclosures and on media reporting available on 10 November 2026. ZachXBT's figures are estimates by an outside investigator and have not been confirmed by the bank. Naming the bank does not imply a security flaw in any particular product or service, and the provider involved has not been identified. Attributions and figures may change as the judicial investigation progresses.

Disclaimer: this article analyses obligations under DORA and its delegated regulations in the light of a public case, for information purposes only. It is not legal advice: incident classification and the designation of critical or important functions depend on each firm and its supervisor.