APP Fraud and PSP Liability for Merchant Reserves

This article is about authorised push payment (APP) fraud, where a customer personally sends money to a fraudster. We explain how such a payment differs from an unauthorised one, who reimburses the loss in the EU and the UK, when a payment service provider (PSP) may withhold a merchant’s settlement funds and what happens when stolen money lands in an honest seller’s account.

Checked on 1 November 2026.

What APP fraud is and who bears the loss

A fraudster may impersonate a bank, business partner, seller or investment firm. The customer creates and authorises the payment order but does so because of deception. This differs from an unauthorised transaction. In the EU, PSD2 contains separate refund rules for unauthorised and incorrectly executed payments; those rules do not automatically cover every transfer that a customer personally authorised after being deceived.

An assessment should identify who initiated the payment, which mechanism was used, what warnings the customer received, what the payer’s and recipient’s PSPs did, and whether the country has a dedicated APP reimbursement scheme. A payment system may set rules and provide settlement infrastructure, but that does not itself make the operator liable to reimburse the loss.

APP fraud or an unauthorised payment

Every dispute about getting money back starts with one question. Who consented to the payment? Under Article 64 PSD2 a payment is authorised if the payer consented to it in the form agreed with the PSP. If the customer entered the details and confirmed the transfer, the payment is authorised, even if a fraudster talked them into it. If a fraudster stole access to the bank and made the transfer without the customer, the payment is unauthorised. This split decides which rules apply.

Unauthorised paymentAPP fraud
Who makes the paymentThe fraudster, without the payer’s consentThe payer, after being deceived
Refund in the EUThe payer’s PSP refunds the amount no later than the end of the next business day after notification. An exception applies where the PSP has reasonable grounds to suspect fraud by the payer and reports them in writing to the authority (Article 73 PSD2)No general refund duty under PSD2
Payer’s share of the lossUp to EUR 50, or the full amount where the payer acted fraudulently or with gross negligence (Article 74 PSD2)Depends on the national scheme, the PSP’s policy and the facts
United KingdomSimilar rules in regulations 76 and 77 of the Payment Services Regulations 2017Mandatory reimbursement for Faster Payments and CHAPS within the scheme

Invoice redirection

A supplier’s email is hacked and the company receives an invoice with new bank details. The accountant pays it. The payment is authorised, so this is APP fraud. The refund rules for unauthorised payments do not help here.

A call from “the bank’s security team”

A fraudster poses as a bank employee and persuades the customer to move savings to a “safe account”. The customer makes the transfer personally. These are the cases the PSR/PSD3 reform aims to cover with a separate refund duty where the fraudster impersonates the PSP.

Investment scam

The customer sends money to a fake investment platform. Often the money first goes to the customer’s own account at a crypto exchange and from there to the fraudsters. The UK scheme does not cover a payment to an account the customer controls, so the dispute moves to the next link in the chain.

The customer shared an SMS code

The fraudster obtained a one-time code and made the transfer personally. This is an unauthorised payment. The PSP may argue gross negligence by the customer, but it is the PSP that has to prove it. A record that the payment instrument was used is not enough on its own (Article 72 PSD2).

How the EU and UK rules differ

EU: distinguish current rules from the upcoming reform

PSD2 primarily governs unauthorised and incorrectly executed payments. The Instant Payments Regulation (EU) 2024/886 introduced Verification of Payee (VoP), a check comparing the payee’s name with the account identifier. PSPs in euro-area Member States have had to offer this service since 9 October 2025; later deadlines apply in non-euro Member States. If the payer is warned of a mismatch and still confirms the payment, the payer’s PSP is generally not liable for the transfer to an unintended payee. The exact conditions should be checked against the Regulation’s text. VoP can help prevent errors and some fraud, but it is not a general promise to reimburse every deceived transfer.

The PSR/PSD3 reform adds anti-fraud measures, including PSP liability for inadequate protections and rules for impersonation of a PSP. A political agreement was reached in November 2025; the Council had already agreed its negotiating mandate in June 2025. On impersonation fraud, the Council position keeps the refund duty for cases where the fraudster impersonates the PSP itself. As of this article’s review date, the acts have not been published in the Official Journal, so these provisions should not be treated as law already in force.

United Kingdom: a dedicated scheme for specified transfers

Since 7 October 2024, mandatory reimbursement has applied to eligible domestic Faster Payments and CHAPS transfers. It covers consumers, microenterprises and charities that meet the scheme criteria, not every business. The sending PSP reimburses eligible claims, normally within five business days; in specified cases, assessment may take up to 35 business days. The cap is £85,000 per claim. An excess of up to £100 may apply, but not to a vulnerable claimant.

A claim must be made within 13 months. Exceptions include first-party fraud and gross negligence under the consumer standard of caution. The scheme excludes, among other things, international payments, card payments, Bacs and SWIFT transfers, other payments outside FPS and CHAPS, civil disputes and payments for unlawful purposes. The receiving PSP generally reimburses the sending PSP for 50% of the reimbursement paid. Pay.UK and the CHAPS operator provide system infrastructure and rules; they do not bear that share of the reimbursement loss.

Merchant reserves and withheld settlement funds

A reserve is part of the settlement funds due to a merchant that a PSP or acquirer temporarily withholds to cover refunds, chargebacks and other contractual liabilities. It may be a fixed amount, a percentage of turnover or a rolling reserve, where part of each settlement is held for a defined period.

Chargeback risk may rise after delivery delays, refunds, a spike in complaints or suspicious transactions. Acquirers may also respond to payment-network monitoring programmes, such as Visa’s Acquirer Monitoring Program (VAMP) and Mastercard programmes for excessive chargebacks and fraud. Networks set thresholds and measures for acquirers; a specific merchant reserve is usually grounded in the merchant’s agreement with its PSP or acquirer.

Check the agreement: what event permits the reserve, how the amount is calculated, which transactions it covers, when it is reviewed and what triggers release. The word “reserve” does not justify an indefinite freeze of all proceeds by itself. A hold needs a contractual or legal basis; the assessment depends on the jurisdiction and facts. A merchant reserve also does not replace a separate PSP reimbursement duty to a victim of APP fraud.

How a reserve works in practice

The law says very little about merchant reserves, so the contract and the acquirer’s practice decide most things. What follows is our practical experience, not a requirement of any legal act.

What usually triggers a reserve

A rising share of chargebacks and refunds, a sharp jump in volume or average ticket, new high-risk products or markets, a long gap between payment and delivery (pre-orders, travel, subscriptions), a warning from a card network, the merchant’s financial difficulties or termination of the agreement.

What the agreement says

The PSP’s right to set and change a reserve, its form (a percentage of each payout, a fixed amount or collateral before go-live), the holding period, a right of set-off against the merchant’s debts and the notice procedure. The holding period is often tied to the time during which cardholders can still dispute a payment.

How to reduce or lift a reserve

Show data, not promises. Chargeback statistics, delivery confirmations and a clear refund policy all help. 3-D Secure, a recognisable descriptor on the customer’s statement and quick responses to complaints lower the risk. Instead of a rolling reserve, a bank guarantee or fixed collateral can be offered.

What to agree before signing

A cap on the reserve, the calculation formula, a review schedule, the notice period before a reserve is introduced and a release schedule after termination. Once a reserve is already in place, these terms are much harder to negotiate.

When APP fraud and a hold meet

The two topics of this article meet when money stolen from a victim lands in a merchant’s account. For example, a fraudster buys goods or crypto and has the victim pay the seller directly. Or the victim personally sends money to a fake “platform” account opened with a PSP. After the complaint, the victim’s bank contacts the receiving PSP, which then holds the funds in the recipient’s account. To an honest merchant this looks like a sudden freeze with no explanation.

United Kingdom

Since 7 October 2024 the receiving PSP generally bears half of the reimbursement, so it has a direct interest in checking incoming payments. Since 30 October 2024 the payer’s PSP may delay an outbound payment by up to 4 business days where it has reasonable grounds to suspect fraud by someone other than the payer (regulation 86(2A)–(2D) PSRs 2017). It must tell the payer about the delay no later than the end of the next business day. For incoming funds, regulation 96(2) protects the receiving PSP from liability where crediting the funds would breach proceeds of crime legislation.

European Union

The EU has no dedicated APP reimbursement scheme yet. The basis for a hold usually comes from anti-money laundering (AML) law. An obliged entity must not carry out a transaction it suspects to be linked to criminal proceeds until it has reported it to the financial intelligence unit (Article 35 of Directive (EU) 2015/849). The financial intelligence unit may suspend the transaction (Article 32(7)).

How such a hold differs from a reserve

A reserve rests on the contract, and the PSP usually explains how it is calculated. An AML hold rests on the law, and the PSP often cannot disclose the reason because of the prohibition on tipping off the customer (Article 39 of Directive 2015/849). A merchant should keep buyer data and proof of delivery in advance and, if funds are frozen, ask which funds exactly are held and which documents would help release them. This matters most for crypto exchangers and marketplaces, where scam victims often send money.

Safeguarding is a separate regime

Safeguarding protects certain customer funds received to execute payment transactions or issue electronic money, including if the institution becomes insolvent. In the UK, payment institutions are subject, among other provisions, to regulation 23 of the Payment Services Regulations 2017; electronic money institutions are subject to regulations 20–22 of the Electronic Money Regulations 2011. Since 7 May 2026, additional FCA requirements include CASS 10A and CASS 15. Safeguarding may be voluntary for small payment institutions and small e-money institutions under the applicable conditions.

Safeguarding is not a general right to freeze merchant settlement. Protected customer funds must be distinguished from contractual settlement funds due to a merchant.

Illustrative example

An acquirer introduces a reserve after chargebacks rise

An online store is told that part of its settlements will be held for 120 days. The agreement may permit a reserve to cover expected liabilities. The merchant should request the contract clause, calculation method, affected transactions and review date. If the acquirer refers to Visa or Mastercard monitoring, the merchant can ask for confirmation of the programme status and measures applied. If the hold is not explained by the agreement or continues beyond its terms, the merchant may use the complaints process, arbitration or court proceedings depending on the contract and local law.

Practical steps

  1. For a victim of APP fraud

    Notify the PSP immediately, ask it to register the claim, preserve confirmations and messages, and check which scheme and filing deadline apply.

  2. For a merchant facing a hold

    Review the agreement and notice; request the basis, reserve calculation, affected transactions, review date and release conditions in writing. Keep delivery, refund and customer communication records.

  3. If the decision is disputed

    Request a reasoned response and file a formal complaint. Access to a financial ombudsman depends on the country and business size. Larger merchants may need to use contractual dispute procedures, arbitration or court proceedings.

FAQ

Must a PSP refund every transfer sent to a fraudster?

No. Eligibility depends on the country, date, payment route, local scheme and the facts of the case.

Can a PSP hold all of a merchant’s settlement funds?

There is no universal answer. Check the contractual basis, amount, duration, review procedure and local legal limits.

Does a reserve mean the merchant has been found to commit fraud?

No. A reserve reflects the PSP’s or acquirer’s risk management and is not, by itself, proof of misconduct.

Why did the PSP freeze the funds without explaining why?

If the hold is linked to a suspicion of money laundering, the PSP often cannot disclose the reason because of the prohibition on tipping off. Ask which funds are held and which documents would help release them.

LegalBit perspective

APP reimbursement and merchant reserves concern different relationships. The first is determined by local law and the payment scheme; the second by the acquiring agreement, applicable network rules and national limits. For PSPs and merchants, clear hold criteria, a documented calculation and a defined review period are central.

See also: How banks block fintech startup accounts.

This topic is our service

Learn more about how we help payment and fintech companies: