Fraudulent Transfers: Use of Codes and Token Does Not Prove Consent (Cass. com., 1 July 2026, No. 25-13.134)

French Supreme Court (Cour de cassation), Commercial Chamber, 1 July 2026, appeal No. 25-13.134, published in the Bulletin

What happened in this case?

The facts are depressingly commonplace for anyone familiar with transfer fraud litigation. Lincotek Tarbes, a simplified joint-stock company (société par actions simplifiée), holds an account with Crédit lyonnais. On 23 November 2020, three transfers were executed from that account. The company maintains that they were fraudulent: it never consented to these transactions and states that its personalised security data was used without its knowledge.

Like thousands of businesses that fall victim to diverted transfers every year, it asked its bank to return the funds. When the bank refused, it brought proceedings.

The course of the proceedings illustrates the difficulty of this type of litigation. The Commercial Court of Créteil (tribunal de commerce), then the Paris Court of Appeal (Pôle 5, ch. 6), in a judgment of 22 January 2025, dismissed its claims. The Court of Appeal’s reasoning deserves to be set out precisely, because it is the very reasoning that has been quashed.

To hold that the payment transactions had been authorised, the Court of Appeal found that the computer records produced by the bank established the use of the user ID and the access code to the online area, as well as the use of a “token” generated by a device assigned to a user within the company. It inferred, on the one hand, that the transaction had been authenticated, duly recorded and accounted for, and, on the other, that it had not been affected by a technical deficiency. And it added that the company’s consent was “presumed accordingly to have been given in accordance with the form agreed between the parties”.

In other words: since the codes and the device worked, you must have consented. It is precisely this shortcut that the French Supreme Court condemns.

What does the law say about consent to a payment transaction?

The law on payment services, derived from the European PSD2 Directive transposed into the Monetary and Financial Code, rests on a simple architecture that protects the payer. Three provisions are at the heart of the judgment.

Article L. 133-6 lays down the principle: a payment transaction is authorised if the payer has given consent to its execution. Article L. 133-7 specifies that this consent is given in the form agreed between the payer and their payment service provider. In the absence of consent, the transaction is deemed unauthorised, with all the consequences the Code attaches to that classification, foremost among them the bank’s obligation to reimburse.

Who must prove what when a transfer is disputed?

This is where the decisive provision comes in: Article L. 133-23 of the Monetary and Financial Code. Where a payment service user denies having authorised a transaction that has been executed, it is for their payment service provider (the bank) to prove that the transaction was authenticated, duly recorded and accounted for, and that it was not affected by a technical or other deficiency.

But Article L. 133-23 contains a second paragraph, too often overlooked by the lower courts, which the Commercial Chamber reproduces word for word in its judgment: “The use of the payment instrument as recorded by the payment service provider is not necessarily sufficient in itself to prove that the transaction was authorised by the payer.”

The rule is crystal clear. The bank’s computer logs may show that the codes were entered, that authentication technically succeeded, that the transaction was recorded without any anomaly: all of this proves the use of the payment instrument. It does not prove the payer’s consent. A payment instrument can perfectly well be used by a fraudster who has captured the security data (by phishing, by social engineering, by compromising the computer) without the holder ever having consented to anything.

Why was the Paris Court of Appeal overturned?

The cassation is made on the basis of Articles L. 133-6, L. 133-7 and L. 133-23 of the Monetary and Financial Code, and it is total: the judgment of 22 January 2025 is quashed and set aside “in all its provisions”.

The Commercial Chamber’s reasoning comes down to a single sentence, in paragraph 6 of the judgment: “In so ruling, when Lincotek disputed having consented to these transactions and maintained that its personalised security data had been used without its knowledge, the Court of Appeal, by inferring consent to the disputed transactions from compliance with the contractually agreed form, reversed the burden of proof and infringed the above-mentioned provisions.”

What does reversing the burden of proof mean?

The reversal that is censured is subtle, and that is what makes the judgment so instructive. The Court of Appeal had not openly required the company to prove its lack of consent, which would have been a flagrant breach of the provision. It proceeded more insidiously, through a presumption: since the “form agreed” between the parties (user ID, access code, token) had been complied with, consent is “presumed” to have been given.

Yet this presumption exists nowhere in the law. Article L. 133-7 says that consent is given in the agreed form; it does not say that compliance with the agreed form amounts to consent. The nuance is crucial. The agreed form is the channel through which consent is expressed; it is not proof that the person who used that channel was indeed the account holder, nor that they genuinely consented. By turning a technical finding (the codes were used) into a legal presumption (the customer consented), the Court of Appeal gave the use of the payment instrument the evidentiary effect that Article L. 133-23, paragraph 2, expressly denies it.

In practice, the approach amounted to putting back on the victim’s shoulders the burden that the legislature had placed on the bank’s: once consent was “presumed”, it was for the company to rebut that presumption, that is, to prove a negative fact, namely that it had not authorised the transfers. An impossible proof (preuve diabolique), exactly what the PSD2 evidentiary regime was designed to avoid.

Why does the “token” not prove consent?

In this case, a device generating tokens had been assigned to a user within the company. The computer records showed that the disputed transfers had been validated by means of the user ID, the access code and a token produced by that device. For the Court of Appeal, this triad was enough.

That overlooked the fact that the technical validation of a transaction and legal consent to that transaction are two distinct things. Fraud scenarios that result in a “technically regular” use of security devices are legion: codes obtained through targeted phishing, an employee manipulated by a fraudster posing as a technician or a manager, remote takeover of the workstation, interception of security data. In all these cases, the bank’s logs will show a successful authentication, and yet the payer, that is, the company holding the account, will never have consented to the transactions.

This is exactly the argument put forward by the company: its personalised security data had been “used without its knowledge”. Since it disputed having consented, the bank had to prove consent, and not shelter behind the formal regularity of the authentication.

What is the scope of this judgment published in the Bulletin?

Publication in the Bulletin is never trivial: it signals that the Commercial Chamber intends to set the line and make it known to the lower courts. Three lessons emerge.

First lesson: the proof that the bank must provide under Article L. 133-23 is a two-stage proof. Establishing that the transaction was authenticated, recorded and accounted for without technical deficiency is a necessary condition, but not a sufficient one. When the customer disputes having consented, the bank must also prove consent itself. The lower courts cannot bridge this evidentiary gap with a judge-made presumption drawn from the “agreed form”.

Second lesson: the judgment neutralises an argument that banks systematically put to victims, individuals and businesses alike: “the transaction was validated with your security devices, so it was you, or someone you let act on your behalf”. This reasoning, seductive on its face, is now explicitly characterised as a reversal of the burden of proof when it is used to establish consent.

Third lesson: the cassation is pronounced “without there being any need to rule on the other ground”, which shows that the reversal of the burden of proof was enough on its own to justify the censure. The message sent to the courts of appeal is unambiguous.

Are businesses protected in the same way as individuals?

One of the major practical contributions of the judgment lies in the status of the victim: a simplified joint-stock company, a professional customer, operating on a corporate online banking area with an authentication device. The evidentiary regime of Article L. 133-23 applies to the “payment service user”, with no distinction between consumer and professional.

This clarification matters, because litigation over fraudulent transfers to the detriment of businesses (fake supplier fraud, CEO fraud, compromised online banking access) is massive, and the financial stakes are often far higher than in frauds targeting individuals. Victim businesses are frequently told that their professional status reduces the protection they enjoy. This judgment is a reminder that the evidentiary foundation of the Monetary and Financial Code applies fully in their favour: it is for the bank to prove consent, including where the payer is a company.

One point nonetheless calls for realism: some protective provisions of the Monetary and Financial Code may be varied by contract with professional customers, under the conditions laid down in Article L. 133-2 of the same Code. Checking the account agreements and the general terms of online banking therefore remains an indispensable first step in every business case. But on the question of the burden of proving consent, the Commercial Chamber’s position in this judgment contains no reservation based on the payer’s professional status.

Is this judgment part of settled case law?

The solution is not a revolution: it is the solemn reaffirmation of a line the Commercial Chamber had already drawn in disputed online payments (Cass. com., 18 January 2017, No. 15-18.102), holding that proof of fraud or gross negligence (négligence grave) by a user who denies having authorised a transaction “cannot be inferred from the mere fact that the payment instrument or the personal data linked to it were actually used”. The judgment of 1 July 2026 extends this logic to the neighbouring ground of consent itself, in respect of online transfers validated by token in a business context.

The consistency of the principle makes all the more striking the persistence, among some lower courts, of the reflex of equating successful authentication with consent given. The Paris Court of Appeal succumbed to that reflex; the cassation, published in the Bulletin, rings out as a call to order. The case is referred to the Versailles Court of Appeal, which will have to re-examine the dispute by placing the entire evidentiary burden on the bank.

What should you do if your business is the victim of fraudulent transfers?

This judgment considerably strengthens the position of victims, but the challenge must still be conducted methodically. The first exchanges with the bank are decisive: a clumsy turn of phrase (admitting having “validated” a transaction, having given a code over the phone, having clicked on a link) can be exploited by the institution to rebuild the debate on the ground of gross negligence. Before making any written or oral statement to your bank, and before filing any complaint, we strongly recommend that you read our practical guide: Bank Fraud: What to Say and Not to Say to Your Bank and in Your Complaint.

On the merits, the litigation strategy revolves around the evidentiary regime recalled by the judgment: formally dispute having consented to the transactions, demand from the bank the full proof that rests on it (authentication, recording, accounting, absence of technical deficiency, and the payer’s consent), and refuse any presumption drawn from the mere functioning of the security devices.

Beyond the burden of proof, other levers may be used depending on the circumstances: the bank’s compliance with its strong authentication and transaction monitoring obligations under the regulatory technical standards (RTS) supplementing PSD2 is an angle that is still under-used, particularly where the disputed transfers showed anomalies in amount, destination or frequency compared with the usual operation of the account.

Finally, filing a criminal complaint remains useful to document the fraud and to facilitate possible measures to freeze or recover the funds, even though it does not in itself provide a basis for compensation against the bank. Here too, the content of the complaint must be weighed carefully.

Conclusion

The judgment of 1 July 2026 is one of those that set the record straight. No, the technical validation of a transfer by user ID, access code and token does not amount to the payer’s consent. No, judges cannot “presume” that consent from compliance with the form agreed between the parties. Yes, it is for the bank, and the bank alone, to prove that its customer authorised the transaction they dispute, and this rule protects businesses and individuals alike.

For victims of fraudulent transfers, this reminder published in the Bulletin is a first-rate litigation lever: it closes the door on the most widespread banking argument and puts the court debate back where the legislature had placed it. If your business or you personally are faced with a refusal to reimburse based on the fact that “your codes were used”, be aware that this finding alone is not enough, in law, to make you bear the loss. The firm LE BOT Avocat, dedicated to banking law, assists victims of transfer fraud at every stage of the dispute, from the initial claim through to trial.

FAQ: Frequently Asked Questions