On the night of 1 November, a French banking group with 5.8 million members and €211.5 billion in assets quietly started bleeding money. Not from customer accounts. From its own.
Crédit Mutuel Arkéa confirmed on 4 November that it had been the victim of a cyberattack that let an outsider use the bank's own account to fire off transfers to other financial institutions, then convert the proceeds into stablecoins. The bank has not confirmed the figure. Blockchain investigator ZachXBT, who flagged the withdrawals before the bank said anything publicly, put it at up to €118 million — roughly $133 million — pulled out as USDC and USDT.
Read that again: a bank heist where no customer's balance moved, no vault was opened, and no card was cloned. The attacker didn't rob the bank's customers. It borrowed the bank's identity for a few hours and let the banking system do the rest.
That is the shape of modern financial crime, and it should change how every team in the region thinks about payment access.
What actually happened
The timeline matters more than the total.
- 1 November — fraudulent withdrawals begin from centralised exchange accounts, later traced back to transactions initiated on Arkéa's side.
- 2 November — ZachXBT publishes a warning about a large unauthorised withdrawal, without naming the institution.
- 3 November — roughly $30 million has already been laundered, per the investigator. No public disclosure yet, so no coordinated freeze.
- 4 November — the bank discloses the incident, says it is "closed and under control", and reassures clients that their assets are unaffected.
- 7 November — the bank's FAQ confirms the attacker reached its network directly through a service provider's platform, and rules out its Fortuneo subsidiary.
Customer balances were untouched. Some transfers were delayed. The bank says it is working with police and judicial authorities to establish the exact origin and method.
So the damage was not a data breach in the usual sense. It was a liquidity event executed at machine speed with legitimate banking rails.
The account they used was the bank's own
Most security budgets in banking are organised around protecting customers. That is where the regulation points, where the audits land, and where the press coverage goes.
But a bank's corporate and treasury accounts are not a side detail. They are the accounts that can move nine figures in an afternoon without a human signing anything by hand. They hold standing instructions, correspondent relationships, and API credentials that other institutions trust by default. When an attacker gets a session inside that account, the fraud controls see a familiar counterparty doing a familiar thing.
Customers are expensive to rob one at a time. The institution's own account is the high-value target, and it usually has weaker behavioural monitoring than the retail side, because "the bank knows what it is doing".
The door was a service provider
The entry point, according to the bank's own FAQ, was a service provider's platform. That is the sentence every CISO in the Gulf should read twice.
Third-party platforms are not a footnote in the supply chain any more. They are the operations layer: treasury tooling, payment orchestration, custody dashboards, KYC vendors, cloud hosting, and increasingly AI copilots that sit inside the same session with the same permissions as the finance team. Each one is a doorway. Each doorway is only as good as the identity behind it.
The uncomfortable question is not whether your vendor is secure. It is whether you can prove, for any given transaction, which human or which service account actually initiated it, from which device, through which third-party hop, with what approval. If the answer requires an email chain and a week of log archaeology, you do not have a control. You have a hope.
Speed decided the loss
Between the first withdrawal and the public disclosure there were about three days. Thirty million dollars moved in that window, according to the investigator, and the argument made at the time was blunt: silence gave the attacker time to launder.
Disclosure speed is now a loss-mitigation control. Regulators in the EU are already moving that way, and the UAE's own incident-reporting expectations are tightening alongside the rest of the compliance stack. A bank that waits for a perfect narrative before picking up the phone is choosing a bigger loss.
The same logic applies inside your own organisation. An incident runbook that requires a committee before anyone can freeze a payment channel is not a runbook. It is a delay with a cover page.
Five controls worth building this quarter
You do not need a €211 billion balance sheet to be exposed to this pattern. Any company that can send money through an API has the same weakness, just with fewer zeros.
- Treat outbound treasury accounts as crown jewels. Separate them from the rest of corporate IT. Give them their own identity provider policy, their own monitoring, and their own on-call rotation.
- Attest every third-party session. Log which vendor platform, which service account, and which human approval produced each payment instruction. If a vendor cannot supply that per-request, they cannot be in the payment path.
- Set velocity limits that a person cannot approve away. A payment that lands in a new jurisdiction, converts to crypto, or exceeds a rolling limit should pause automatically rather than wait for a manager's click.
- Practise the freeze. Once a quarter, time how long it takes to suspend a payment channel end to end. If it is longer than an hour, the attacker wins by default.
- Pre-write the disclosure. Have the statement, the regulator notification, and the customer note drafted before you need them, so the first sixty minutes go to containment rather than committee.
What this means for teams in the Gulf
Arkéa is French, but the mechanism is portable. GCC banks, exchanges, fintechs, and family offices run on the same rails: correspondent relationships, stablecoin settlement, vendor-hosted treasury dashboards, and a growing layer of AI agents touching payment workflows.
The lesson is not "harden the perimeter". The lesson is that the perimeter is now a set of permissions held by third parties, and the crown jewel is the institution's own ability to move money. Audit that. Instrument that. Put a hard stop on it that does not need a deploy to trigger.
Because the next heist will not look like a break-in. It will look like a normal Tuesday, run from a legitimate account, through a trusted partner, and finished before the first meeting about it starts.
The bottom line: if you cannot name, per transaction, who authorised it and through which third party, then you are one compromised vendor session away from being the case study.