CIVIL LAW AND POST-DIGITAL TRANSFORMATION OF BANKING LIABILITY LAW IN EUROPE

1. Introduction

The European banking sector has moved through several technological stages:

Traditional banking → internet banking → mobile banking → open banking → AI-driven banking → cloud banking → post-digital banking.

In the traditional model, the main legal questions were:

Was the bank negligent?

Did it execute the customer's instructions?

Was the payment authorised?

Did the bank maintain confidentiality?

Was the bank liable for defective execution?

In the post-digital environment, additional questions arise:

Who bears the loss from a cyberattack?

What happens when an AI fraud-detection system incorrectly blocks a legitimate transaction?

Is a bank responsible when an automated system approves a fraudulent payment?

Who is liable when an open-banking API fails?

Can a bank transfer liability to a cloud provider?

What happens when biometric authentication is compromised?

How should liability be allocated between banks, fintechs, payment institutions and customers?

Does regulatory compliance automatically protect the bank from civil liability?

European banking liability is therefore increasingly based upon:

authentication + automation + cybersecurity + operational resilience + consumer protection + causation.

2. Meaning of Post-Digital Banking Liability

“Post-digital” banking does not simply mean online banking.

It describes a banking environment in which digital technology has become the basic infrastructure of banking, rather than merely an additional delivery channel.

Examples include:

mobile banking;

instant payments;

open banking;

APIs;

cloud computing;

artificial intelligence;

machine-learning fraud detection;

biometric authentication;

digital identity;

automated credit scoring;

robo-advice;

blockchain/DLT;

embedded finance;

fintech-bank partnerships;

automated compliance systems.

Liability therefore increasingly concerns system architecture, not merely individual employee negligence.

3. Basic Liability Formula

A simplified European banking-liability formula is:

Duty → Digital system/operation → Failure → Causation → Financial loss → Remedy

For example:

A bank operates an online-payment system.

A fraudster obtains access.

The bank's authentication system accepts the transaction.

The customer disputes it.

The legal question becomes:

Was this an authorised transaction, and if not, which party bears the loss under the applicable payment-services regime?

This distinction is central to European payment law.

4. Main Sources of European Banking Liability

Post-digital banking liability is derived from several overlapping legal regimes.

A. Payment Services law

The EU Payment Services Directive framework regulates:

authentication;

payment orders;

unauthorised transactions;

defective execution;

refund obligations;

information duties;

allocation of risk.

B. Consumer law

Consumer law regulates:

transparency;

unfair terms;

credit costs;

information duties;

contractual fairness.

C. GDPR

Banking increasingly involves extensive personal-data processing.

Examples:

transaction monitoring;

fraud detection;

profiling;

credit scoring;

behavioural analysis;

biometric authentication.

D. DORA

The Digital Operational Resilience Act—Regulation (EU) 2022/2554—creates an extensive framework for ICT risk management in financial entities.

It covers:

ICT risk management;

incident reporting;

operational resilience testing;

cyber threats;

business continuity;

ICT third-party risk;

cloud/technology providers;

incident response.

DORA expressly requires financial entities to maintain sound ICT-risk management and business-continuity arrangements and covers major ICT and payment-related incidents.

5. DORA and the Transformation of Banking Liability

DORA is particularly important to post-digital banking liability.

Its concept of digital operational resilience concerns the ability of a financial entity to maintain operational integrity and reliability, including through ICT third-party services, during disruptions.

Banks must therefore address:

1. ICT risk

Banks must identify technological vulnerabilities.

2. Detection

Banks must detect anomalous activities and ICT incidents.

3. Response

Banks must have procedures for containing incidents.

4. Recovery

Banks must restore critical functions.

5. Testing

Banks must test their digital resilience.

6. Third-party risk

Banks must manage risks arising from ICT service providers.

7. Post-incident review

Major incidents must be analysed so that lessons are incorporated into the risk-management framework.

This changes the concept of negligence.

In the traditional model:

“Did the bank employee act negligently?”

In the post-digital model:

“Did the bank design, monitor, test and govern its digital infrastructure with reasonable regulatory and operational safeguards?”

6. CASE LAW

CASE 1 — ZG v Beobank, C-351/21

Court

Court of Justice of the European Union.

Date

16 March 2023.

Facts

A Belgian customer had a debit card.

A legitimate €100 transaction was followed by two disputed transactions of approximately €991 and €993.

The customer argued that the latter transactions were unauthorised.

The bank's liability under the EU payment-services framework became the central issue.

Decision

The CJEU examined the provider's obligations concerning unauthorised payment transactions and the information that the provider must provide concerning the relevant payee.

The Court stressed that the payment-services liability regime governs the refund question and that the customer cannot simply bypass that regime by characterising the same event as another type of liability.

Principle

Classification of a transaction as authorised or unauthorised is fundamental to determining payment-service-provider liability.

Post-digital significance

This principle becomes especially important where transactions are executed through:

mobile terminals;

contactless cards;

tokenised payments;

digital wallets;

biometric authentication.

7. CASE 2 — UA v Eurobank Bulgaria, C-409/22

Court

CJEU.

Date

11 July 2024.

Facts

The case concerned allegedly unauthorised payment transactions and questions concerning:

authentication;

consent;

agents;

powers of attorney;

payment instruments;

burden of proof.

Decision

The CJEU examined the relationship between authentication and consent and the allocation of responsibility for allegedly unauthorised transactions under the payment-services framework.

Principle

Authentication and actual authorisation are legally related but must not simply be treated as identical concepts.

Importance

This is extremely significant in the post-digital environment.

A bank may argue:

“The transaction was authenticated.”

But the legal question may additionally be:

“Did the customer actually consent to the transaction?”

This distinction matters in cases involving:

stolen credentials;

phishing;

social engineering;

compromised devices;

malicious remote access;

fraudulent agents.

8. CASE 3 — DM and LR v Crédit Agricole, C-337/20

Court

CJEU.

Date

2 September 2021.

Facts

The case arose from alleged unauthorised payment transactions and concerned the notification requirements applicable to payment-service users.

The dispute also involved a guarantor of the payment-service user.

Decision

The CJEU interpreted Articles 58 and 60 of the Payment Services Directive and addressed the conditions governing liability for unauthorised transactions and notification.

Principle

The statutory notification and refund structure forms an important part of the allocation of risk between customer and payment provider.

Post-digital significance

Digital banking generates enormous quantities of transactions.

A customer may discover fraud:

immediately;

several days later;

through an automated notification;

through a bank statement;

through a fraud alert.

The legal timing of notification can therefore become critical.

9. CASE 4 — Tecnoservice Int. v Poste Italiane, C-245/18

Court

CJEU.

Date

21 March 2019.

Facts

A payment instruction contained an incorrect IBAN.

The name of the intended recipient did not correspond to the account associated with that IBAN.

The payment was nevertheless executed according to the supplied identifier.

The claimant argued that the bank should have detected the mismatch.

Decision

The CJEU held that when a payment order is executed according to the unique identifier supplied by the payment user, the statutory limitation of payment-service-provider liability applies to both the payer's and payee's payment service provider.

Principle

The bank's responsibility is strongly connected to execution according to the unique identifier supplied by the customer.

Post-digital importance

Modern payment systems rely heavily upon:

IBAN;

account identifiers;

APIs;

machine-readable payment instructions;

automated straight-through processing.

The case illustrates an important principle:

Automation does not automatically expand the bank's liability beyond the statutory payment-services framework.

10. CASE 5 — DenizBank v Verein für Konsumenteninformation, C-287/19

Court

CJEU.

Date

11 November 2020.

Facts

The case concerned multifunctional bank cards and their NFC/contactless functionality.

Questions arose concerning:

whether particular functionality constituted a payment instrument;

information duties;

changes to framework contracts;

low-value payment instruments;

authentication-related rules.

Decision

The CJEU interpreted the Payment Services Directive 2015/2366 in relation to multifunctional bank cards and contactless functionality.

Principle

Modern digital and contactless payment functionality must be analysed according to the legal definition and regulatory structure of payment instruments.

Post-digital significance

Banking liability now increasingly concerns:

contactless payments;

NFC;

digital wallets;

tokenised cards;

mobile devices.

The case demonstrates how traditional payment law adapts to technological developments.

11. CASE 6 — PrivatBank, C-480/18

Court

CJEU.

Date

2 April 2020.

Facts

The dispute concerned payment services, including questions about:

defective execution;

the person responsible;

prudential supervision;

complaints;

out-of-court redress;

competent authorities.

Decision

The CJEU interpreted the scope of the EU payment-services framework in relation to a credit institution and defective/non-executed payment orders.

Principle

Banking liability and regulatory supervision are related but distinct legal mechanisms.

A supervisory authority's powers do not automatically answer whether an individual customer has a private claim for damages.

Post-digital importance

This distinction becomes crucial after:

cyber incidents;

payment outages;

API failures;

cloud disruptions;

digital service interruptions.

12. CASE 7 — T-Mobile Austria, C-616/11

Court

CJEU.

Date

9 April 2014.

Facts

The case concerned the interpretation of payment instruments and charges associated with their use.

Decision

The CJEU interpreted provisions of the Payment Services Directive concerning payment instruments and charges.

Principle

Digital/payment functionality must be interpreted within the harmonised European payment-services framework.

Importance

Although the case predates the modern AI/cloud banking era, it demonstrates the earlier stage of European digital-payment regulation from which today's liability regime developed.

13. CASE 8 — Lexitor, C-383/18

Court

CJEU.

Date

11 September 2019.

Facts

The case concerned consumer credit and the consumer's right to a reduction in the total cost of credit after early repayment.

Decision

The CJEU held that the reduction could extend to costs imposed on the consumer in connection with the credit, rather than being restricted only to costs expressly calculated according to the remaining duration.

Principle

Consumer-credit liability and restitution must be interpreted in a manner that gives practical effect to consumer protection.

Post-digital relevance

Modern banking increasingly uses:

digital consumer loans;

automated credit agreements;

fintech lending;

app-based credit;

embedded finance.

The case therefore remains relevant to the consumer-protection side of post-digital banking.

14. CASE LAW SUMMARY

15. From Human Negligence to Systemic Negligence

Traditional banking liability was largely based upon human conduct.

For example:

Bank employee negligently enters wrong account number.

Post-digital banking changes the analysis.

Now:

Automated system generates the wrong instruction.

The court may need to examine:

system design;

testing;

data quality;

authentication;

cybersecurity;

access controls;

monitoring;

audit logs;

algorithmic configuration;

software updates;

vendor management.

This creates the emerging concept of:

Systemic digital negligence

The question becomes not merely:

“Who clicked the wrong button?”

but:

“Was the banking system reasonably designed and controlled to prevent foreseeable harm?”

16. AI Fraud Detection

Banks increasingly use automated systems to detect:

unusual transactions;

suspicious devices;

unusual locations;

transaction velocity;

behavioural anomalies;

mule accounts;

money laundering;

identity theft.

This creates two opposite liability risks.

False negative

The system fails to detect fraud.

Customer suffers financial loss.

False positive

The system incorrectly blocks a legitimate transaction.

Customer suffers:

business interruption;

missed payment;

contractual loss;

reputational damage.

Therefore:

AI accuracy becomes a potential civil-liability issue.

17. Algorithmic Banking Decisions

Digital banks may use algorithms for:

credit scoring;

fraud detection;

account restrictions;

AML monitoring;

transaction blocking;

customer segmentation.

A bank cannot necessarily avoid legal responsibility simply by stating:

“The algorithm made the decision.”

The bank normally remains responsible for the systems through which it conducts regulated banking activity.

This is consistent with DORA's governance approach: the management body bears ultimate responsibility for managing ICT risk and must establish appropriate governance, roles and responsibilities.

18. Open Banking

Open banking changes the traditional banking relationship.

There may be:

Customer → Account Servicing Bank → API → Third-Party Provider → Merchant

A single payment may therefore involve several entities.

Possible liability questions include:

Who authenticated the customer?

Who initiated the payment?

Who transmitted the payment instruction?

Who failed to secure the API?

Was the API unavailable?

Was the wrong account accessed?

Was the third-party provider negligent?

Did the bank comply with its regulatory obligations?

19. API Failure

Suppose:

A customer uses a fintech application.

The fintech connects through the bank's API.

The API fails.

A payment instruction is delayed.

The customer suffers a financial loss.

Potential defendants may include:

bank;

account-information/payment-initiation provider;

technology provider;

cloud provider.

The claimant must identify:

which contractual or statutory duty was breached and by whom.

DORA is important because financial entities must manage ICT risks and maintain arrangements designed to ensure continuity of critical or important functions.

20. Cloud Banking Liability

Modern banks increasingly depend upon:

cloud infrastructure;

external data centres;

SaaS providers;

cybersecurity companies;

payment processors.

This produces a new liability problem:

Can the bank escape responsibility because the failure occurred at a technology supplier?

Generally, outsourcing does not simply eliminate the bank's regulatory responsibility.

DORA expressly addresses ICT third-party risk and contractual arrangements with ICT third-party service providers.

The bank must therefore manage:

supplier risk;

concentration risk;

service continuity;

security;

contractual protections;

incident notification;

exit strategies.

21. Cyberattack Liability

A cyberattack can cause:

unauthorised transfers;

account takeover;

identity theft;

ransomware;

data loss;

service interruption.

The central civil-law questions are:

Question 1

Was the transaction authorised?

Question 2

Was authentication properly performed?

Question 3

Did the customer act fraudulently or negligently?

Question 4

Did the bank fail to comply with security obligations?

Question 5

Did the bank's system detect suspicious behaviour?

Question 6

Did the bank respond quickly enough?

Question 7

Was the damage caused by the cyberattack or by another event?

22. Social Engineering Fraud

One of the most difficult post-digital banking problems is:

The customer personally authenticates a transaction but does so because a fraudster manipulated the customer.

Examples:

fake bank employee;

phishing;

investment scam;

romance scam;

business-email compromise;

fake police communication;

remote-access fraud.

The legal question becomes more complicated than simple credential theft.

There is a spectrum:

Bank system hacked ← stolen credentials ← phishing ← social engineering ← customer deliberately authorised payment

The legal consequences may differ at every point.

23. Authentication Is Not Everything

The Eurobank Bulgaria case is particularly useful because it demonstrates why authentication should not automatically be equated with substantive consent.

A technically authenticated transaction may still generate litigation concerning whether the payment was genuinely authorised under the applicable legal framework.

Thus:

Technical authentication ≠ automatic immunity from civil liability.

24. Data Protection Liability

Banks hold extremely sensitive data:

account information;

transactions;

income;

credit history;

identity documents;

biometric information;

location data;

behavioural information.

Digital transformation therefore expands the possibility of claims concerning:

unlawful processing;

excessive profiling;

security failures;

unauthorised disclosure;

automated decision-making.

A banking system can therefore generate both:

financial liability + data-protection liability.

25. Cybersecurity as a Civil Standard of Care

Traditionally, a bank's duty of care was understood through:

reasonable banking practice;

contractual obligations;

statutory duties;

professional standards.

Post-digital banking adds:

cyber-risk assessment;

penetration testing;

authentication controls;

monitoring;

incident response;

backup;

recovery;

encryption;

access management.

DORA requires financial entities to establish comprehensive ICT-risk management and to maintain mechanisms capable of detecting anomalous activities and ICT incidents.

Therefore, regulatory cybersecurity requirements may increasingly influence what courts regard as reasonable banking conduct.

26. Regulatory Breach vs Civil Liability

An important distinction is:

Regulatory breach does not automatically equal civil liability.

For example:

A bank may breach an ICT reporting obligation.

That may lead to:

supervisory action;

administrative penalties;

remediation.

But a private claimant seeking damages still generally needs a legal basis for compensation and proof of causation and damage.

Conversely, compliance with regulations does not necessarily guarantee immunity from every private claim.

27. Causation in Digital Banking

Digital banking claims can have complex causal chains.

Example:

Cyber vulnerability → hacker access → fraudulent transaction → account freeze → missed business payment → contractual penalty

The claimant must determine which loss is legally attributable to the bank.

Courts may consider:

directness;

foreseeability;

intervening acts;

customer conduct;

third-party fraud;

mitigation;

contractual limitations.

28. Contributory Negligence

Customer behaviour can be important.

Examples:

sharing OTP;

revealing password;

installing malicious software;

ignoring security warnings;

failing to report fraud promptly.

But the customer's conduct does not automatically eliminate the bank's liability.

The court must apply the applicable statutory payment-services rules and determine whether the customer acted fraudulently or with the relevant degree of negligence.

29. Digital Banking Contract

Modern banking contracts increasingly include:

online terms;

app terms;

API agreements;

electronic authentication;

digital signatures;

automated notifications;

electronic statements.

This creates questions concerning:

incorporation of terms;

notice;

transparency;

unfair terms;

authentication;

electronic consent.

The customer may never sign a traditional paper contract, but the contractual relationship remains legally significant.

30. Consumer Protection

Digital banking must also respect consumer-protection principles.

Important areas include:

transparent fees;

clear digital disclosures;

accessible information;

unfair contract terms;

credit costs;

early repayment;

cancellation;

automated decisions.

Lexitor demonstrates the strong consumer-protection approach of the CJEU in the credit context.

31. Instant Payments

Instant payments create a new liability challenge.

Traditional bank transfer:

Instruction → processing → delay → possible intervention

Instant payment:

Instruction → authentication → execution → almost immediate completion.

This reduces the time available for:

fraud detection;

cancellation;

human intervention.

Consequently, prevention and real-time monitoring become increasingly important.

32. Digital Identity and Biometrics

Banks may use:

facial recognition;

fingerprints;

voice authentication;

device recognition;

behavioural biometrics.

A compromised biometric identifier presents a special problem:

A password can be changed; a fingerprint or face generally cannot.

This makes biometric security a particularly important component of post-digital banking liability.

33. Third-Party Fintech Liability

A customer may interact with a fintech rather than directly with the bank.

Potential parties include:

Bank.

Payment institution.

Fintech.

Account-information provider.

Payment-initiation provider.

Cloud provider.

Cybersecurity provider.

Merchant.

The law must determine:

Which entity owed which duty?

34. Bank's Duty to Monitor

A modern bank may have sophisticated tools capable of identifying:

unusual transaction size;

unusual geography;

unusual device;

rapid successive payments;

new beneficiary;

abnormal behaviour.

The existence of such technology may affect expectations concerning reasonable banking security.

However:

The existence of an algorithm does not mean that every fraud should have been detected.

Liability still depends on the applicable legal duty, statutory framework and causal evidence.

35. Operational Resilience

DORA changes the legal importance of operational continuity.

Banks must prepare for:

cyberattack;

cloud outage;

software failure;

data corruption;

telecommunications failure;

third-party failure;

payment-system disruption.

The bank must not merely prevent incidents.

It must also:

respond, recover and learn from them.

DORA expressly requires business-continuity arrangements and post-incident reviews designed to identify causes and improve ICT operations.

36. Banking Liability and AI

Future litigation may involve:

AI fraud system failure

AI fails to detect fraud.

AI false positive

Legitimate customer is blocked.

AI credit scoring

Customer receives an adverse credit decision.

AI AML decision

Account is restricted or closed.

Generative AI

Bank employee relies upon incorrect AI-generated information.

Autonomous banking agents

AI executes or recommends financial transactions.

The basic civil-law questions remain:

Duty + breach + causation + damage.

But the evidence becomes much more technical.

37. Evidence in Post-Digital Banking Litigation

Important evidence can include:

authentication logs;

IP addresses;

device fingerprints;

API logs;

transaction records;

fraud-alert records;

AI model outputs;

model configuration;

audit trails;

access logs;

cybersecurity reports;

incident-response records;

cloud-provider logs;

customer communications.

Digital evidence can therefore become central to proving:

who authorised the transaction and whether the bank's systems functioned correctly.

38. Burden of Proof

Payment-services legislation often establishes specific rules concerning:

authentication;

unauthorised transactions;

notification;

refund;

customer liability.

The Eurobank Bulgaria judgment is especially useful because the CJEU addressed the evidentiary relationship between authentication and liability.

The bank therefore cannot necessarily establish its entire defence merely by saying:

“Our computer says the transaction was authenticated.”

The legal framework determines what authentication proves and what additional facts must be established.

39. Contractual Exclusion Clauses

Banks may attempt to limit responsibility through contractual terms.

However, consumer-protection law and mandatory payment-services rules may restrict contractual derogations.

This is particularly important where the contract attempts to transfer:

cyber risk;

fraud risk;

system failure;

third-party technology risk

entirely to the customer.

Mandatory EU payment-services protections can prevent contractual arrangements from undermining statutory consumer rights.

40. Digital Banking and Traditional Civil Law

The transformation can be understood through this comparison:

41. Important Legal Principle: Technology Does Not Eliminate the Bank's Duties

A bank cannot normally argue:

“The computer made the decision, therefore nobody is responsible.”

The bank remains the regulated financial institution.

DORA's governance provisions reinforce this principle by placing ultimate responsibility for ICT risk management upon the financial entity's management body.

42. Important Legal Principle: Technology Also Does Not Automatically Increase Liability

The opposite proposition is equally important.

The fact that a bank uses sophisticated technology does not mean that it guarantees:

zero fraud;

zero downtime;

perfect AI;

perfect authentication;

perfect cybersecurity.

Liability still depends upon:

legal duty + breach + causation + damage.

43. Regulatory Compliance as Evidence

DORA compliance may become important evidence in civil litigation.

A claimant may ask:

Was there an ICT risk assessment?

Was the system tested?

Were vulnerabilities identified?

Was the incident properly recorded?

Was the bank's recovery plan activated?

Was a known vulnerability left unresolved?

The regulatory record may therefore become relevant evidence even where the private claim itself arises under contract or civil law.

44. Cross-Border Banking Liability

Digital banking makes geographical boundaries less significant.

Example:

customer in France;

bank in Belgium;

cloud provider in Ireland;

payment processor in Germany;

merchant in Spain.

Potential legal questions include:

jurisdiction;

applicable law;

consumer protection;

payment-services liability;

GDPR;

evidence;

enforcement.

The EU's harmonised payment-services framework attempts to reduce fragmentation, while private international law continues to determine jurisdiction and applicable law.

45. Multi-Party Liability

A single digital banking incident may involve:

Customer + Bank + Fintech + Cloud provider + Payment processor + Merchant + Fraudster.

The claimant must distinguish:

Primary liability

Entity directly responsible for the relevant breach.

Secondary liability

Entity legally responsible for another person's conduct.

Contractual liability

Liability arising from an agreement.

Statutory liability

Liability arising from mandatory legislation.

Tort/delict liability

Liability arising independently of contract.

46. Practical Example

A customer receives a fake bank call.

The fraudster persuades the customer to authenticate a payment.

The payment is executed instantly.

The customer contacts the bank twenty minutes later.

The bank's fraud system had already identified the transaction as highly unusual but did not stop it.

Possible issues

Issue 1: Was the payment authorised?

Issue 2: What did authentication establish?

Issue 3: Did the bank comply with its payment-services duties?

Issue 4: Did the customer act fraudulently or negligently?

Issue 5: Did the bank's fraud-monitoring system create an additional relevant duty?

Issue 6: Did the bank respond promptly after notification?

Issue 7: What loss is legally recoverable?

This is a classic post-digital banking liability problem.

47. Practical Example: Cloud Failure

Suppose:

A bank's cloud provider suffers a major outage.

Online banking becomes unavailable.

Customers cannot make payments.

A business customer misses a contractual deadline.

The customer claims damages from the bank.

The legal analysis should ask:

Did the bank owe a contractual service obligation?

Was the outage foreseeable?

Was adequate resilience maintained?

Did the bank have a contingency system?

Was the ICT provider properly supervised?

Did the bank comply with its continuity obligations?

Did the outage actually cause the claimed loss?

Did the customer mitigate its loss?

DORA's third-party ICT-risk framework becomes particularly relevant.

48. Practical Example: AI Credit Scoring

Suppose an AI system incorrectly rejects a loan.

The customer alleges:

inaccurate data;

discriminatory model;

inadequate explanation;

unlawful automated decision;

economic loss.

Possible legal regimes include:

banking/consumer law;

GDPR;

anti-discrimination law;

AI regulation;

contract law;

national civil liability law.

The bank cannot necessarily avoid responsibility by saying:

“The AI generated the score.”

The legal question is whether the bank's use and governance of the system complied with applicable law.

49. Remedies

Depending on the applicable regime, remedies may include:

Payment refund

For qualifying unauthorised transactions.

Damages

For proven financial loss where a private-law basis exists.

Interest

For delayed repayment.

Contractual remedies

For defective banking services.

Injunction

To prevent unlawful processing or conduct.

Data remedies

Correction, deletion or other GDPR remedies where applicable.

Regulatory remedies

Administrative penalties and supervisory measures.

Restitution

Particularly in consumer-credit disputes.

50. Key Case-Law Principles

ZG v Beobank

Unauthorised transaction classification is fundamental.

Eurobank Bulgaria

Authentication and consent must be legally analysed rather than mechanically equated.

Crédit Agricole

Notification rules form part of the payment-liability framework.

Tecnoservice

Correct execution according to the supplied unique identifier can limit provider liability.

DenizBank

Contactless and modern card functionality falls within the evolving payment-services framework.

PrivatBank

Payment-service liability and regulatory supervision are related but distinct.

T-Mobile Austria

Payment instruments and charges must be interpreted within the harmonised framework.

Lexitor

Consumer protection can require meaningful reduction/restoration of credit costs.

51. Ultra-Basic Revision Notes

Meaning

Post-digital banking liability = traditional banking liability + digital-system risk.

Main technologies

AI + Cloud + API + Mobile Banking + Biometrics + Instant Payments + Open Banking + Cybersecurity

Main risks

Fraud + Hacking + API failure + Cloud outage + AI error + Data breach + Authentication failure

Main legal questions

Who owed the duty?

Was the transaction authorised?

Was authentication sufficient?

Who caused the loss?

Was the customer negligent?

Was the bank's digital system reasonably secured?

Was a third-party provider responsible?

What damage is recoverable?

52. Ten Key Cases to Remember

ZG v Beobank — C-351/21
→ unauthorised payment liability.

UA v Eurobank Bulgaria — C-409/22
→ authentication, consent and burden of proof.

DM & LR v Crédit Agricole — C-337/20
→ notification and unauthorised transactions.

Tecnoservice — C-245/18
→ incorrect IBAN/unique identifier.

DenizBank — C-287/19
→ contactless/NFC payment instruments.

PrivatBank — C-480/18
→ defective payment execution.

T-Mobile Austria — C-616/11
→ payment instruments and charges.

Lexitor — C-383/18
→ consumer-credit costs.

DORA — Regulation 2022/2554
→ ICT operational resilience.

DORA Article 6 framework
→ management responsibility for ICT risk.

53. Conclusion

The post-digital transformation of banking has not replaced traditional civil-law principles. Instead, it has expanded the objects of banking liability.

The traditional model asked:

Did the bank execute the customer's instruction correctly?

The post-digital model asks a much broader series of questions:

Was the transaction properly authenticated?

Was it actually authorised?

Was the digital infrastructure secure?

Was the fraud-detection system appropriately designed and monitored?

Was the bank resilient against ICT disruption?

Was the customer properly protected?

Was the technology provider adequately governed?

Did the bank respond appropriately to the incident?

The CJEU's payment-services case law—particularly Beobank, Eurobank Bulgaria, Crédit Agricole, Tecnoservice, DenizBank and PrivatBank—shows the continuing importance of statutory allocation of payment risk.

At the same time, DORA represents a major shift toward systemic operational responsibility: financial entities must identify ICT risks, detect incidents, maintain continuity, test resilience, manage third-party ICT risks and learn from major incidents.

The emerging principle can therefore be expressed as:

Digital banking does not transfer responsibility from the bank to the machine.

Instead:

The more banking becomes technologically automated, interconnected and dependent on ICT infrastructure, the more liability analysis focuses on system design, authentication, governance, resilience, third-party risk and causation.

Thus, the post-digital European banking-liability model can be reduced to:

AUTHENTICATION + SECURITY + OPERATIONAL RESILIENCE + CONSUMER PROTECTION + CAUSATION + DAMAGE = MODERN BANKING LIABILITY.