Failure at each lifecycle stage

Every payment passes through seven lifecycle stages, and each stage has its own failures, its own messages and its own recovery, and a business analyst must know all seven, because a failure at initiation needs a different fix from a failure at settlement. The seven stages are initiation, validation, screening, authorisation and debit, clearing and routing, interbank settlement, and beneficiary credit and notification, and the failure at each stage is taught below with a worked example, a message and a recovery. Source: European Payments Council, SEPA Credit Transfer Rulebook 2025, version 1. 1, effective 5 October 2025; ISO 20022, pain.002, pacs.002 and pacs.004. At initiation the failure is a bad instruction, and the recovery is a rejection to the customer before any money moves. The customer submits a pain.001 with an IBAN that is one digit short, or with an amount that exceeds the daily limit, or with a value date that is a bank holiday. Bank A validates the pain.001, finds the error, and returns a pain.002 with a reason code, such as BE01 for an incorrect account number, and the payment is never created. No debit is posted, no pacs.008 is sent, and the customer is told to correct the instruction and resubmit. A channel that accepts a bad instruction and lets it fail downstream has moved the failure to a more expensive stage. At validation and screening the failure is a hold or a rejection, and the recovery depends on which check failed. A validation failure, such as a missing mandatory field or a duplicate payment, is rejected with a pacs.002 status RJCT and a reason code, and the customer is told to correct and resubmit. A sanctions screening hit holds the payment for review, the customer is told the payment is under review, and the review must complete within the scheme deadline, or the payment is rejected. The three checks are different: validation is about the data, screening is about the parties, and fraud is about the behaviour, and each needs a different team, a different SLA and a different customer message. At authorisation and debit the failure is insufficient funds or a blocked account, and the recovery is a rejection with the funds untouched. The customer instructs EUR 25,000 but holds only EUR 20,000, so Bank A cannot debit, and the payment is rejected with reason code AM04 for insufficient funds, and the customer is told to fund the account. If the account is frozen by a court order or by compliance, the payment is rejected, and the customer is told to contact the bank, not given the reason for the freeze, because the reason may be confidential. A debit without a credit is a break, and it must be reversed the same day. At clearing and routing the failure is a misrouted or rejected message, and the recovery is a resend or a reroute. Bank A sends a pacs.008 to STEP2, but the message is rejected because a field is invalid under the scheme usage guidelines, so STEP2 returns a pacs.002. If the routing is wrong, because the beneficiary bank is not a participant in the chosen clearing system, the payment is rejected, and Bank A must reroute it through the correct system, or through a correspondent bank, and tell the customer the new value date. If the clearing system is down, the payments queue, and Bank A must hold them, tell the customer they are queued, and release them when the system recovers, with the value date moved to the recovery day. At interbank settlement the failure is a funding failure or a system outage, and the recovery is a queue, a default procedure or a loss sharing, under the system rules. Bank A owes a net EUR 5 million at the STEP2 cut-off, but its reserve account holds only EUR 3 million, so it cannot fund the settlement, and treasury must draw intraday credit from the central bank, using collateral, or the cycle will be at risk. A settlement failure is the most serious failure in payments, because it affects every payment in the cycle, not just one, and the Bank for International Settlements Principles for Financial Market Infrastructures set the standard for how it must be handled. At beneficiary credit and notification the failure is a closed, frozen or wrong account, and the recovery is a return. Bank B receives the pacs.008 for EUR 25,000, finds the supplier account closed, and returns the payment with a pacs.004. If the payment is credited to the wrong account, because the IBAN was correct but belonged to a different person, the recovery is a recall with a camt.056, and the beneficiary must agree to return the funds, which can take days. If the notification fails, because the customer contact details are wrong, the payment may have succeeded but the customer does not know, and the fix is to correct the contact data and to resend the notification, not to resend the payment. For a business analyst, product owner or subject matter expert, the test is to write the failure and recovery for each of the seven stages, for any payment product, with the message, the reason code, the posting and the customer message at each stage. Ask who is told, how quickly, and what the customer can do next. The ISO 20022 messages provide the evidence: pain.002 for initiation, pacs.002 for validation, clearing and settlement, pacs.004 for returns, and camt.056 for recalls, and the reason codes provide the cause, so the requirement must name the message and the code for each failure, or the operations team will not know how to handle it. Takeaway: initiation fails on bad data and is rejected by pain.002, validation and screening fail on data, parties or behaviour and are held or rejected by pacs.002, authorisation fails on insufficient funds with reason AM04, clearing fails on a bad message or a wrong route, settlement fails on funding or an outage under the system default procedure, and beneficiary credit fails on a closed account and is returned by pacs.004 with reason AC04. Further reading: European Payments Council, SEPA Credit Transfer Rulebook 2025, version 1. 1, effective 5 October 2025; ISO 20022, pain.002, pacs.002, pacs.004 and camt.056; Bank for International Settlements, Principles for Financial Market Infrastructures. Last reviewed 7 November 2026.