Fake Security Questionnaire: No Gross Negligence by the Customer (TJ Lyon, 23 June 2026, No. 25/01406)

Lyon Court of First Instance, 4th Chamber, 23 June 2026, RG No. 25/01406

What happened in this fake security questionnaire fraud case?

The facts decided by the Lyon Court of First Instance illustrate a formidable variant of phishing: one that unfolds not in the victim’s mailbox, but at the very heart of his digital banking environment.

How did the scam unfold?

In mid-February 2024, the holder of an account with Banque Populaire Auvergne Rhône Alpes is managing his accounts on his banking app when he receives a notification presented as coming from his bank. The message reproaches him for not having answered a questionnaire on the security of his bank card. Trusting, since he is then logged in to his personal area with his credentials, the customer fills in the questionnaire, which asks him in particular for his card numbers. He then receives an email notifying him that his card is blocked for 72 hours.

In reality, the questionnaire was a decoy. The fraudster, having obtained the customer’s data, then has a request validated whose wording was cryptic (“I authorise this connection” or “I do not authorise this connection”), which in fact concealed the enrolment of a new phone as the device receiving SECUR’PASS codes, the bank’s strong authentication system. From then on the fraudster holds the key to the vault.

On the evening of 20 February 2024, the customer receives by SMS a notice of an instant transfer of €4,700. He reacts without delay: he disputes the operation by email to his adviser at 10:31 p.m., thirty-eight minutes after being informed of it according to the grounds of the judgment. The account is blocked by the bank on 21 February at 12:30 a.m. Too late: the next morning, the customer discovers that two further transfers of €4,950 and €5,000 have been debited. He files a criminal complaint on 23 February 2024. On 26 and 27 February, two bank card payments of €6,650 and €41.98 are still made (the card had not been blocked), which leads the customer to make an online report via the PERCEVAL platform.

How did the bank justify its refusal to reimburse?

Banque Populaire refused any reimbursement on the ground that the operations had been validated by entry of the SECUR’PASS code, a strong authentication system which, according to the bank, complies with the second Payment Services Directive (PSD2). Before the court, it argued that the operations had been authenticated, recorded and accounted for without any technical deficiency, that any operation carried out in the agreed form is presumed to be authorised, and that its duty of vigilance obliged it only to detect glaring anomalies.

Above all, the bank pleaded the customer’s gross negligence: he had allegedly opened a phishing page believing he was answering a security questionnaire, he should not have validated the enrolment of a new phone when he had not changed device, and he had allegedly been slow to report the fraud. These are all arguments that the court will methodically dismiss.

What does the law say about reimbursement of unauthorised operations?

The court begins by recalling a now firmly established principle: where a payment service provider’s liability is sought on account of an unauthorised or incorrectly executed operation, only the specific liability regime defined by the Monetary and Financial Code applies, to the exclusion of ordinary law.

Who must prove what in payment instrument fraud?

The evidentiary architecture of the Monetary and Financial Code is built entirely in the payer’s favour. Article L. 133-23 provides that where the user denies having authorised an operation, it is for the bank to prove that the operation was authenticated, duly recorded and accounted for, and that it was not affected by a technical or other deficiency. The same text specifies, decisively, that the use of the payment instrument as recorded by the provider is not necessarily sufficient in itself to prove that the operation was authorised by the payer, or that the payer was grossly negligent.

Article L. 133-19 II adds that the payer is not liable if the unauthorised operation was carried out by misusing, without the payer’s knowledge, the payment instrument or the data linked to it. Paragraph IV of the same article makes the payer bear losses only if they result from fraudulent conduct on his part or from an intentional breach, or one amounting to gross negligence, of his obligations to preserve his personalised security data (Article L. 133-16).

The court summarises this combined reading: where the account holder claims that an operation was not authorised, it is for the bank to prove authentication, recording, accounting and the absence of technical deficiency, unless it shows gross negligence by the account holder. Two cumulative items of proof, then, the burden of which the bank bears alone.

Why does phishing received in the banking app reveal a technical failure by the bank?

This is the most striking contribution of the judgment. The customer explained, without being contradicted by the bank, that the booby-trapped notification came directly from his personal banking area: he was already logged in with his credentials when it appeared. The court draws a radical conclusion: “The fact that Mr [Z] received such a message on his online app, even though it was a link to a phishing site, demonstrates a technical failure in the bank’s security system, and rules out any gross negligence on his part.”

The reasoning is highly logical. A customer’s authenticated personal area is supposed to be a secure environment, controlled end to end by the institution. If fraudulent content manages to appear there, whatever the technical mechanism, the bank’s security perimeter has been breached. The failure is no longer to be sought in the gullible customer, but in the institution’s own system. And this same circumstance neutralises the complaint of gross negligence: a customer cannot be blamed for trusting what is displayed in the environment his bank presents to him as safe.

Here, in outline, is the sequence of the fraud as it emerges from the judgment:

The bank tried to shift the debate: the customer had allegedly “believed he was chatting in his personal area” when he had in fact opened a fraudulent message. But this explanation, far from exonerating the bank, drives the point home: if the boundary between the authenticated area and the trap is indistinguishable to the user, then the security put in place by the bank was indeed deficient.

Why was the customer not grossly negligent?

The court examines the bank’s complaints one by one and dismisses them all, in reasoning that deserves reflection by every institution tempted to meet phishing victims with a blanket refusal.

Is giving one’s bank card number gross negligence?

No, answers the court, at least not in this context. Providing the card number “cannot constitute gross negligence since it is required for any online payment and given the context of the request received on the banking app”. The card number is not a secret code in the strict sense: everyone gives it at every online purchase. Disclosing it in response to a request appearing in one’s own banking area cannot amount to the breach of particular seriousness required by law. The customer further maintained that he had not entered his confidential codes on this occasion.

Does validating “I authorise this connection” make the customer liable?

This is the second major practical lesson. The bank blamed the customer for validating the enrolment of a new phone when he had not changed device, which it said was a sign of obvious fraud. But the court notes that the wording of the request “is not explicit since it merely states ‘I authorise this connection’ or ‘I do not authorise this connection’, without any detail or reference to new equipment”. The customer cannot be blamed for accepting a connection when he legitimately believed he was still on his banking app.

The lesson is a warning to banks: security through cryptic messages protects no one. A strong authentication system whose validation screens do not clearly say what the user is authorising, here the attachment of an unknown device to his account, misses its target and cannot ground any complaint against the customer.

Was the customer slow to report the fraud?

Finally, the bank put forward late reporting. The argument collapses in the face of the chronology: informed of the first transfer by SMS at 9:53 p.m., the customer disputed it by email at 10:31 p.m., thirty-eight minutes later, on a weeknight, then disputed the following operations as soon as he became aware of them, filed a criminal complaint three days after the events and reported the card payments via the PERCEVAL platform. It is hard to imagine more exemplary responsiveness. The blocking of the account, which took place on 21 February at 12:30 a.m., did not in any event prevent the card payments of 26 and 27 February, as the card had not been blocked, a failing that lies within the bank’s sphere, not the customer’s.

Why were the bank’s Excel listings excluded from the proceedings?

One last line of defence remained for the bank: proving that each operation had been validated by entry of the SECUR’PASS code. To do so, it filed some forty pages printed on both sides, taken from an Excel file. The court does not mince its words: these pages “are not numbered and are totally incomprehensible and unusable for the Court, containing only numbers, dates and technical indications, apart from the entries and comments added on certain lines”. The printout had cut up the table to the point of making it impossible to decipher, with no indication of how to assemble it or of the page order.

And the court adds the finishing blow: “In any event, no one can create evidence for themselves.” The technical logs produced by the bank, generated by its own systems and commented on in its own hand, cannot suffice to establish that the customer himself used the strong authentication codes.

This twofold reasoning is valuable for victims. First because it recalls a requirement as to the quality of evidence: a bank claiming to demonstrate the authentication of an operation must produce legible, ordered, usable material, not a raw dump of technical data. Second because it applies the principle that the bank’s internal records, which neither the customer nor the judge can verify, cannot on their own constitute the proof required by Article L. 133-23. The conclusion then follows automatically: the bank demonstrates neither the absence of a technical failure nor gross negligence, so reimbursement is due.

What practical lessons can be drawn from this judgment if you are a fraud victim?

This judgment provides a roadmap for victims of payment instrument fraud, whether classic phishing, fake bank adviser fraud or, as here, a fake security questionnaire infiltrated into the banking environment.

The first lesson concerns timing: the victim’s responsiveness carried great weight. A written dispute within forty minutes of the alert SMS, an email to the adviser, a prompt criminal complaint, a PERCEVAL report for the card payments: each step built the case. Reporting each disputed operation without delay, in writing and keeping proof of sending, is essential; Article L. 133-24 moreover confines reporting to a period of thirteen months for consumers.

The second lesson concerns what is said to the bank and to investigators. The statements made in the complaint served the customer here: they established that he was logged in to his personal area when the trap closed. But clumsy statements can, conversely, be exploited by the bank to plead gross negligence. Before drafting your dispute or your complaint, read our complete guide: Bank Fraud: What to Say and Not to Say to Your Bank and in Your Complaint.

The third lesson concerns evidence: do not be impressed by the bank’s technical assertions. “The operation was validated by strong authentication” is not proof, it is an allegation. Demand production of the underlying material, challenge its legibility and probative value, and recall that the mere use of the payment instrument as recorded is not enough, and that the regulatory technical standards (RTS) supplementing PSD2 impose precise requirements on banks regarding strong authentication and transaction monitoring, an angle that is still under-exploited in these disputes.

What is the significance of this judgment for victims of banking fraud?

This judgment of the Lyon Court of First Instance is part of a case-law trend that is demanding of banks as regards the double proof required by Article L. 133-23, but it adds two distinctive building blocks.

First, the statement that receiving a phishing message within the banking app amounts to a technical failure in the bank’s security system carries considerable weight. It shifts the ground of the debate: instead of dissecting the victim’s behaviour, the judge scrutinises the integrity of the digital environment the bank makes available. Institutions will no longer be able to retreat behind the technical validation of operations where the entry point of the fraud lies within their own application ecosystem.

Second, the rejection of illegible computer listings on the twofold ground that they are unusable and that no one may create evidence for themselves effectively arms victims against a widespread practice: the mass production of raw technical data, supposed to serve as demonstration. The message is clear: proof of authentication must be intelligible and verifiable, failing which it proves nothing.

Finally, two nuances should be noted. The court rejected the customer’s claim for additional damages, for lack of evidence of bad faith on the bank’s part: a mere refusal to reimburse, even if unjustified, is not in itself wrongful absent intent to harm. And interest ran only at the statutory rate from 5 March 2024, as requested, the customer not having sought the benefit of the specific provisions of Article L. 133-18, which nonetheless provides for immediate reimbursement with the account restored to the state it would have been in had the operation not taken place. Two points of litigation strategy to be handled with care in future cases.

Ultimately, this judgment recalls a self-evident point that fraud victims sometimes lose sight of in the face of their bank’s categorical refusal: the law is on their side, and so is the burden of proof. Where the fraud has infiltrated the banking app itself, it is the bank’s system that failed, and it is for the bank to bear the consequences. If your bank sets strong authentication validation or your alleged gross negligence against you, do not give up: each case deserves a precise analysis of the chronology, the messages received and the evidence actually produced by the institution.

FAQ: Your Questions on Fake Security Questionnaire Fraud