Attackers Came In Through A Supplier. The Money Left The Bank's Own Account.

On Wednesday 4 November, Credit Mutuel Arkea confirmed that it had been the target of an attack which enabled the execution of fraudulent transactions. In a question and answer session that evening the bank said the attackers "went through the platform of one of our service providers", that they "used Credit Mutuel Arkea's own account", and that no customer account in its federations or subsidiaries was involved. The loss was first made public two days earlier, not by the bank, but by an independent blockchain investigator who had traced it on-chain. The provider has not been named and the method has not been disclosed. What has been confirmed is enough to put a question to any board with suppliers in its payment path, and it is not the question those suppliers are usually asked.

What happened

The sequence matters more than usual here, because the bank and the public record started from different ends of the same event.

Three days of reporting, sorted. The gap between the bank's account of the route and the on-chain trace is the part worth watching.

On Monday 2 November the blockchain investigator ZachXBT posted that an unidentified European Union entity was suspected of having lost more than 106 million dollars from accounts held at multiple cryptocurrency exchanges, with the funds taken the previous day, Sunday 1 November. He published eleven wallet addresses and traced the laundering route over the following 24 hours: USDC and USDT out, USDC exchanged for ether, movement through the instant exchange services WellWallet and Kyrrex, and some proceeds converted into Monero via Wagyu. Two days later he raised the estimate to more than 133 million dollars, around 118 million euros. On attribution he said he could state "with a high degree of confidence it is NOT Lazarus Group based on multiple laundering indicators". No entity had been named at that point and no loss independently confirmed.

On Wednesday 4 November the bank suspended certain transactions as a precaution, so transfers could not be made from its applications, and Credit Mutuel Arkea confirmed that it had been the target of an attack that enabled the execution of fraudulent transactions and that the incident was under control. ZachXBT named the bank the same day. Its statement said: "We wish to reassure all of our customers: this incident has had no impact on their assets." The attack "only caused a delay in the execution of certain transfers", and the sums involved were in no way of a nature to undermine its financial strength and soundness. The group reports 5.8 million members and customers and total assets of 211.5 billion euros.

The substantive disclosure came that evening. In a question and answer session at 17:30, the bank said the attackers "sont passes par la plateforme d'un de nos prestataires", they went through the platform of one of its service providers, and that "les attaquants ont utilise le compte propre de Credit Mutuel Arkea pour realiser des transactions vers d'autres acteurs bancaires", they used Credit Mutuel Arkea's own account to carry out transactions towards other banking institutions. No customer account in the federations or the subsidiaries was used. Asked whether internal error was a factor, it answered: "Non. Il s'agit d'une attaque sophistiquee venant de l'exterieur." It stated that no entry was made through Fortuneo, its online bank. On the amount, it could "simply validate the order of magnitude" and it was too early for a final figure; AFP reported its provisional estimate as on the order of 100 million euros, which is reporting of the bank's position rather than a figure it has confirmed. Part of the funds may have been blocked, in the conditional wording of the French reporting. Nearly all operations had restarted that morning, and the first statement of the day carried a preventive phishing warning, without stating that customer data was exposed. One note on language: the characterisation of this as a supply-chain attack is the reporting journalist's conclusion, not the bank's own term, and it is not attributed to the bank anywhere here.

• Sunday 1 November 2026The day on which the funds were lost, according to ZachXBT. He and forensic transaction data describe the attack as having unfolded over several days; no source states when it began.
• Monday 2 November 2026ZachXBT posts that an unidentified EU entity is suspected of losing more than 106 million dollars from accounts at multiple cryptocurrency exchanges. Eleven wallet addresses are published. No entity is named and the loss is not independently confirmed.
• Wednesday 4 November 2026, morningCertain transactions are suspended as a precaution, with the result that transfers cannot be made from the bank's applications.
• Wednesday 4 November 2026Credit Mutuel Arkea confirms the attack and says the incident is under control and customer assets unaffected. ZachXBT names it as the suspected victim and raises his estimate to more than 133 million dollars, around 118 million euros. Le Telegramme reports the same figure.
• Wednesday 4 November 2026, 17:30In a question and answer session the bank states that the attackers went through the platform of one of its service providers, that they used the group's own account, that they did so to carry out transactions towards other banking institutions, that no customer account was used, that internal error is ruled out, and that no entry was made through Fortuneo. It validates only the order of magnitude of the reported loss and says nearly all operations restarted that morning.
• Wednesday 4 to Thursday 5 November 2026The cybercrime section of the Paris public prosecutor's office opens an investigation into an attack on an automated data-processing system committed by an organised group, with the Office anti-cybercriminalite tasked with the inquiry. Le Telegramme reports that the bank informed the Banque de France, which houses the ACPR; the Banque de France declined to comment to AFP.
• Thursday 5 November 2026The bank is reported to be still counting its losses. No provider has been named, no method disclosed and no attribution made.

Two things are worth holding onto before anyone builds a lesson on this. The first is how far the two accounts of the loss actually meet. The bank names the first leg: its own account, used to make transactions towards other banking institutions. The investigator describes losses from accounts at cryptocurrency exchanges. The step between them, that those receiving institutions then allowed conversion into cryptocurrency on specialised platforms, appears in the French reporting in the conditional and as the journalist's inference rather than as a bank statement. Which institutions received the transfers, and how they map onto the exchange accounts traced on-chain, has not been published. The second is that the provider has not been named and the method has not been disclosed, so how access to a supplier platform became the authority to initiate transfers out of a bank's own account remains the central unanswered question of the incident.

Why this one is different

Third-party risk registers are built to answer a confidentiality question. This incident asked a different one.

Supply-chain compromise is not new, and a bank confirming one would not normally justify a board's attention beyond a note in the risk report. What makes this one worth twenty minutes is the direction of the loss.

Third-party risk management, as most organisations practise it, is built around a confidentiality question. The assessment asks what data the supplier holds, where it is processed, how it is encrypted, which sub-processors are involved and what happens to the data on exit. That shape is not an accident. It is the sediment of fifteen years of data protection enforcement, in which the loss event that attracted a fine, a headline and a regulator's letter was disclosure. The questionnaire learned to detect the thing that kept hurting.

What Credit Mutuel Arkea has confirmed is a different loss event. No customer account was used. No theft of customer data has been reported. What left the institution was cash, out of the group's own account, through a route that began at a supplier's platform. On GCS's reading, that is the distinction a board should take from this: a supplier platform that sits anywhere in the payment or treasury path does not merely hold data about the organisation, it holds transactional reach into it. The two exposures are different in kind, they fail differently, and they are almost always assessed by the same document.

Run the test on your own estate. You can probably name, within minutes, which suppliers hold personal data and what your lawful basis is for each. Can anyone name, with the same speed, every supplier platform technically capable of initiating, authorising or releasing a payment? In most organisations that second list has never been written down as its own artefact, because no questionnaire has a field for it. It sits distributed across treasury, procurement, finance systems and whatever integrations were built when the platform was onboarded, often years ago, by people who have since moved on.

There is a second distinguishing feature, and it is uncomfortable for any regulated institution. The loss became public on 2 November through on-chain analysis by a private researcher. The bank confirmed on 4 November. ZachXBT has gone further and alleged that delays by the bank in alerting regulators and exchange compliance teams allowed upwards of 30 million dollars to be laundered that could otherwise have been frozen. That is his allegation. It is not a regulatory finding, the bank has not responded to it, and no supervisor has made any finding on the timeliness of its reporting. We record it because it is in the public record, not because it is established.

Either way the sequence is instructive. Stolen funds that move through public blockchains are traceable by anyone with the skill to follow them, so the window in which an institution controls the narrative of its own loss is now set by a third party's analysis rather than by its own disclosure calendar. A crisis communications plan that assumes the first outsider to ask about a loss will be a journalist, rather than someone who has already traced it, is out of date.

Note too what this was not. Not ransomware, so no encryption event and no ransom decision. Not a data breach, so the data protection playbook, the one most organisations have actually rehearsed, would have been the wrong one to open. Incident response muscle memory built around those two scenarios leaves a team improvising.

Commercial exposure for UK and European organisations

Four faces, in the order a board is likely to meet them.

Regulatory. For any EU financial entity, the governing instrument is the Digital Operational Resilience Act, Regulation (EU) 2022/2554, and the relevant clause is worth quoting rather than paraphrasing. Article 28(3) requires financial entities to "maintain and update at entity level, and at sub-consolidated and consolidated levels, a register of information in relation to all contractual arrangements on the use of ICT services provided by ICT third-party service providers", and requires that those arrangements be documented "distinguishing between those that cover ICT services supporting critical or important functions and those that do not". The classification question is the one this incident puts pressure on. A platform through which payments can be initiated is difficult to argue out of the critical or important category, yet the register entry for it was often drafted when the relationship was understood as a data-processing one. For reporting, Article 19(1) requires financial entities to "report major ICT-related incidents to the relevant competent authority", and Article 19(4) sets out an initial notification, an intermediate report, and a final report due "when the root cause analysis has been completed". The time limits sit in Commission Delegated Regulation (EU) 2025/301. Article 5(1)(a) requires the initial report "as early as possible, but in any case, within four hours from the classification of the ICT-related incident as a major ICT-related incident and no later than 24 hours from the moment the financial entity has become aware of the ICT-related incident". Article 5(1)(b) sets the intermediate report "at the latest within 72 hours from the submission of the initial notification, even where the status or the handling of the incident have not changed", and Article 5(1)(c) the final report "no later than one month" after the intermediate or latest updated intermediate report. One detail is routinely missed and is directly relevant here: Article 5(4) allows a deadline that falls on a weekend or a bank holiday to be met "by noon of the next working day", but Article 5(5) states that this "shall not apply for the submission of an initial notification or an intermediate report by credit institutions, central counterparties, operators of trading venues, and other financial entities identified as essential or important entities pursuant to Article 3 of Directive (EU) 2022/2555". Note the scope: the extension is removed for the initial notification and the intermediate report, and remains available for the final report. These funds were lost on a Sunday. For a credit institution, the clock on the first two does not pause for the weekend.

Regulatory, for UK readers. DORA does not apply to a UK-only firm, and it is worth being precise about what does. The UK's critical third parties regime, in the FCA's words, "came in on 1 January 2025", with the Treasury designating critical third parties; the first four designations were made on 13 July 2026, all of them entities in the Amazon, Google, Microsoft and Oracle groups. The point for this story is the limit of that regime rather than its reach. A mid-tier payments, treasury or reconciliation platform of the kind implicated in an attack on a bank's supplier would not be a designated critical third party, and the FCA is explicit that the regime is intended to "Complement, not replace" existing obligations, with firms remaining "responsible for managing their own third-party risks". The supplier that can move your money is, in regulatory terms, entirely your problem.

Financial. The loss here sat with the institution, not its customers, which is a clean illustration of where this category of risk lands on a balance sheet. Where the route in is a supplier platform, recovery turns on contractual liability caps, the supplier's own insurance, and whether your cyber policy responds to funds transfer fraud arising from a third party's compromise rather than your own. Three clauses, three documents, usually three different owners, and the time to find out how they interact is not during an incident. We put no figure on the recoverable proportion, because no source supports one and the Arkea position is unresolved.

Governance. The exposure here is an ownership gap rather than a control gap. A payments or treasury platform is typically selected by finance, integrated by IT, assessed by a third-party risk function using a template built for data processors, and never revisited at board level because it has never caused an incident. Each of those four parties can reasonably believe another holds the risk. The question that closes the gap takes one meeting: who signed off that this supplier's platform can move our money, and when was that decision last reviewed?

What leaders should do now

Six decisions available this week. None of them waits on the provider being named.

None of what follows depends on the provider being named, the method being disclosed or anyone being attributed. All of it is available this week.

1. List what can move money. Produce, as its own artefact, every supplier platform capable of initiating, authorising or releasing a payment, separately from the list of suppliers that hold data. If that list does not already exist, that absence is the finding, and it is one the board should see in those terms rather than as a housekeeping action.
2. Establish what the access actually is. For each platform on that list: standing access or time-boxed, named credentials or shared, which API scopes, which accounts it can reach, what transaction limits apply, and who reviews the log. Arkea has not said how provider access became the authority to transfer. That is precisely the gap worth closing in your own estate while the answer is still unknown in theirs.
3. Split the register in two. Record transactional reach as a distinct exposure from data access, with a different owner and a different assurance question. Asking a payments platform about encryption at rest while never asking what it can authorise is the shape of the problem.
4. Check the DORA classification, in writing, per contract. For EU entities, confirm which side of the Article 28(3) line each contract in the payment path sits on, and whether the register entry reflects the platform's transactional capability or only its data role. For UK entities, do the equivalent exercise against your own operational resilience documentation, on the understanding that the critical third parties regime will not cover this supplier for you.
5. Rehearse the first four hours. For an EU credit institution the initial notification is due within four hours of classifying the incident as major, and no later than 24 hours from awareness, with no weekend extension available for it or for the intermediate report. Rehearse the classification decision itself, not just the escalation: the four-hour clock starts when someone decides the incident is major, and that decision is usually the slowest part.
6. Decide now who speaks first. Name the individual authorised to confirm or deny a loss that a researcher or an analyst publishes before you do, and agree what they may say on day one. This loss was public two days before the institution confirmed it, and that gap is now a standing feature of any loss touching a public ledger.

Three questions for the board

• Question oneWhich of our suppliers' platforms can move our money, as distinct from seeing our data, and who signed that off? If no single person can answer within the meeting, that is the answer.
• Question twoIf an outside party published a loss of ours tomorrow, how long would it take us to confirm or deny it, and who is authorised to do so?
• Question threeFor each ICT supplier in our payment path, does our register record the contract as supporting a critical or important function, and does that classification reflect what the platform can actually do rather than what it was bought to do?

Strategic takeaway

The useful thing about this incident is not its size. It is that the loss arrived through a door the third-party risk process was not built to watch. Supplier assessment matured in an era when the worst outcome of a vendor compromise was disclosure, and it became very good at detecting that. The platforms since wired into payment, treasury and reconciliation functions carry a different exposure, and they are being assessed with the older instrument.

Closing that gap is not a technology programme. It is a list that does not currently exist, an access review that nobody owns, and a classification decision that was made implicitly and never tested. All three are achievable inside a quarter, and none requires knowing who attacked a French bank, or how.

Confidence note

Confirmed by Credit Mutuel Arkea in its statements of 4 November 2026: that it was the target of an attack enabling the execution of fraudulent transactions and that the incident is under control; that the attackers went through the platform of one of its service providers; that the attackers used the group's own account to carry out transactions towards other banking institutions and that no customer account in the federations or subsidiaries was used; that internal error is ruled out and the attack came from outside; that no entry was made through Fortuneo; that customer assets were not affected and the incident only delayed certain transfers; that nearly all operations restarted on the morning of 4 November; and that it can validate only the order of magnitude of the reported loss, with a final figure still to come. The term supply-chain attack is the reporting journalist's and is not attributed to the bank in this briefing.

Reported but not confirmed by the bank: the figure of 118 million euros or 133 million dollars, which comes from Le Telegramme and from ZachXBT's on-chain analysis, against the bank's own provisional estimate of around 100 million euros as reported by AFP; the laundering route and the exchanges involved, and the exchange accounts from which ZachXBT traced the loss; that part of the funds may have been blocked, which the French reporting puts in the conditional rather than as a flat confirmation; that the receiving institutions then allowed conversion into cryptocurrency on specialised platforms, which is the journalist's inference in the conditional and not a bank statement; ZachXBT's allegation that delays by the bank in alerting regulators and exchange compliance teams allowed upwards of 30 million dollars to be laundered, which is his alone and to which the bank has not responded; and the notification of the Banque de France, reported by Le Telegramme, on which the Banque de France declined to comment to AFP. ZachXBT's assessment that the actor is not Lazarus Group is his own, stated with high confidence and not corroborated by any authority.

Update, 6 November 2026. After this briefing was drafted, the bank itself put the loss at around 100 million euros on Thursday 5 November, which moves that figure from AFP's reporting of the bank's position to a statement of the bank's own. A spokesperson declined to identify the third-party service provider whose platform was used, said the funds taken were not cryptocurrency although they could have been converted afterwards, and repeated that neither Fortuneo nor its customers' accounts were involved. The bank is reported to have informed the European Central Bank and the French banking supervisors, and the Paris prosecutor's cybercrime unit opened its investigation following a complaint from the bank. The provider, the method and the entry point remain undisclosed, and no recovery of funds has been reported.

Not established by any source at the time of writing: the identity of the service provider; the technical method; how access to a supplier platform became the authority to initiate transfers from the bank's own account; which institutions received the transfers from the bank's own account, and how they map onto the exchange accounts ZachXBT traced; and any attribution. No claim of responsibility has been made, and no arrest has been reported. The opening of a criminal investigation by the cybercrime section of the Paris public prosecutor's office is reported, and the qualification of the offence under French law is an allegation at this stage rather than a finding.

The regulatory clauses in this briefing are quoted from Regulation (EU) 2022/2554, Commission Delegated Regulation (EU) 2025/301 and the FCA's published position, rather than paraphrased from memory. Readers in the UK should note that DORA does not apply to them directly and should check their own position with counsel. This briefing does not assert that Credit Mutuel Arkea failed any reporting obligation. An allegation of delay has been made by a private researcher and is recorded above as such; no supervisor has made any finding, and the DORA material here is offered as the framework a reader's own organisation sits inside, not as a verdict on this bank's conduct. The central argument about registers, the confidence grading, the six actions and the three board questions are GCS's own analysis.

Garzon Cyber Solutions delivers cybersecurity advisory, compliance certification and specialist technology recruitment as one integrated capability for organisations in the UK, EU and beyond.