Civil Law and Banking Technology Service Liability in Europe

1. Introduction

Banking technology service liability concerns civil liability arising when a bank's technological systems or technology-enabled banking services fail and cause loss to a customer, merchant, business, or another payment-service participant.

Examples include:

online-banking system failures;

mobile-banking failures;

payment-platform failures;

ATM malfunction;

card-payment failures;

contactless-payment problems;

authentication failures;

cybersecurity incidents;

phishing-related unauthorised transactions;

incorrect automated payment processing;

API/open-banking failures;

payment-initiation failures;

cloud or outsourced IT failures;

defective banking software;

incorrect transaction records;

delayed or duplicated transactions.

There is no single EU civil-liability statute covering every banking technology failure. Liability is normally constructed from EU payment-services legislation, consumer law, data-protection law, electronic-commerce rules and the applicable national contract/tort law.

For payment services, Directive 2015/2366 (PSD2) is particularly important. It contains specific rules for unauthorised transactions, technical failures, authentication, payment initiation and allocation of liability among payment-service providers. (Eur-Lex)

2. What Is a Banking Technology Service?

A banking technology service is a banking service delivered substantially through technological infrastructure.

It may involve:

Customer-facing technology

mobile banking;

internet banking;

ATM;

payment cards;

contactless payments;

biometric authentication;

digital wallets.

Bank infrastructure

core banking software;

transaction-processing systems;

payment gateways;

fraud-detection systems;

authentication systems;

databases;

cloud systems.

Intermediary technology

payment-initiation service providers;

account-information service providers;

card processors;

payment gateways;

open-banking APIs;

outsourced IT providers.

The legal question is therefore often:

Who bears the loss when technology used to provide a banking service fails?

3. European Legal Framework

A. PSD2

Directive 2015/2366 is the central EU framework for payment-service liability.

It regulates:

authentication;

payment instruments;

payment initiation;

account information;

unauthorised transactions;

defective execution;

non-execution;

liability between payment-service providers.

Under Article 72, where a payment user denies authorising a transaction, the use of a payment instrument recorded by the provider is not by itself necessarily sufficient to establish authorisation or fraud/gross negligence. The provider must provide supporting evidence where fraud or gross negligence is alleged. (Eur-Lex)

4. Liability for Unauthorised Digital Payments

Article 73 PSD2 establishes a strong refund mechanism.

Where an unauthorised payment transaction occurs, the payer's payment-service provider must generally refund the amount immediately and no later than the end of the following business day, subject to the Directive's limited exception concerning reasonable grounds to suspect fraud. (Eur-Lex)

This is extremely important in cases involving:

phishing;

stolen credentials;

malware;

account takeover;

fraudulent mobile banking;

fake bank websites;

unauthorised card transactions.

5. Customer's Possible Liability

The customer is not automatically protected in every situation.

Article 74 PSD2 can impose limited liability for certain lost, stolen or misappropriated payment instruments, normally up to €50 in the specified circumstances.

Greater liability can arise where the payer acted fraudulently or intentionally or with gross negligence failed to comply with relevant security obligations. (Eur-Lex)

Therefore:

Technology fraud does not automatically mean that the bank is liable for every loss, but neither does successful authentication automatically prove customer fault.

6. Case Law

Case 1 — ZG v Beobank SA

C-351/21, CJEU, 16 March 2023

This is one of the most important modern cases for technological banking-service liability.

Facts

The dispute concerned payment transactions from a customer's account and the information that the payment-service provider was required to provide concerning the beneficiary/payee.

Issue

The CJEU had to consider the provider's information obligations and the relationship between those obligations and the statutory liability regime for unauthorised transactions.

Decision

The Court held that the payment-service provider must provide information enabling the payer to identify the person who benefited from the transaction, rather than merely supplying whatever limited information the provider happened to possess.

The Court also emphasised that the EU regime for liability concerning unauthorised transactions is harmonised and cannot simply be replaced by a competing national liability regime concerning the same operative event.

Importance

The case is relevant to:

digital payment records;

transaction identification;

electronic banking evidence;

unauthorised payments;

allocation of liability.

7. Case 2 — UA v Eurobank Bulgaria

C-409/22, CJEU, 11 July 2024

Facts

The dispute involved an alleged unauthorised payment and issues concerning:

a power of attorney;

payment instruments;

authentication;

consent;

evidentiary burdens.

Issue

The Court was required to determine the meaning of authentication and how liability for unauthorised transactions should be established.

Importance

The judgment is particularly relevant where a bank argues:

“The transaction was authenticated, therefore the customer must have authorised it.”

European law does not permit that proposition to be treated as automatically conclusive. The statutory framework requires analysis of authorisation and the relevant evidence. (Infocuria)

Banking technology significance

The case is useful for disputes involving:

electronic authentication;

digital signatures;

payment credentials;

online banking;

power-of-attorney arrangements;

fraud investigation.

8. Case 3 — Veracash

C-665/23, CJEU, 1 August 2025

Facts

A customer held a gold-backed account with Veracash. A payment card was allegedly never received by the customer, but withdrawals were made from the account.

The customer notified the provider approximately two months after the first disputed withdrawals.

Issue

The question concerned the effect of failure to notify the payment-service provider without undue delay.

Decision

The CJEU held that a payment-card user can lose the right to obtain reimbursement of an unauthorised transaction if, after becoming aware of it, the user fails to notify the provider without undue delay through intent or gross negligence—even if notification occurs within the longer statutory period. (curia)

Importance

The case demonstrates that technology-service liability involves shared responsibilities.

The bank has technological and statutory duties, but the customer also has duties concerning:

monitoring transactions;

protecting payment instruments;

reporting suspected fraud;

security precautions.

9. Case 4 — DM and LR v Crédit Agricole

C-337/20, CJEU, 2 September 2021

Facts

The case involved allegedly unauthorised payment transactions and a claim brought by guarantors of the payment-service user.

Issue

The Court examined the notification and liability regime under the Payment Services Directive.

Importance

The case confirms the importance of the EU statutory framework for determining liability for unauthorised electronic transactions. It also illustrates that the right to invoke payment-service liability depends upon the legal status of the person bringing the claim. (Infocuria)

Relevance

This becomes important where:

a company account is involved;

a guarantor claims against the bank;

a third party suffers loss;

several parties are connected to the banking contract.

10. Case 5 — DenizBank AG v Verein für Konsumenteninformation

C-287/19, CJEU, 11 November 2020

This is particularly important for contactless banking technology.

Facts

DenizBank used multifunctional bank cards equipped with NFC/contactless functionality.

The dispute concerned the legal treatment of contactless transactions and contractual information.

Issues

The CJEU considered:

whether the NFC functionality constituted a payment instrument;

low-value contactless transactions;

information obligations;

changes to framework contracts;

tacit consent;

limitations on blocking certain payment instruments.

Importance

The case demonstrates that technologically different payment methods can still fall within the EU payment-services framework.

It is particularly relevant to:

contactless cards;

NFC;

digital payment instruments;

payment authentication;

customer consent;

low-value transactions. (Infocuria)

11. Case 6 — T-Mobile Austria v Verein für Konsumenteninformation

C-616/11, CJEU, 9 April 2014

Although the defendant was a telecommunications company rather than a traditional bank, this case is relevant to technologically mediated payment services.

Facts

The dispute concerned payment methods and online banking/payment instruments.

Issue

The CJEU considered the meaning of a payment instrument under the Payment Services Directive and the charging of fees associated with particular payment methods.

Importance

The judgment helps establish that payment-service law focuses on the function and characteristics of the technological payment mechanism, rather than merely its physical form. (curia)

It is therefore useful for disputes involving:

online payment;

electronic payment mechanisms;

digital banking interfaces;

payment instruments;

transaction charges.

12. Case 7 — Home Credit Slovakia v Bíróová

C-42/15, CJEU, 9 November 2016

Facts

A bank provided consumer credit but the contract did not contain certain mandatory information, including information concerning the annual percentage rate.

Issue

The case concerned the legal consequences of failing to provide mandatory contractual information.

Decision

The CJEU accepted that national law could impose a serious consequence—loss of entitlement to interest and charges—where failure to provide required information prevented the consumer from assessing the extent of the contractual obligation, subject to proportionality. (Infocuria)

Banking technology relevance

Modern banking contracts are frequently concluded:

online;

through mobile applications;

through electronic interfaces;

using electronic documents;

through click-through acceptance.

The case supports the broader principle that digital delivery of a banking contract does not remove mandatory information obligations.

13. Case 8 — Tukowiecka / PKO BP

C-70/25 — pending as of September 2026

This is particularly relevant to modern phishing and digital-banking fraud.

The dispute concerns an unauthorised transaction following phishing. The Advocate General's March 2026 Opinion considered whether a bank can refuse the immediate PSD2 refund because it believes the customer acted with gross negligence. The Opinion concluded that the bank should initially refund the unauthorised transaction, subject to the Directive's fraud exception, while potentially seeking recovery later if gross negligence is established. The Opinion is not binding on the CJEU, and the case remained pending in the source reviewed. (Infocuria)

Importance

This case illustrates a major emerging issue:

Who bears the loss when sophisticated phishing defeats a customer's digital banking security?

The final judgment should be distinguished from the Advocate General's non-binding opinion.

14. Technology Failure as a Contractual Breach

Suppose:

A bank's online-banking platform crashes for 12 hours.

The customer cannot make a €500,000 payment before a contractual deadline and suffers a €50,000 loss.

The legal analysis may include:

Was the banking technology service contractually required to be available?

Was there an SLA?

Was the failure caused by the bank?

Was the failure caused by an outsourced IT provider?

Was there force majeure?

Did the customer have alternative means of payment?

Was the loss foreseeable?

Does the contract exclude consequential damages?

Is the exclusion enforceable?

What national law governs damages?

This is primarily a contract-law problem, supplemented where applicable by payment-services legislation.

15. Defective Payment Execution

PSD2 also addresses payment transactions that are:

non-executed;

incorrectly executed;

late;

incorrectly credited.

The Directive places significant responsibility on payment-service providers for correct execution and provides mechanisms for correction/refund. (Eur-Lex)

Example:

Customer instructs Bank A to transfer €100,000 → software sends €10,000 → recipient receives incorrect amount.

Potential issues include:

defective execution;

technical failure;

bank negligence;

restitution;

damages;

evidence from transaction logs.

16. Banking Software Failure

A bank may use software for:

transaction processing;

fraud detection;

interest calculation;

payment routing;

credit decisions;

account management;

compliance monitoring.

A software defect can create:

incorrect account balances;

duplicated transactions;

missing transactions;

wrong interest;

failed payments;

incorrect fees;

false fraud blocks.

The legal characterization depends upon the relationship.

Bank–customer

Usually primarily a banking contract/service-liability question.

Bank–software supplier

Potentially a technology supply/outsourcing contract.

Consumer–software producer

Depending on the circumstances, product-liability legislation may become relevant.

17. Outsourced Banking Technology

Modern banks frequently outsource technology to:

cloud providers;

payment processors;

cybersecurity companies;

software vendors;

data centres;

identity-verification companies.

This creates a chain:

Customer → Bank → Technology Provider → Cloud/Infrastructure Provider

A central civil-law question is:

Can the bank escape liability by arguing that the failure was caused by its technology supplier?

Generally, the answer cannot be determined merely by identifying the technical culprit.

The court must examine:

the banking contract;

applicable mandatory payment-services law;

outsourcing arrangements;

national agency/contract law;

statutory allocation of responsibility;

whether the bank remains responsible toward the customer.

PSD2 expressly recognises situations involving other payment-service providers and outsourced entities when allocating losses. (Eur-Lex)

18. Cyberattack Against Banking Technology

A cyberattack may produce:

unauthorised transactions;

loss of account access;

data destruction;

service interruption;

fraudulent transfers;

disclosure of financial information.

Possible defendants may include:

bank;

payment-service provider;

payment-initiation provider;

technology supplier;

cybersecurity provider;

cloud provider;

fraudster.

The customer's contractual claim against the bank is distinct from a potential tort claim against the unknown cybercriminal.

19. Phishing Liability

Phishing creates a difficult allocation-of-risk problem.

Example:

Customer receives a fake bank SMS → clicks a link → enters banking credentials → attacker transfers €20,000.

The court may examine:

Bank's side

authentication system;

fraud monitoring;

transaction-risk controls;

unusual transaction detection;

warnings;

blocking systems.

Customer's side

security of credentials;

response to warnings;

speed of notification;

degree of negligence.

PSD2 expressly requires the payment provider to provide evidence where fraud or gross negligence by the customer is alleged. (Eur-Lex)

20. Authentication Is Not Automatically Authorisation

This is a crucial examination point.

A bank may show:

“The correct password/OTP/device authentication was used.”

But the legal question can still be:

“Did the customer actually authorise the transaction?”

PSD2 expressly provides that recording use of a payment instrument is not, by itself, necessarily enough to prove authorisation or fraud/gross negligence. (Eur-Lex)

Eurobank Bulgaria is particularly useful on this distinction. (Infocuria)

21. Contactless and Low-Value Payments

Contactless technology creates special issues because certain low-value payment mechanisms may operate with reduced authentication requirements.

DenizBank is important because the CJEU considered how NFC functionality and low-value payment rules operate within PSD2. (Infocuria)

Potential disputes include:

stolen contactless card;

repeated low-value transactions;

blocking functionality;

customer information;

authentication;

liability allocation.

22. Mobile Banking

Mobile banking creates several possible failure points:

Customer device → mobile app → authentication → bank API → core banking system → payment network

A failure at any stage can potentially cause loss.

Examples:

app displays incorrect balance;

payment is duplicated;

payment fails but account is debited;

authentication system incorrectly rejects customer;

fraud detection blocks legitimate transaction;

API sends incorrect payment data.

The court must identify the precise contractual and statutory obligation that was breached.

23. Open Banking and Payment-Initiation Services

PSD2 permits payment-initiation services in which another provider initiates payments through the customer's account.

This produces a multi-party relationship:

Customer → Payment Initiation Service Provider → Account-Servicing Bank → Payee

PSD2 specifically addresses allocation of responsibility between these actors.

Where a payment-initiation provider is involved, the account-servicing provider generally remains subject to the immediate refund mechanism for unauthorised transactions, while the payment-initiation provider may have to compensate the account-servicing provider where liability is attributable to it. (Eur-Lex)

24. Data and Banking Technology

Banking technology also processes extensive personal and financial data.

Potential disputes may concern:

unauthorised disclosure;

inaccurate automated information;

cybersecurity breach;

unlawful processing;

excessive data retention;

profiling;

automated fraud decisions.

The contractual banking claim may therefore coexist with a GDPR/data-protection claim.

This can create multiple remedies:

Contractual damages + statutory payment refund + data-protection compensation

provided that the applicable legal requirements for each remedy are independently satisfied.

25. Bank's Duty to Maintain Secure Technology

The exact standard depends on applicable legislation, contract and national law.

Potential considerations include:

reasonable security;

strong customer authentication;

system monitoring;

fraud detection;

incident response;

access controls;

software updates;

business continuity;

cybersecurity safeguards.

A technology failure becomes legally significant where it constitutes a breach of a relevant contractual or statutory obligation and causes legally recoverable loss.

26. Force Majeure and Technology Failure

A bank may argue that a technology failure resulted from:

major cyberattack;

telecommunications outage;

cloud infrastructure failure;

power failure;

natural disaster;

war;

government intervention.

But “technical failure” does not automatically equal force majeure.

The court must examine:

contractual force-majeure clause;

foreseeability;

preventability;

control;

available backup systems;

statutory duties;

causation.

27. Limitation of Liability Clauses

Banking technology contracts may contain clauses limiting:

consequential damages;

loss of profit;

business interruption;

indirect losses.

However, enforceability depends on:

applicable national law;

consumer status;

unfair-terms legislation;

mandatory payment-service rules;

nature of the breach.

A bank cannot necessarily contract out of a mandatory EU statutory refund obligation.

28. Evidence in Banking Technology Litigation

Technology cases are highly evidence-dependent.

Important evidence includes:

Digital evidence

transaction logs;

authentication logs;

IP addresses;

device identifiers;

timestamps;

API logs;

server logs;

audit trails.

Cybersecurity evidence

malware reports;

phishing messages;

fraud alerts;

security notifications;

SIEM records;

incident-response reports.

Contractual evidence

banking agreement;

terms and conditions;

SLA;

security policy;

customer warnings;

payment instructions.

Expert evidence

Cybersecurity and IT experts may determine:

where the system failed;

whether authentication worked;

whether the transaction was technically executed;

whether the system was compromised;

whether reasonable security controls existed.

29. Causation

Causation may be particularly difficult because multiple technological failures can occur simultaneously.

Example:

Cyberattack → stolen credentials → bank authentication → fraudulent transfer → delayed detection → customer loss.

The court may have to separate:

Cybercriminal's conduct

from

bank's technological failure

from

customer's conduct.

This is why PSD2 contains specific statutory allocation rules rather than leaving every payment dispute entirely to ordinary tort principles. (Eur-Lex)

30. Contributory Fault

National civil law may recognise contributory negligence or equivalent concepts.

Possible customer conduct:

sharing OTP;

disabling security features;

ignoring warnings;

failing to report loss;

leaving a payment device unsecured.

However, statutory EU payment rules may limit the ability to rely on general national principles to circumvent the harmonised payment-liability regime. ZG v Beobank is important in this respect.

31. Remedies

Possible remedies include:

1. Refund

Especially for unauthorised payment transactions.

2. Account restoration

The account may have to be restored to the position it would have occupied without the unauthorised transaction. (Eur-Lex)

3. Damages

Available where the applicable law establishes compensable loss.

4. Reimbursement

For incorrect or defective payment execution.

5. Interest

Interest may be recoverable under applicable national law.

6. Injunction

Potentially available to prevent continued unlawful conduct.

7. Declaration

Court may determine whether the transaction was authorised or whether the bank breached its contractual obligations.

32. Difference Between Banking Technology Liability and Ordinary Banking Contract Liability

The technology dispute therefore usually requires both civil-law analysis and technical evidence.

33. Important Case Comparison

34. Practical Liability Test

A useful formula is:

T-F-A-C-D-R

T — Technology

What banking technology was involved?

F — Failure

What exactly failed?

A — Actor

Was the responsible party:

bank;

payment provider;

technology vendor;

cloud provider;

payment-initiation provider;

customer?

C — Contract/statute

Which contractual or statutory duty applies?

D — Damage

What loss resulted?

R — Remedy

Should the customer receive:

refund;

account restoration;

damages;

interest;

other relief?

35. Example

Suppose a customer uses mobile banking to transfer €50,000.

The bank's system records the payment twice because of a software error.

The customer loses €50,000 temporarily.

The legal analysis would examine:

whether the second transaction was authorised;

whether it was correctly executed;

whether there was a technical breakdown;

whether PSD2 applies;

whether the bank must refund/restore the account;

whether additional damages are available under national law;

whether the software supplier is liable to the bank;

whether the customer suffered additional foreseeable losses.

The bank cannot simply say:

“The software supplier caused it.”

The contractual relationship between the bank and customer must be analysed separately from the bank's recourse against its technology supplier.

36. Special Issue: Bank vs Technology Supplier

Suppose a bank outsources its mobile-banking platform.

The software provider's system fails.

Customer → Bank

The customer may have a contractual claim against the bank.

Bank → Software provider

The bank may have a separate contractual indemnity or damages claim.

Thus:

Outsourcing does not automatically transfer every customer-facing obligation from the bank to the technology supplier.

PSD2 itself recognises allocation of responsibility between payment-service providers and other entities in the payment chain. (Eur-Lex)

37. Special Issue: Banking Technology and Consumer Protection

Consumer protection is particularly significant because technological banking services can make contracts:

automated;

lengthy;

difficult to understand;

digitally accepted;

continuously modified.

Home Credit Slovakia demonstrates that mandatory information requirements remain legally significant even where the banking relationship is documented through modern contractual mechanisms. (Infocuria)

DenizBank similarly demonstrates that technological innovation does not place banking services outside the EU payment-services framework. (Infocuria)

38. Key Legal Principles

Principle 1

Technology does not eliminate contractual liability.

Principle 2

Authentication does not automatically prove authorisation. (Infocuria)

Principle 3

Unauthorised payment transactions receive a special statutory liability regime under PSD2. (Eur-Lex)

Principle 4

The payment-service provider may have the evidential burden concerning fraud or gross negligence. (Eur-Lex)

Principle 5

The customer also has statutory security and notification obligations. (curia)

Principle 6

Outsourcing technology does not necessarily eliminate the bank's obligations toward its customer.

Principle 7

Contractual damages and statutory payment-service remedies must be distinguished.

Principle 8

Digital banking disputes require both legal and technical evidence.

39. Conclusion

Banking technology service liability in Europe is an increasingly important area of civil law because banking services are now heavily dependent on software, electronic authentication, APIs, cloud infrastructure, mobile applications and automated payment systems.

The principal liability situations include:

unauthorised electronic payments;

phishing;

authentication failures;

contactless-payment disputes;

defective payment execution;

software errors;

mobile-banking outages;

API failures;

cybersecurity incidents;

outsourced IT failures;

incorrect digital records;

defective consumer-credit documentation.

The most useful authorities include ZG v Beobank, Eurobank Bulgaria, Veracash, DenizBank, DM & LR v Crédit Agricole, T-Mobile Austria and Home Credit Slovakia, with Tukowiecka representing an important pending development concerning phishing and immediate reimbursement.

Exam-ready rule

Where a banking technology service fails in Europe, liability is determined by identifying the technological failure, the applicable banking contract and mandatory EU payment-services rules, the responsible actor, the question of authorisation and authentication, causation and customer conduct, and the legally recoverable loss. For unauthorised payment transactions, the PSD2 liability regime is especially important because it establishes specific rules concerning refund, evidence, authentication, gross negligence and allocation of risk.