Short answer
Under the current , the payer's payment service provider normally refunds an unauthorised transaction immediately and no later than the end of the following business day. The payer may bear up to €50 for certain losses involving a lost, stolen or misappropriated instrument, and may bear all losses caused by the payer's fraud or intentional or grossly negligent breach of specified security and notification duties. The provider bears the burden of proving authentication and supplying evidence of fraud or gross negligence.
A scammer-induced payment is different. If the payer consented in the agreed form—even because of deception—the transfer may be authorised, outside PSD2's automatic refund. Recovery then depends on valid consent, correct execution, security and payee-verification duties, national law and possible recipient recovery.
Strong customer authentication (SCA) is important but not conclusive. Successful SCA does not itself prove legal consent, fraud or gross negligence. Conversely, where the payer's provider did not require SCA, PSD2 generally places the unauthorised-payment loss on the provider unless the payer acted fraudulently.
First classify the transaction: unauthorised or scam-authorised
Article 64 says a transaction is authorised only if the payer consented in the form agreed with the provider; without consent it is unauthorised. Examples include a criminal using stolen credentials or changing a payment without the payer's approval. A customer denying authorisation triggers PSD2's proof and refund architecture.
Authorised push-payment (APP) fraud is harder. A fraudster may impersonate a bank, supplier or relative and induce approval of the criminal's account and amount. Deception does not automatically negate payment-law consent. The question is whether the payer agreed through the specified procedure—not whether truth would have changed the decision.
The classification remains fact-specific. Malware changing the payee after approval, a forged mandate or a transaction outside the agreed consent procedure may be unauthorised. In Eurobank Bulgaria, decided under PSD2's predecessor, a formally regular notarised power of attorney was not enough:
the payment service provider must demonstrate that, by means of that power of attorney, the payment service user duly expressed agreement, in accordance with the procedure for giving consent agreed with that provider. —
The current Article 64 wording controls, but the case illustrates why authentication evidence and consent are distinct.
The default refund and the provider's proof burden
Once an unauthorised transaction is reported, Article 73 requires refund by the end of the next business day and restoration of the account. The provider may pause that immediate refund only where it has reasonable grounds to suspect payer fraud and communicates those grounds in writing to the relevant national authority. A payment-initiation service may ultimately reimburse the account provider, but the payer claims the immediate refund from the account-servicing provider.
Article 72 allocates proof:
the use of a payment instrument recorded by the payment service provider ... shall in itself not necessarily be sufficient to prove either that the payment transaction was authorised by the payer or that the payer acted fraudulently or failed with intent or gross negligence. —
The provider must prove authentication, accurate recording and absence of technical or service deficiency, and support alleged payer fraud or gross negligence. A PIN, app approval or device record is relevant, but not conclusive.
These consumer protections can differ for businesses. Under Article 61, a provider and a non-consumer may contract out of Articles 72 and 74 in whole or part and agree a different notification period. Member States may treat microenterprises like consumers. The contract and national implementation therefore matter for a corporate payer.
When the payer bears €50—or the whole loss
Article 74 permits a payer contribution of up to €50 where an unauthorised transaction results from a lost, stolen or misappropriated payment instrument. That contribution does not apply where the loss was undetectable before payment, absent payer fraud, or was caused by the provider's employee, agent, branch or outsourced entity.
The payer bears all unauthorised losses caused by acting fraudulently or by intentionally or grossly negligently failing to use the instrument according to objective and proportionate terms, notify loss or misuse promptly, or take reasonable steps to keep personalised security credentials safe. “Gross negligence” is more than ordinary carelessness: it is a serious breach of the required duty of care, assessed from all circumstances under national law. The provider still bears the evidential burden; possession of credentials alone is insufficient.
After notification, later use normally falls on the provider. So does loss where the provider failed to offer an always-available notification channel, except for payer fraud.
Notification: “without undue delay” and within 13 months
Article 71 contains two requirements. The customer must notify the provider without undue delay after becoming aware and, in any event, no later than 13 months after debit. The long-stop does not apply where the provider failed to make the required transaction information available.
In Veracash, interpreting the materially corresponding rule in the predecessor Directive, the Court confirmed that meeting the 13-month ceiling does not excuse undue delay:
the payment service user is, in principle, deprived of the right to obtain rectification ... if he or she did not notify ... without undue delay on becoming aware ... even though ... within 13 months after the debit date. —
For instrument misuse, loss of reimbursement generally requires intentional or grossly negligent delay. For successive transactions, Veracash confined the consequence to transactions culpably reported late. Customers should still report and block immediately and preserve evidence.
What strong customer authentication changes
PSD2 Article 97 generally requires SCA when a payer accesses an account online, initiates an electronic payment or performs a remote action risking fraud. The require at least two independent elements from knowledge, possession and inherence. For remote electronic payments, the authentication code is dynamically linked to the amount and payee; changing either must invalidate it. Defined exemptions include certain low-value, recurring, trusted-beneficiary and low-risk transactions.
SCA reallocates unauthorised-payment risk sharply:
Where the payer's payment service provider does not require strong customer authentication, the payer shall not bear any financial losses unless the payer has acted fraudulently. —
If the payee or its provider failed to accept SCA, it reimburses the payer's provider for the resulting damage. But completed SCA is not a reverse presumption that the payer authorised the transaction or was grossly negligent. Nor does SCA necessarily prevent APP fraud: dynamic linking can display precisely the criminal's account and the amount that the deceived customer consciously approves.
Verification of payee now adds a separate safeguard
added Article 5c to the SEPA Regulation. Before a credit transfer is authorised, the payer's provider must offer free verification matching the payee name and account identifier, across initiation channels. A mismatch warning must explain that authorisation may send funds to an account not held by the named payee.
If failed verification causes defective execution, the payer's provider must refund without delay and restore the account; the responsible other provider compensates it. Correct verification avoids liability based merely on an incorrect unique identifier, and a warned payer may still proceed.
For PSPs in euro-area Member States, the general compliance date was 9 October 2025. Non-euro Member States have until 9 July 2027, and specified payment and electronic-money institutions have later transitional dates. Verification therefore helps with name/account diversion, but does not create blanket reimbursement where the criminal controls an account bearing a matching name or the payer ignores a correct warning.
PSD3 and the proposed Payment Services Regulation
The proposed PSD3 and Payment Services Regulation would broaden prevention and add a conditional refund for specified bank-employee impersonation fraud. It is not current law. Negotiators reached provisional agreement on 27 November 2025 and ECON approved it on 5 May 2026, but Parliament's tracker—last updated 20 June 2026 and checked again on 31 July 2026—still described it as close to adoption and awaiting formal adoption. Announced PSR reimbursement is not yet an applicable entitlement.
Conclusion
For an unauthorised payment, the provider normally refunds first and proves any exception. The payer's exposure is narrowly capped unless fraud, intentional breach or gross negligence is established; missing SCA generally leaves the provider with the loss. Prompt notice remains essential even within 13 months.
For a fraudulently induced but authorised transfer, PSD2 does not promise the same refund. Ask whether consent was valid, execution matched it, payee verification was correct, and national law adds a remedy. SCA is a security process—not a finding of consent or blame—and future PSR protection cannot apply before enactment and commencement.
Sources
This article provides general legal information, not advice for a specific matter. Laws, facts and procedural deadlines may change the result. Follow the linked primary sources and obtain local advice before acting.