PSD2 Fraud Redress: How Payment Institutions Must Handle Unauthorised Transactions

Why PSD2 complaint handling requires a dedicated playbook

Payment complaints are not ordinary service complaints with a different label. Under PSD2, the complaint timeline, the reimbursement logic, and the legal test for unauthorised transactions are all governed by payment-services law rather than a generic consumer-protection framework. That distinction changes the operating model in three ways that most firms underestimate.

First, the response deadline is shorter. Article 101 gives PSPs 15 business days, not the 8 weeks familiar from the UK's DISP framework or the looser timelines in some national transposition rules. Second, there is a separate and earlier duty to reimburse the payer for an unauthorised transaction, usually by the end of the next business day, which runs independently of the complaint investigation. Third, the liability allocation in Articles 73 and 74 depends on whether Strong Customer Authentication was required and whether it was actually applied, making SCA evidence a first-order complaint artefact rather than a background technical detail.

Together, these three differences mean that a payment complaint cannot be managed through a single sequential queue. Teams need parallel tracks: one for the complaint narrative, one for the refund decision, and one for the liability and SCA analysis.

Scope: Who does PSD2 apply to?

PSD2 (Directive 2015/2366) applies to payment service providers operating within the European Union and the European Economic Area. That includes credit institutions offering payment accounts, payment institutions authorised under PSD2, electronic money institutions (EMIs) to the extent they provide payment services, and account information and payment initiation service providers (AISPs and PISPs).

In the United Kingdom, the Payment Services Regulations 2017 (PSRs 2017) transposed PSD2 into domestic law before Brexit. UK-authorised payment firms and EMIs remain subject to the PSRs 2017, which carry substantially the same complaint-handling, refund, and SCA obligations. References to specific PSD2 articles in this guide correspond to the equivalent PSRs 2017 provisions for UK-regulated firms.

The scope question matters for complaint teams because it determines which complaints fall under the PSD2 regime and which are governed by general consumer-complaint rules. A firm that provides both payment services and non-payment products must route complaints to the correct playbook at triage, not at the drafting stage.

Step 1: Complaint receipt and the Article 101 clock

The complaint clock starts when the PSP receives the complaint, not when a fraud team reviews it, not when the complaint is assigned to an analyst, and not when the customer provides additional information. Article 101 is explicit: the clock runs from receipt.

For complaint operations, the practical effect is that intake must be timestamped and that any internal routing between fraud, payments, and complaints must happen within the first day or two rather than consuming the first week.

• Record the exact date and time the complaint was received, regardless of channel.
• Treat receipt as a firm-wide event, not a team-specific one: if the complaint lands in a general inbox, the clock still starts.
• Route the complaint to the payment-complaints workflow immediately, tagging it with the relevant PSD2 articles.
• Send an acknowledgement to the complainant confirming receipt and the expected timeline.

Step 2: The 15-business-day response target

Article 101 requires PSPs to provide a final response within 15 business days of complaint receipt. This is not a soft target or a service-level aspiration. It is a regulatory deadline that national competent authorities can enforce.

Fifteen business days is roughly three calendar weeks. That leaves limited room for back-and-forth with the customer, requests for third-party evidence, or cross-team deliberation. The investigation must therefore begin on day one, not after a preliminary review period.

• Calendar the 15-business-day deadline at intake and surface it on every case view.
• Identify the required evidence (authorisation logs, SCA records, device data, customer correspondence) within the first two days.
• Run the refund assessment in parallel with the broader complaint investigation so the two do not block each other.
• Draft the final response in stages rather than starting from scratch on day 12.

Step 3: Exceptional circumstances and the 35-day extension

Article 101 permits an extension to 35 business days only where the PSP cannot provide a final response within 15 business days due to reasons beyond its control. The bar is high. Routine investigation complexity, internal staffing constraints, and ordinary information-gathering delays do not qualify.

When an extension is justified, the PSP must send a holding reply before the 15-business-day deadline. That reply must state the reasons for the delay and specify a deadline by which the complainant will receive the final response. The outer limit is 35 business days from the original complaint receipt date.

• Use the extension only for genuinely exceptional situations: third-party dependency, cross-border evidence requests, or regulatory referrals that the PSP cannot accelerate.
• Document why the specific case qualifies for an extension and what remains outstanding.
• Send the holding reply before the 15-business-day deadline, not on the deadline.
• Track extension usage across the complaint book so that recurring extensions trigger a process review.

Step 4: Unauthorised transactions and the Article 73 refund duty

Article 73 creates a refund obligation that operates independently of the complaint process. Where a payment transaction was not authorised, the payer's PSP must refund the full amount of the transaction immediately, and at the latest by the end of the business day following the day on which the PSP became aware of or was notified about the unauthorised transaction.

This D+1 refund deadline means the analyst cannot wait for a complete fraud investigation before making the refund decision. The assessment is binary: was the transaction authorised or not? If it was not authorised, the refund must go out unless the PSP has reasonable grounds to suspect fraud by the payer and has communicated those grounds to the relevant competent authority in writing.

Suspicion of third-party fraud (for example, that a fraudster compromised the payer's credentials) is not a basis for withholding the refund. The fraud exception in Article 73 applies only where the PSP suspects the payer acted fraudulently.

• Separate the refund decision from the broader complaint narrative. They run on different timelines and different legal tests.
• Check whether the PSP has documented, competent-authority-notified grounds to suspect payer fraud before withholding any reimbursement.
• Store the transaction logs, device fingerprints, and authentication records in the complaint file for later audit.
• Record the exact timestamp of the refund so that D+1 compliance is demonstrable.

Step 5: Liability framework (Article 74)

Article 74 determines how much of the financial loss the payer may bear. The default position is that the payer's liability for unauthorised payment transactions is limited to a maximum of EUR 50. That cap applies where the payer's personalised security credentials were lost, stolen, or misappropriated and the payer was not acting fraudulently.

The payer bears all losses only in two situations: where the payer acted fraudulently, or where the payer failed, with intent or gross negligence, to comply with the obligations to keep personalised security credentials safe and to notify the PSP without undue delay upon becoming aware of loss, theft, or misappropriation.

Crucially, Article 74(2) provides that where the PSP does not require Strong Customer Authentication, the payer shall not bear any financial losses unless the payer acted fraudulently. This makes the SCA record a decisive factor in liability allocation.

The table above simplifies the interaction between Articles 73 and 74. In practice, the complaint analyst must assess both the authorisation status and the payer's conduct, and then check whether SCA was required and applied. That three-part assessment drives the liability outcome.

Step 6: SCA and evidence requirements

Strong Customer Authentication is the pivot point for most PSD2 liability disputes. SCA requires at least two independent elements from three categories: knowledge (something the payer knows, such as a PIN or password), possession (something the payer has, such as a mobile device or hardware token), and inherence (something the payer is, such as a fingerprint or facial recognition).

Where SCA was required and the PSP failed to apply it, the payer does not bear any financial loss unless the payer acted fraudulently. This makes the SCA evidence trail one of the first items a complaints team should request from the payments or fraud operations team.

The complaint file should contain at minimum:

• The authentication method applied to the disputed transaction (or confirmation that no SCA was applied).
• The SCA exemption relied upon, if any, with the legal basis and the risk assessment supporting it.
• Device and session data linking the authentication event to the disputed payment.
• Any relevant transaction-risk analysis or fraud-scoring output that informed the exemption or authentication decision.

Step 7: Structuring the final response

A PSD2 complaint response must do more than summarise what happened. It must classify the transaction, explain the evidence basis, allocate liability with reference to the legal framework, and set out the redress or corrective action. Regulators and ombudsman bodies will assess the response against these elements, not just its tone.

A well-structured final response should contain seven elements:

1. A clear statement of the complaint as the PSP understood it.
2. A classification of the disputed transaction: authorised, unauthorised, or disputed on mixed facts.
3. The evidence the PSP relied on, including SCA records, device data, and customer correspondence.
4. The liability allocation with reference to Articles 73 and 74 (or the equivalent PSRs 2017 provisions).
5. The refund amount and timing, or the specific grounds for declining a refund.
6. Any corrective action the PSP has taken or will take.
7. The customer's right to escalate to the relevant ADR body or competent authority, with contact details and applicable time limits.

Each element should be written in plain language. The customer should be able to understand the outcome, the reasoning, and the next steps without needing to look up the legislation.

Step 8: Dispute escalation and ADR

If the customer remains dissatisfied after the final response, PSD2 and the national transposition rules provide for escalation to an alternative dispute resolution body or the relevant competent authority. The specific ADR route depends on the jurisdiction and the type of PSP.

In the United Kingdom, payment services complaints can be referred to the Financial Ombudsman Service (FOS) if the firm is FCA-regulated. In EU member states, the route varies: some countries use a financial ombudsman, others use a general consumer ADR body, and some rely on the competent authority itself. FIN-NET, the cross-border financial dispute resolution network, connects national ADR bodies across the EEA and can assist where the customer and the PSP are in different member states.

• Include the relevant ADR body's name, contact details, and referral time limits in the final response.
• Where the customer and the PSP are in different jurisdictions, reference FIN-NET as an available coordination mechanism.
• Retain the full complaint file, including all evidence, analysis, and correspondence, for at least three years after the complaint is closed or longer if national law requires.
• Monitor ADR outcomes for recurring themes that indicate systemic issues in the PSP's payment controls or complaint handling process.

PSD2 complaint handling at a glance

What mature PSP complaint teams monitor

The strongest PSP complaint teams treat complaint data as a live risk signal rather than a back-office reporting obligation. Five patterns in particular warrant standing monitoring:

1. Extension frequency. If more than a small fraction of PSD2 complaints require the 35-business-day extension, the root cause is usually a slow investigation process rather than genuinely exceptional circumstances. Track extension rates monthly and investigate spikes.

2. D+1 refund compliance. The Article 73 refund deadline is one of the most auditable PSD2 obligations. Track the percentage of unauthorised-transaction refunds that hit the D+1 target, and treat any miss as an incident requiring root-cause analysis.

3. SCA evidence gaps. Complaints where the SCA record is incomplete or ambiguous are the ones most likely to result in adverse ADR outcomes. Monitor how often the complaints team has to request SCA evidence more than once, and feed that signal back to the payments or authentication team.

4. Recurring authentication disputes. Clusters of complaints about the same transaction type, the same merchant category, or the same authentication flow often indicate a control weakness rather than isolated customer incidents. Route these clusters to fraud governance for review.

5. ADR reversal rate. Track outcomes where an ADR body or ombudsman overturns the PSP's complaint decision. A rising reversal rate is one of the clearest indicators that the complaint handling process, the liability analysis, or the evidence standards are not meeting the bar.

Complaint handling under PSD2 is not a stand-alone response function. It connects directly to fraud governance, payment operations, and customer-outcome monitoring. Teams that treat it as an integrated discipline rather than a back-office queue will produce better regulatory outcomes and stronger customer relationships.