On November 4, 2026, Crédit Mutuel Arkéa confirmed a cyberattack that enabled fraudulent transactions. The attackers used the bank's own account to send funds to other institutions. Those funds were then reportedly converted into cryptocurrency.
Blockchain investigator ZachXBT puts the amount diverted at $133 million, around €118 million. Arkéa confirms the order of magnitude without confirming the figure. Part of the funds has been frozen, and customers' assets are not affected.
The attackers acted from the bank's own account
In a second statement, the group describes the path taken. Contrary to early press reports, the attackers did not get in through Fortuneo, its online bank. They went through an external service provider's platform, then reached Arkéa directly. No customer account was used for the transactions.
The bank rules out human error and describes a sophisticated attack from outside. Its systems detected the suspicious activity, and some transactions were suspended as a precaution. Almost all deferred transfers resumed during the morning.
The rest is not public. More than a week after the events, the provider's name, the access exploited and the controls bypassed remain unknown. Pointing to a specific flaw would therefore be premature. Yet the confirmed entry point is enough to raise a question that goes well beyond banks.
An intrusion is measured by what it lets someone do
At Bureau Vallée, customer data was copied from a service provider (we covered it in customer data was also held by the service provider). At Arkéa, the access was used to execute transfers. The same kind of entry point, two incidents of a different nature: in the first, the intruder takes; in the second, the intruder acts.
Two controls share this ground. Authentication verifies who is connecting. Authorization sets what that identity is allowed to do. The first never replaces the second, and it is often the second that is set too broadly.
The reason is mundane. A technical account with broad rights makes initial development easier: tests pass, the connection works, the application goes into production. The day that account is compromised, the attacker has nothing to break. They simply use the capabilities already granted.
We detailed this gap between granted rights and useful rights in your AI automations work, but what can they reach.
An authorized operation can still be abnormal
Reducing rights is not always enough. Take an application that updates supplier records. It usually makes a few dozen changes a day. One morning, it attempts several thousand, including payment details.
The connection is authenticated. The permissions technically allow these operations. The behavior, however, is anything but normal, and only a control independent of access rights can catch it: a volume cap, an alert on an unusual change, a second approval for certain operations.
In a bank, these controls take very specific forms. In an SME, they can stay simple:
- a business application creates a new supplier, but asks for a separate confirmation before changing its bank details;
- a B2B platform automatically accepts routine orders and holds those above a threshold;
- a gateway synchronizes stock levels without being allowed to touch prices.
None of this requires approving every operation by hand, which would quickly become unmanageable. The aim is to single out the few operations whose consequences justify an extra layer of protection.
Good architecture does not only aim to prevent intrusion. It also limits what an intrusion makes possible.
A provider's security and the security of its connection are two separate questions
The natural reflex is to choose recognized, certified providers with their own cybersecurity teams. These are good criteria. They answer only one of the two questions.
The first: does the provider properly protect its own infrastructure? The second: what would its access to your system allow if it were compromised? A certification, a maintenance contract or an availability commitment shed light on the first. They do not set the technical limits of a connection.
That second question is yours to answer, whatever the provider's size. A provider should not be able to do more than its assignment requires. That limit is set in the system, not only in the contract.
Cutting off an access is prepared before the incident
The day an access is compromised, three questions arrive at once. Can you cut off the provider's access without stopping your whole business? Can you trace the operations it carried out? Do your logs let you tell legitimate transactions from the rest?
These answers are prepared in advance. Improvised during the attack, they add hours of uncertainty, then days of checks. Meanwhile, losses have to be assessed and the customers concerned informed. Depending on the case, you may also have to report to your bank, your insurer or the authorities.
Three questions about your most critical integration
There is no need to start with an audit of your entire information system. Pick one integration that matters to your business: ERP, e-commerce, CRM, accounting software or automation platform. Once its rights are listed, ask these three questions with your technical lead or your provider.
1. Which operations would have serious consequences?
Changing a payment beneficiary, deleting orders or exporting the customer file does not carry the same weight as checking a delivery status. Those actions deserve a limit or an independent approval.
2. How would we spot abnormal use?
Are operations logged? Would anyone be alerted to an unusual volume of changes, or to a connection from an unexpected environment?
3. Can we cut this access off right away?
Who can revoke it, and which services would stop? How long would it take to get back to a controlled state?
The answers often lead to modest adjustments: a narrower permission, two separate technical accounts, an alert, a written revocation procedure. If a compromise happens, these are what make the difference.
Trust needs verifiable limits
The investigation will show, if it gets that far, how the provider's access led to the transfers. The bank says its systems made it possible to contain the attack. One lesson, at any rate, does not depend on those findings.
A company's information system is no longer a set of software side by side. It is a network of permissions, dependencies and automated decisions, and every partner holds one of its threads. Next time you connect a tool to a business application, don't just ask whether it works.
Also ask what it could do if someone else took its place.
Author · B.Coquisart - Project manager