Paris Court of Appeal, Pôle 4, Chamber 9 A, 11 June 2026, No. 25/09073
🔑 Key takeaways
- The Paris Court of Appeal upholds the order requiring BNP Paribas to refund €8,722.97 to a customer who was the victim of a fake bank adviser (spoofing).
- It is for the bank, not the customer, to prove that the disputed transaction was authenticated, recorded and not affected by a technical failure (Art. L. 133-23 of the Monetary and Financial Code, code monétaire et financier).
- All online logins allowing the card code to be viewed, the password to be changed or the limit to be raised required strong authentication; the bank does not show that it applied it.
- Asserting that “the confidential code must have been entered” amounts to reversing the burden of proof: the bank shows neither that the code was entered nor that the customer disclosed it.
- Handing one’s card to a courier is negligent, but not “grave” (gross), in the absence of proof that the code was disclosed and used.
- Interest at the statutory rate runs from the outset of the refusal: the bank could not legitimately refuse to refund when it did not have the proof that lay upon it.
Contents ▼
- What happened in this fake bank adviser case?
- Who must prove what when a banking transaction is disputed?
- Why did the absence of strong authentication make the bank lose?
- Could the bank simply assert that the code “must have been entered”?
- When does negligence become “grave” enough to deprive a customer of a refund?
- Why does interest run from the outset of the refusal to refund?
- What to remember if you are the victim of a fake adviser fraud?
- FAQ: Frequently asked questions
What Happened in This Fake Bank Adviser Case?
The scenario has become sadly commonplace, but it remains formidably effective. On 10 September 2022, at around 2 p.m., the holder of a BNP Paribas account receives a call. On the line, a person introduces themselves as an adviser from his bank. They warn him: fraudulent transactions have just been attempted with his card, notably purchases of plane tickets on an African platform. The tone is urgent, the situation seems serious. Frightened and stressed, the customer follows the instructions he is given “to put an end to the fraud in progress”: he agrees to hand his bank card to a courier on a scooter, who arrives at his home at around 3 p.m.
The customer states that he never disclosed his confidential code or his credentials. Yet, in the hours and days that follow, his account is emptied. Between 11 and 13 September 2022, fourteen transactions are carried out: thirteen purchases from merchants for a total of €6,723.97 and a cash withdrawal of €2,000, making €8,722.97 in all. In the meantime, the password for the online area has been changed and the card’s payment limit raised to €12,000.
The victim reacts quickly: he disputes the transactions with BNP Paribas on 21 September 2022 (as confirmed by a letter from the bank dated 5 October), files a criminal complaint on 23 September and stops his card. The bank nevertheless refuses to refund him, considering that the customer committed gross negligence. The case is brought before the Paris Local Court (tribunal de proximité), which, by judgment of 17 April 2025, orders BNP Paribas to pay the €8,722.97, with interest at the statutory rate from 17 April 2024, plus €1,600 in respect of legal costs. The bank appeals. On 11 June 2026, the Paris Court of Appeal upholds the judgment in all respects and orders BNP Paribas to pay the costs of the appeal.
Spoofing refers to the impersonation of a banking institution. The fraudster poses as an adviser (by telephone call, sometimes displaying the bank’s real number) in order to inspire trust and push the victim into carrying out operations or handing over elements of their card. It is a social engineering technique that exploits fear and urgency rather than a purely IT flaw.
Who Must Prove What When a Banking Transaction Is Disputed?
This is the whole heart of the dispute, and it is where many victims give up wrongly. When a customer disputes a transaction that they did not authorise, the instinct, encouraged by banks, is that it is for them to prove that they did nothing. It is exactly the opposite. The Monetary and Financial Code places the burden of proof on the payment service provider, that is, the bank.
Where a user denies having authorised a payment transaction that has already been executed, it is for their bank to prove that the transaction was authenticated, duly recorded and accounted for, and that it was not affected by a technical deficiency. The text specifies that the mere use of the payment instrument, as recorded by the bank, is not sufficient to prove that the transaction was authorised by the customer or that they committed gross negligence.
The Court of Appeal sets out an evidential mechanism in two stages, which must be well understood because it determines the outcome of most fraud cases. Where the customer denies having authorised a transaction, the bank must, first, prove that it was indeed the user’s authentication data that were used and that there was no technical failure. Only second, and even where authentication was strengthened and those data were used, must the bank provide evidence demonstrating fraud or gross negligence on the part of the user.
The burden of proof, step by step
The customer disputes a transaction
↓
Step 1: The bank must prove that the customer’s authentication data were used and that there was no technical failure
↓
Step 2: Even if strong authentication was applied, the bank must also prove the customer’s fraud or gross negligence
↓
If the bank fails at either step → full refund to the customer
This logic is fundamental: as long as the bank has not cleared the first step, the very question of the customer’s negligence does not arise. It is precisely on this first step that BNP Paribas stumbled.
Why Did the Absence of Strong Authentication Make the Bank Lose?
To show that the transactions had been properly authenticated, BNP Paribas produces only one document: a “statement of remote connections” listing some thirty logins to the account. The problem: almost all of these logins are described as having been made “by customer number and password”. Yet a username and a password do not, on their own, constitute strong authentication.
Defined in Article L. 133-4 f) of the Monetary and Financial Code, strong authentication relies on the use of at least two independent elements belonging to different categories: “knowledge” (something only the user knows, such as a password), “possession” (something only the user has, such as their telephone) and “inherence” (something the user is, such as their fingerprint). Independence means that the compromise of one does not call the others into question.
Article L. 133-44 of the Monetary and Financial Code requires the bank to apply this strong authentication in three situations: when the payer accesses their payment account online, when they initiate an electronic payment transaction, and when they carry out a transaction by a remote means of communication that may involve a risk of fraud.
Delegated Regulation (EU) No. 2018/389, which supplements the Payment Services Directive (PSD2), lays down the regulatory technical standards (RTS) requiring strong authentication and the monitoring of transactions. The bank relied on its Article 10, which allows an exemption from strong authentication for the mere viewing of the balance within 90 days. But this exemption does not cover the sensitive operations at issue here.
The court’s analysis here is particularly instructive. It first notes that the exact nature of the logins is not specified in the statement produced, except for the password changes and the raising of the limit: it is therefore impossible to say that they correspond to the card payments. Above all, the court finds that all the logins made online required strong authentication, because they allowed not only the account balance to be viewed, but also the card’s confidential code to be displayed, the password to be changed and the payment limit to be raised. The customer showed this with a document, not disputed by the bank, establishing that the online area gave access to the card code.
The reasoning is implacable: if the personal area made it possible to see the card’s confidential code without strong authentication, then the fraudster who had entered that area (since he had changed the password and raised the limit) could have retrieved the code there himself, without the customer ever needing to disclose it to him. By failing to show that it had applied strong authentication to these nonetheless sensitive operations, the bank did not discharge the required burden of proof. The first evidential step is not cleared.
Could the Bank Simply Assert That the Code “Must Have Been Entered”?
This was BNP Paribas’s central argument: since the purchases had been made physically at merchants and a withdrawal had been made at a cash machine, the confidential code had necessarily been entered; and if the code was entered, it is because the customer had given it to the fraudster along with his card. The argument has the appearance of common sense. The court nonetheless dismisses it, and this is one of the most useful contributions of the judgment.
The court notes that, in doing so, the bank reverses the burden of proof. Two flaws are identified. First, the bank does not even show that the confidential code was actually entered: no IT evidence is produced to support that assertion. Second, even supposing that it was, the bank in no way shows that it was the customer who disclosed that code, even though it has just been established that this code was accessible online, without strong authentication, to anyone who had broken into the personal area.
“The code was entered, therefore the customer gave it”: this shortcut is legally flawed. It makes the victim prove a negative (not having disclosed their code), whereas the law requires the bank to prove gross negligence positively. A mere assertion, unsupported by technical traces, is never enough.
This reasoning is valuable for all victims faced with the same argument. Many refusals to refund are in fact based on begging the question (pétition de principe): the bank starts from the result (the money has gone) to infer the customer’s fault (they must have given away their data). The Court of Appeal recalls that a syllogism is not proof, and that a bank that produces no technical trace of the code being entered cannot make its customer bear the weight of its own failure of proof.
When Does Negligence Become “Grave” Enough to Deprive a Customer of a Refund?
The bank does not bear the loss if it proves that the customer committed gross negligence in safeguarding their data. The whole difficulty lies in the borderline between mere imprudence, which does not exonerate the bank, and gross negligence, which deprives the customer of a refund.
Gross negligence (négligence grave) is a clear breach by the user of their obligation to preserve the security of their personalised data. It presupposes conduct that any normally attentive account holder would have avoided. It is for the bank to prove it; any doubt benefits the customer. Not every act of imprudence is gross negligence.
The court recalls the dividing line established by case law on spoofing: a user who validates transactions by answering a call displayed on their telephone as coming from their bank commits no fault; on the other hand, a user who replies to messages whose fraudulent nature should have been apparent to them, or who clicks on manifestly dubious links, commits gross negligence. The nuance lies in the plausibility of the approach and in the vigilance that the circumstances allowed one reasonably to expect.
Applying these principles, the court accepts that the customer did commit negligence in entrusting his card to a stranger. But it refuses to describe it as grave, for a strictly evidential reason: it is not established that he also gave his confidential code, nor that this code was actually used to make the payments and the withdrawal that he disputes. In other words, negligence relating to the physical card is not enough, on its own, to establish gross negligence, since the causal chain between the customer’s conduct and the fraudulent debit is not demonstrated.
The overall coherence of the reasoning should be noted: the distressing context of the call, which reduced the victim’s vigilance, and the implausibility of a bank asking its customers to hand their card to a courier, both help to rule out the seriousness of the fault. The fear instilled by the fraudster is part of the analysis, and not a neutral circumstance.
Why Does Interest Run From the Outset of the Refusal to Refund?
BNP Paribas sought, in the alternative, to push back the starting point of interest at the statutory rate to the day of the judgment, arguing that late-payment penalties apply only where the bank has breached its obligation to refund. The court, on the contrary, upholds the starting point adopted at first instance.
The justification is clear: the bank could not legitimately refuse to refund when it was unable to provide the proof that lay upon it in the first place. In other words, the refusal to refund was wrongful from the outset, because the bank did not have the evidence that would have allowed it to rely on that refusal. Interest therefore runs from the date set by the first judge, and not from the judgment. This is a point that is far from insignificant financially: on substantial sums and in proceedings that stretch over several years, the starting point of interest is a real issue.
On the other hand, the court upholds the dismissal of the claim for damages for non-material harm (préjudice moral): the customer merely asserted it without supporting it with a single document. This is a useful reminder: even where refund of the principal is secured, compensation for a separate harm presupposes concrete proof of it.
What to Remember If You Are the Victim of a Fake Adviser Fraud?
This judgment forms part of a body of case law that is increasingly protective of fraud victims, running counter to the guilt-tripping line often taken by banks. Several practical lessons emerge.
First, never accept without reacting a refusal to refund based on the mere assertion that “the data must have been used by you”. The bank must produce precise technical traces; a vague statement of logins, which does not distinguish the nature of the transactions and does not establish that strong authentication was applied, is insufficient. The absence of strong authentication on sensitive operations (access to the card code, password change, raising of the limit) is a decisive line of attack.
Next, keep and gather evidence of your promptness: date of the challenge to the bank, filing of a complaint, stopping of the card. In this case, the challenge made as early as 21 September, the complaint of 23 September and the stop request strengthened the victim’s position and ruled out any time-bar (forclusion). Filing a complaint remains, in this respect, factually very useful, even though it is not in itself a basis for civil compensation.
Finally, when looking for the grounds of the bank’s liability, one must reason in terms of payment law and the technical obligations that flow from it. Beyond the burden of proof under Article L. 133-23, the obligations arising from the regulatory technical standards (RTS) supplementing PSD2 (strong authentication, monitoring and detection of abnormal transactions) are a still under-used lever for engaging the liability of an institution that allowed a fraud to flourish without triggering the safeguards it was required to implement.
In practice: the right reflex after a fraud
- Challenge in writing with the bank as soon as possible (and at the latest within 13 months).
- Stop the card and file a complaint.
- Require the bank to prove strong authentication of the disputed transactions.
- Do not be intimidated by the argument “the code must have been entered”.
- Consult a banking law lawyer to assess the procedural levers.
Conclusion
The Paris Court of Appeal’s judgment of 11 June 2026 is a clear and instructive decision, which puts the burden of proof back where it belongs: on the shoulders of the bank. As long as an institution does not show that it applied strong authentication to sensitive operations, and produces no trace of the confidential code actually being entered, it cannot take refuge behind its customer’s “gross negligence” to refuse to refund. Handing one’s card to a fraudster posing as one’s adviser remains imprudent, but imprudence is not gross fault, especially where the bank itself left the card code accessible online without enhanced security. For victims of spoofing, the message is encouraging: the battle is not lost in advance, and the terrain of technical proof is often the one on which banks are most vulnerable.
