SEPA exceptions checkpoint
Rejects, returns, and recalls: can you tell them apart, pick the right one for a live scenario, read a return message, and explain what Verification of Payee does and does not do?
QUESTIONS AS TEXT
Q1. What is the cleanest way to keep reject, return, and recall apart?
Answer: A: A reject stops the payment before settlement; a return sends settled funds back on the beneficiary side's initiative; a recall is the ordering side asking for settled funds back — a request, not a guarantee.
The two questions that sort every R-transaction are: had the payment settled yet, and who is acting? Before settlement, the payment can still be rejected and no funds have to move back. After settlement, the beneficiary side can return funds of its own accord, while the ordering side can only request them back with a recall — and the answer to a recall may be no.
Q2. Bank Alfa, the debtor agent on an SCT that settled two days ago, receives this fictional fragment. What happened?
Answer: A: The beneficiary side has returned the settled funds as a pacs.004, citing reason code AC04 — the account is closed. Bank Alfa should apply the returned amount and inform its customer.
PmtRtr is the root of a pacs.004 payment return: settled funds moving back, always referencing the original transaction. The reason code — here AC04, from the ISO 20022 external code sets, indicating a closed account — tells the receiving bank why, so operations can post the return and give the customer a usable answer rather than a mystery credit. All references in the excerpt are fictional.
Q3. Diagnose the situation and pick the correct instrument for Bank Alfa.
Answer: A: Send a camt.056 recall for the duplicate transaction, citing the duplicate as the reason, and wait for either a pacs.004 return or a camt.029 response from the beneficiary side.
A duplicate that settled is the textbook recall case: the SCT rulebook defines a recall procedure for situations such as duplicates, technical errors, and fraud, initiated by the debtor agent within the scheme's time limit. The crucial discipline is treating the camt.056 as an open question — the case is only closed when a pacs.004 brings the funds back or a camt.029 explains why they are not coming.
Q4. An SCT Inst payment is rejected by the beneficiary PSP within the scheme's time limit because the account is closed. What does the paying customer experience?
Answer: A: A near-immediate failure notification: the transaction never completes, no funds reach the beneficiary side, and there is no return to wait for.
The compressed timeline is the whole point of instant rejection: the debtor agent receives the negative pacs.002 before it confirms anything to its customer, so failure is communicated in seconds. This keeps the exception cheap — no funds in flight, no return leg, no investigation — provided the originating bank's channel actually surfaces the failure clearly to the customer.
Q5. What does Verification of Payee (VOP) actually do?
Answer: A: Before the payer confirms a credit transfer, the payee's name is checked against the account identifier at the payee's PSP, and the payer is shown the outcome — such as a match, close match, or no match — before deciding whether to proceed.
VOP attacks two problems at once: honest mistakes (a mistyped IBAN sending rent to a stranger) and impersonation fraud (a criminal supplying their own account under a trusted name). By checking name-against-account before the payment is confirmed, it moves the warning to the only moment it can still help. It does not guarantee the payment, replace screening, or remove the value of recall procedures when things go wrong anyway.