Payment exception management: rejects, returns and recalls
Most payments teams can describe the happy path in detail and the exception path only in anecdotes. That asymmetry is expensive, because the exception path is where the regulated deadlines live. A rejected file, a return two days later, a customer who mistyped one digit of an IBAN, a direct debit disputed seven weeks after the debit — each is a different legal animal, with a different owner, clock and liability outcome. This piece sets out the taxonomy, the deadlines binding each branch, and what changes as instant transfers and verification of payee reach payment and e-money institutions.
1. The five things people call “an exception”
The biggest source of confusion in exception handling is vocabulary. Five distinct events get the same name in operational conversation, and they diverge on the two questions that matter: has the money moved, and who is entitled to get it back.
| Event | When it happens | Who initiates | Governing rule |
|---|---|---|---|
| Refusal of a payment order | Before execution | The payer’s own provider | PSD2 Article 79 |
| Reject | Before settlement, on validation | Either provider, or the clearing layer | Scheme rules; PSD2 Article 79 notice |
| Return | After settlement, provider-driven | The payee’s provider | Scheme rules; PSD2 Articles 83 and 89 for timing and liability |
| Refund | Up to 8 weeks after debit | The payer, as a right | PSD2 Articles 76 and 77 |
| Recall | After settlement, no entitlement | The payer’s provider, on request | PSD2 Article 88(3) — a duty to try, not to succeed |
The distinction that catches firms out is the last two. A refund is a right the payer exercises unilaterally within a fixed window; a recall is a request for cooperation with no guaranteed outcome. A customer who sent money to the wrong IBAN is in the second category, however strongly they feel otherwise.
2. Refusing an order: the notice is the obligation
Under Article 79 of Directive (EU) 2015/2366, where a provider refuses to execute a payment order, it must notify the user of the refusal and — if possible — the reasons for it, together with the procedure for correcting any factual mistakes that led to the refusal, unless another Union or national law prohibits the disclosure. The notice must be provided or made available at the earliest opportunity and in any event within the Article 83 execution periods. A framework contract may allow a reasonable fee where the refusal is objectively justified.
Two consequences are routinely missed. The “how to fix it” step is a legal requirement, not a service nicety: a message reading only payment could not be processed is non-compliant even where the underlying decision is right. And Article 79(2) runs the other way — where all the conditions in the payer’s framework contract are met, the account-servicing provider shall not refuse an authorised order. A risk engine blocking on a rule not reflected in the contract creates exposure rather than removing it.
3. The clocks, in one place
Exception management is really deadline management. These are the periods fixed by PSD2, and they are the ones an operating model has to be built around.
| Clock | Length | Source |
|---|---|---|
| Credit to the payee’s provider | End of the following business day (one extra day for paper-initiated orders) | Article 83(1) |
| Agreed longer intra-Union period | Maximum 4 business days from receipt | Articles 83, 78 |
| User’s window to notify an unauthorised or incorrectly executed transaction | Without undue delay on becoming aware, and no later than 13 months after the debit date | Article 71(1) |
| Payer’s right to request a refund of a payee-initiated transaction | 8 weeks from the debit date | Article 77(1) |
| Provider’s window to refund or justify refusal | 10 business days from receiving the request | Article 77(2) |
Note what Article 71(1) does to the 13-month limit: it does not apply at all where the provider failed to provide or make available the transaction information required by Title III. A statement-delivery defect converts a closed dispute into an open one — which is why information-provision failures are exception-management incidents, not service issues.
4. The wrong IBAN: a duty to try, not to succeed
This is the highest-volume genuine exception in most euro payment books, and Article 88 resolves it in a way customers find counter-intuitive. An order executed in accordance with the unique identifier is deemed to have been executed correctly with regard to the payee that identifier specifies (Article 88(1)); where the identifier the user supplied was wrong, the provider is not liable under Article 89 for non-execution or defective execution (Article 88(2)).
What survives is a positive duty of effort. Under Article 88(3) the payer’s provider shall make reasonable efforts to recover the funds and the payee’s provider shall cooperate, including by communicating all relevant information for collection. Where collection proves impossible, the payer’s provider must, on written request, hand over the information it holds that the payer needs to pursue a claim.
Worked example. A customer instructs €9,400 and transposes two digits; the IBAN is valid, passes the check digit and belongs to an unrelated person at another provider. The order settles. Facts to rule: the identifier came from the user, so Article 88(2) removes Article 89 liability — no automatic refund. What the analyst does: open a recovery case, evidence the reasonable-effort standard with a dated request to the receiving provider under Article 88(3), and log the response. Outcome A — the beneficiary consents, funds return, no liability event. Outcome B — no consent: the provider does not owe the money but does owe the information, and must respond to a written request with what it holds so the customer can pursue a claim. Say that at the outset rather than letting the customer expect a refund.
5. When the money genuinely did not arrive
Where the identifier was correct and the transaction was not executed, or was executed defectively or late, Article 89 allocates liability by proof of receipt. The payer’s provider is liable for correct execution unless it can prove that the payee’s provider received the amount in accordance with Article 83(1) — at which point liability shifts to the payee’s provider.
The remedies belong in the correction pipeline, not in manual handling. The liable payer-side provider must refund without undue delay and restore the account to its prior state, with the credit value date no later than the debit date. A liable payee-side provider must immediately place the amount at the payee’s disposal, again value-dated no later than the date it would have been credited. Where a payment initiation service provider is in the chain, Article 90 puts the refund duty on the account-servicing provider first. Article 93 preserves the escape for abnormal and unforeseeable circumstances.
6. What instant transfers change — and the date that matters for EMIs and PIs
Regulation (EU) 2024/886, adopted 13 March 2024, published in the Official Journal on 19 March 2024 and in force from 8 April 2024, inserts Articles 5a to 5d into Regulation (EU) No 260/2012. Article 5a requires providers that send and receive euro credit transfers to send and receive instant ones — executed in under ten seconds, twenty-four hours a day, on any calendar day. Article 5c requires a verification-of-payee service: a check of the payee name against the identifier, with any discrepancy notified before the payer authorises. Article 5d replaces per-transaction screening for in-scope transfers with verification of a provider’s own users against EU targeted financial restrictive measures at least once every calendar day, plus an immediate re-check after any new or amended designation.
The compliance dates are staggered, and the row payments firms most often get wrong is their own. Euro-area providers generally had to receive from 9 January 2025 and send from 9 October 2025, with verification of payee also from 9 October 2025. Euro-area electronic money institutions and payment institutions have until 9 April 2027 for both directions — a consequence of the same Regulation amending Directive 98/26/EC to open payment-system access to them. Non-euro-area providers run to 9 January 2027 to receive and 9 July 2027 to send, with verification of payee from 9 July 2027.
Worked example. A euro-area e-money institution reads “9 October 2025” in a summary and books a programme to send instant transfers by then. Facts to rule: as an EMI it sits in the 9 April 2027 row. What the compliance officer does: re-baseline to April 2027 and split the two workstreams the single date was hiding — scheme and settlement access under the amended Settlement Finality Directive, with its long lead time and external dependencies, and the exception-handling redesign, which has neither. Outcome: head-room on access, and the return paths tested against a real date rather than a misread one.
The exception consequence of a ten-second rail is structural. Every control that used to run in a batch window must now answer inside the execution window or fail the transfer, and a verification-of-payee mismatch becomes a high-volume, pre-authorisation exception type no legacy queue was designed to hold — a customer-communication problem as much as a systems one, since the payer must be told what the mismatch is and still be able to proceed.
7. Questions that come up
Can we charge for recovering funds sent to a wrong IBAN?
Yes, where agreed with the user. PSD2 permits charges for the Article 88(2) recovery case, requiring them to be agreed and to be appropriate and in line with the provider’s actual costs.
Does the 8-week refund right apply to credit transfers?
No. Articles 76 and 77 cover authorised transactions initiated by or through a payee — the direct-debit case. A push credit transfer is not refundable by that route; it falls under Article 88 recovery or, if incorrectly executed, Article 89.
Does verification of payee only apply to instant transfers?
No. The Article 5c obligation attaches to credit transfers generally, not only instant ones — which is why it cannot be scoped as a sub-task of an instant-payments project.
If the customer proceeds despite a name mismatch, where does liability sit?
The identifier logic in Article 88 still governs: an order executed in accordance with the unique identifier is deemed correctly executed. The warning does not transfer the loss to the provider, but the evidence that it was given, and what it said, becomes the material record — retain it as a control artefact.
What if we spot an incorrectly executed payment before the customer does?
Article 71 governs the user’s claim window, not the duty to correct. Where Article 89 liability applies, the refund and value-date restoration are owed without undue delay; waiting for a complaint is not defensible.
8. What to do, today
- Map every internal status code to exactly one of refusal, reject, return, refund and recall — ambiguity is what makes the deadlines unmanageable.
- Audit refusal messages against Article 79: does each carry a reason where lawful, and the procedure for correcting factual mistakes?
- Test value dating on the correction path. Refund to the original debit date, and prove it in the ledger rather than the policy.
- Instrument the 10-business-day Article 77(2) clock as a hard measure, not a service target, and alarm it before it expires.
- Check transaction-information delivery is complete, because a Title III gap disapplies the 13-month limit in Article 71(1).
- If you are a euro-area EMI or PI, re-baseline the instant-payments plan on 9 April 2027 and split scheme access from exception redesign.
Related: Verification of payee under the IPR · Sanctions screening at instant-payment speed · Unauthorised payment transactions · What is settlement finality
