Acceptance for Settlement

Acceptance for settlement is the stage at which a payment system or securities settlement system formally accepts a transfer instruction for settlement, in line with its rulebook. Before acceptance, the system has only received a message. After acceptance, the instruction has passed the system's validation and risk checks and is in the settlement process, even if the money or securities have not yet moved. The term matters most to system operators, participant banks, lawyers and overseers, because many legal consequences are tied to this moment.

Acceptance is one step in a sequence that runs from submission to settlement finality. It is often confused with finality itself. In some systems the two happen together; in others an accepted instruction can still be queued or revoked for a time. Each system's rules define the exact moment, and the Principles for Financial Market Infrastructures expect those rules to be clear and public.

Imagine handing a parcel to a courier. Dropping it on the counter is not the same as the courier signing for it. Once the courier checks the label, weighs the parcel and gives you a receipt, the parcel is in their care and under their terms, even though it has not been delivered yet.

Acceptance for settlement is the signed receipt. The system has looked at the instruction, decided it is valid and that the sender is allowed to send it, and taken responsibility for processing it under its own rules. Delivery, which in payments is settlement, may follow a moment later or at the end of the day.

A typical system runs a series of tests before it accepts an instruction:

1. Technical validation. The message is checked for format, mandatory fields and authentication, using standards such as ISO 20022 messages.
2. Participant checks. The system confirms that the sender and the receiving participant are both admitted members, not suspended, and permitted to use that service.
3. Risk controls. The system tests the instruction against limits such as a credit cap, bilateral or multilateral limits, or the availability of funds or collateral.
4. Formal acceptance. If the tests pass, the instruction is time-stamped as accepted and either settled at once or placed in a queue.

In a real-time gross settlement system, an accepted payment that is covered by funds settles almost immediately, so acceptance and settlement may be separated by milliseconds. Where funds are short, the accepted payment waits in a queue or is handled by a liquidity-saving mechanism. In a deferred net settlement system, acceptance can happen hours before the net positions are settled at a settlement window.

Acceptance points matter in insolvency. If a participant fails, administrators may try to unwind payments it sent. Laws that protect payment systems usually shield instructions that entered the system before the insolvency was declared. In the European Union, the Settlement Finality Directive uses the idea of the "moment of entry" of a transfer order, defined by each designated system's rules, and the moment after which an order can no longer be revoked. Transfer orders that entered the system before insolvency proceedings opened remain enforceable against third parties.

Acceptance is therefore separate from irrevocability and from final settlement. A system might say that orders are accepted when they pass validation, become irrevocable when they enter the settlement queue, and are final when the accounts are debited and credited. Participants need to know each of these points, because they decide when a payment can be cancelled and when the receiving bank can safely release funds to its customer.

Operators publish acceptance rules in their rulebooks and technical documentation. Participant banks build their internal controls around them: a bank's payment engine records the system's acceptance message as evidence that the order left its hands, and treasury teams use queued but accepted payments when forecasting intraday liquidity. Acceptance also affects payment status reporting, since "accepted" and "settled" are separate statuses in ISO 20022 status reports.

In card and retail systems the same idea appears in a different form. An instruction may be accepted for clearing in a batch, while interbank settlement happens later through a settlement agent. The customer's bank may already have given the payee provisional credit, which can be reversed if the batch does not settle.

Vague acceptance rules create settlement risk and legal risk. If participants disagree about whether an instruction was accepted before a failure, losses can land in the wrong place and confidence in the system can suffer. Overseers therefore ask operators to define, document and disclose acceptance, irrevocability and finality as separate, clearly timed events, and to make sure local law supports them.

• Principles for Financial Market Infrastructures (CPMI-IOSCO)