Arkéa’s Reported Theft: Test Third-Party Transaction Authority

Sources checked: 10 November 2026. FailSafe Research.

A provider identity may have permission to invoke an operation without having a legitimate business reason to move a particular amount of money. Transaction-authority testing asks how that identity, the institution's own accounts and the final transfer controls interact. It belongs alongside application and API testing.

What has been reported about Arkéa

In November 5 reporting quoting the bank and AFP, Crédit Mutuel Arkéa described a service-provider pathway and fraudulent transfers involving a bank-owned account. The report places the loss in the order of €100 million and distinguishes bank funds from customer accounts. The provider and full technical route were not identified. Exact recovery and loss figures should not be treated as settled from this account. This is a reported incident, not a FailSafe investigation.

Map the authority before the entry point

Start with the institutional action that must remain bounded. Inventory provider identities, service accounts and approved APIs. Determine which identity reaches the ledger-facing operation, which account it can affect and where the amount, beneficiary and velocity limits are enforced. A diagram should make each policy owner visible, including any control outside the application being tested.

FailSafe's application, API and identity assessments examine authorized paths to a defined consequence. A transaction-authority engagement adapts that method to customer-owned financial workflows. The test environment uses synthetic balances, agreed identities and approved destinations. It needs a business owner who can specify the legitimate operation and the unacceptable state transition.

Test a sequence rather than one permission

A fictional integration may be allowed to create a beneficiary and request a transfer. The assessment should ask whether the same authority can combine those actions in a way the institution did not intend. Compare an allowed transaction with a deliberately out-of-policy synthetic case. Record the actual enforcement decision rather than inferring it from a documented limit.

Include the approval boundary: which details were approved, whether subsequent changes require a new decision, and whether an alternative route applies the same check. If a control depends on transaction ordering or prior history, document that state. Calling each operation valid in isolation does not establish that their composition is authorized.

Measure intervention and recovery

With explicit permission, simulate suspension and credential revocation. Determine whether queued work still executes and whether recovery can repeat a transfer. Collect timestamps for the request, alert, authority change and observed rejection. Stop before effects reach real settlement rails unless those effects are specifically approved under the engagement's safety plan.

The closure record should connect each correction to a repeated case and an allowed control. Where a provider refuses access or telemetry is unavailable, identify the limitation instead of assigning a pass. The finance assurance worksheet helps teams separate delegated authority, economic limits and revocation evidence. Review FailSafe's testing workflow to define the scope before selecting an engagement.