Threat intel
Crédit Mutuel Arkéa heist went through a service provider
Attackers used a vendor's platform to drain an estimated €100M to €118M from Crédit Mutuel Arkéa's own account. What is known and which controls to check.
On November 4, Crédit Mutuel Arkéa, the Brittany-based cooperative group behind Fortuneo with 5.8 million customers, confirmed a cyberattack that let criminals carry out fraudulent transactions. The attackers reached an internal account of the bank through the platform of an outside service provider, sent money to other financial institutions, and the funds appear to have been turned into dollar stablecoins on crypto exchanges.
Customers are not the ones who lost money: the bank says no client assets were touched and the loss stays with the group, although some transfers were suspended or ran late while it added controls. The story matters to anyone whose treasury or payment accounts can be driven by a vendor's system, which describes most mid-sized companies. If that vendor is compromised, your own account sends the money.
How the attack worked, as far as anyone knows
The bank has said three things about the entry point. The attackers "went through a provider's platform" and from there reached Arkéa directly. They used an account belonging to the bank itself, not customer accounts, to transact with other banks. And the cause was not internal human error: the bank calls it "a sophisticated attack from outside." It also says no entry was made through Fortuneo, contradicting early press reports that the operations started there.
The provider has not been named, and neither has the kind of service it runs. That leaves the exact mechanism open. What the bank's statements describe is a familiar pattern: a third-party platform holds a trusted connection to the bank's payment systems, the attacker gets control of that platform or its credentials, and payment orders from it are accepted as legitimate because the channel itself is trusted. Reporting in Le Figaro and MoneyVox, citing journalist Grégory Raymond, says the money went to accounts opened under false identities before it was converted to crypto. The bank has not confirmed this.
On the crypto side, blockchain analytics firm Bitquery traced 108.8 million USDC (a stablecoin pegged to the US dollar issued by Circle) withdrawn from accounts at Kraken, Crypto.com and OKX over about 21 hours on November 1 and 2. Some of it was swapped to ether within hours and later moved through Monero, a privacy coin that breaks the public transaction trail. Some funds were also withdrawn as USDT, Tether's stablecoin.
What we know about the money, and where sources disagree
The amount is not settled, and the sources disagree:
- Blockchain investigator ZachXBT flagged the theft on November 2 and, after adding about $27 million in further withdrawals on November 3, put the total at more than $133 million, about €118 million. ZachXBT says the figure could rise once over-the-counter trades are counted.
- Le Télégramme reported the €118 million figure. The bank said it could "only validate the order of magnitude" and would not confirm the exact number.
- The bank told Reuters its losses were lower than the reported $133 million. AFP reports quote the group at around €100 million and say part of it has been recovered.
- Bitquery's $108.8 million covers only the USDC it traced. It is not a measure of the bank's final loss.
Recovery has been patchy. Tether froze about $1.14 million of USDT, while Circle had not frozen any of the identified USDC by the time of IT-Connect's report. The Paris prosecutor's cybercrime section opened an investigation on the evening of November 4 for organised intrusion into an automated data processing system, assigned to the national anti-cybercrime office (Office anticybercriminalité). The bank says the amounts do not threaten its financial stability.
What to do if a vendor can move your money
The Arkéa case involved a bank, but the same exposure exists wherever a payment hub, treasury management system, payroll bureau or EBICS or SWIFT service provider can submit payments from your accounts. The goal is that a fully compromised provider still cannot move a large sum without one of your own people noticing or approving it.
Find out what each provider can actually do. For every outside system, record which accounts it reaches and whether it only sends payment files or can also authorise them. Ask the bank for the mandate and channel configuration in writing. The setup usually drifts from what the contract says.
Put the limits where the vendor cannot change them. A cap configured inside the vendor's own application is gone when that application is compromised. Ask your bank for per-transaction and daily limits on the provider's channel, a beneficiary allowlist, and a holding period on any beneficiary added since the last review.
Separate sending from approving. On EBICS (the file transfer protocol used for corporate payments in France, Germany, Austria and Switzerland), signature classes do this for you. Give the provider transport signature class T, which lets it submit files that the bank will not execute. Require release by two of your own staff with class A and class B signatures, or two class A signatures, each on a separate device. On other channels, enforce the same maker and checker rule: the vendor never holds both roles, and no approval happens inside the vendor's interface alone.
Watch the provider's sessions as closely as your own admins. Grant vendor access through a privileged access management tool, just in time, with session recording. Alert on logins outside the vendor's normal hours or source IP ranges, on first payments to a new beneficiary IBAN, on bursts of payments to several institutions in a short window, and on amounts just under a limit. Make sure each payment record keeps the submitting channel, user ID, source IP, beneficiary IBAN and BIC, amount and approver IDs, so you can reconstruct a session afterwards.
Rehearse the stop. Arkéa suspended transactions to halt the fraud; you need to be able to do the same in minutes. Agree with your bank who can suspend a provider's channel and how. Know the SEPA recall process (the camt.056 recall message) and your bank's fraud contact, and for crypto-bound fraud keep the law enforcement request routes for exchanges and stablecoin issuers to hand. In this case the stablecoins left exchanges within about 21 hours, and only a small share was frozen.
For EU financial entities, the Digital Operational Resilience Act (DORA) already requires a register of information on ICT third-party arrangements. Use it as the starting list, and add a column for payment rights.
Checking whether you are already exposed
Pull 90 days of outbound payments by channel and compare the provider-submitted ones against what the provider should be sending: which beneficiaries, which amounts, at what times. Any beneficiary that only appears on the vendor channel, or any change to approval rules made by a vendor account, needs an explanation. Ask each provider when it last rotated the credentials and certificates it uses to reach your bank, and whether it would tell you about a compromise of its own platform within hours.
If you want an outside view of how far a compromised vendor could get into your payment flow, our security operations team can monitor those sessions, and our compliance and audit readiness work helps you document vendor access before an auditor asks. Open the chat and Yaali, our AI agent, will pass your question to an engineer.
Sources: BleepingComputer, The Next Web, CSO Online, OCCRP, FrenchWeb, IT-Connect, Reuters via SRN News, La Presse (AFP).