Payment versus settlement

A payment and a settlement are related but not identical. A payment is the instruction and the customer facing commitment to move value. Settlement is the actual movement of value between banks, usually in central bank money, that makes the payment final and irrevocable. In many domestic systems, a customer sees the payment as complete when the money appears in the beneficiary account, but the interbank settlement behind it may happen later, through a clearing system, a netting process, or a real time gross settlement system. Until settlement is final, there is a residual risk that the payment could be unwound or that a bank could fail before settling. This gap between payment and settlement is why payment systems distinguish between customer account entries and interbank positions. A bank may credit a beneficiary account intraday on the basis of a payment instruction, taking on intraday credit risk against the sending bank, and then settle later through the central bank. In a real time gross settlement system, each payment settles individually in central bank money as soon as it is processed, so there is no netting risk, but liquidity needs are higher. In a deferred net settlement system, payments are netted and settled at set times, which saves liquidity but creates a window of exposure. Both models are valid, and the choice affects cost, risk, and speed. For a business analyst, the practical lesson is to never confuse a customer credit with final settlement. When you write requirements for payment finality, cut off times, or value dating, you must state whether you mean the customer account entry, the clearing, or the central bank settlement. A payment that is credited but not yet settled can still be affected by an operational failure, a recall, or a bank default, depending on the scheme rules. Clear language about finality protects the bank, the customer, and the analyst, and it is essential when you explain delays or failures to stakeholders. Take a worked example. A customer sends EUR 5,000 to a supplier on a Monday morning, and the supplier sees the credit in its account the same day. The payment looks complete, but the banks behind it have not settled yet. The sending bank and the receiving bank net their Monday payments and settle the net amount in central bank money on Tuesday morning. Between Monday and Tuesday, the payment is credited but not finally settled, so if the sending bank failed overnight, the settlement could be affected. The customer experience and the interbank reality are two different things, and a business analyst must always say which one is meant when talking about a payment being done. Worked example with real numbers: a customer pays EUR 8,000 to a merchant by card at 10:00, and the merchant sees an authorisation approval in seconds, but the merchant is not paid until the next day, when the scheme clears and the acquirer credits the merchant account less interchange of EUR 16, scheme fees of EUR 4 and acquirer margin of EUR 12, so the merchant receives EUR 7,968. The customer payment and the merchant settlement are two different events, separated by a day, and the gap is the clearing and settlement lag. By contrast, a EUR 8,000 SEPA Instant payment settles in central bank money within 10 seconds under Regulation (EU) 2024/886, so the beneficiary credit and the interbank settlement happen in the same window, and there is no lag to manage. Failure and recovery: a payment that is authorised but never settled, because the clearing file was lost, leaves the merchant unpaid even though the customer was debited, and the recovery is to resend the clearing file and to reconcile the authorisation holds against the clearing totals. A settlement failure, where a participant cannot fund its net debit at the clearing cut-off, is handled by the system default procedure, which may exclude the participant or share the loss, under the Bank for International Settlements Principles for Financial Market Infrastructures. Each failure sits at a different stage, and the recovery follows the stage, not the customer complaint. For a business analyst, product owner or subject matter expert, the test is to state, for every payment product, four separate times: the customer instruction time, the beneficiary credit time, the interbank settlement time and the finality time. If the requirement states only one time, it is confusing the payment with the settlement, and the customer will be misled. The ISO 20022 pacs.002 status codes make the stages visible, with ACCP for acceptance, ACSC for settlement completion and ACCC for creditor credit, and the requirement must map each status to a customer message, so that a customer who asks where the money is gets an answer from the status, not from a guess.