Clearing, routing and message exchange

Clearing is the process by which payment instructions are exchanged between banks, sorted, and prepared for settlement. In a domestic system, the debtor agent sends the instruction to a clearing house, which sorts it with other payments and sends it to the creditor agent. In a cross border payment, the debtor agent sends the instruction through SWIFT or another network to the next bank in the chain, which forwards it onward until it reaches the creditor agent. The routing decision is critical. The debtor agent must choose the correct clearing system, the correct currency, and the correct intermediary based on the creditor bank, the currency, the amount, and the value date. The payment message is the vehicle for clearing. In MT, the message is an MT103 for a customer payment or an MT202 for a bank to bank payment. In ISO 20022, the message is a pacs zero zero eight or a pacs zero zero nine. The message must carry all the information the next bank needs to process the payment, including the debtor and creditor details, the amount, the charges, and the remittance information. If the message is incomplete, the receiving bank may need to repair it manually, which adds delay and cost. If the message is routed to the wrong bank, the payment may be delayed or returned. Failures at the clearing stage are often operational. A message may be rejected for a format error, a missing mandatory field, or an invalid BIC. A clearing system may be unavailable due to a technical outage, and payments may queue until it recovers. A payment may miss the clearing cut off and be deferred to the next cycle, which changes the value date. Analysts must document the routing logic, the message format, the clearing timetable, and the behaviour on rejection or outage. They must also ensure that the payment status is updated at each hop, so that the customer and operations can see where the payment is. Worked example with real numbers: a EUR 40,000 payment from Bank A to Bank B can be routed two ways, and the routing decision changes the cost and the time. By SEPA Credit Transfer through STEP2 the payment is cleared at 14:00, settled through T2 at 16:00, and the supplier is credited by the end of the next business day at the latest, at a cost of EUR 0. By SCT Inst through TIPS the payment is settled within 10 seconds under Regulation (EU) 2024/886, and the supplier is credited in seconds, at a cost of EUR 1. If the hub had routed silently, the customer who paid for urgent would complain when the payment arrived the next day. Failure and recovery: a pacs.008 rejected by the clearing system, because a field is invalid under the scheme usage guidelines, is returned with a pacs.002 status RJCT, and Bank A must correct the field and resend before the cut-off, or the payment will be value dated the next day. A clearing system outage queues the payments, 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. A message that is sent twice, because the send job retried after a timeout, must be detected by the MsgId duplicate check, and the duplicate must be rejected, not processed twice. For a business analyst, product owner or subject matter expert, the test is to write the routing decision tree for the product, with the conditions, the rail, the cost, the timing and the fallback for each branch, and to state how the customer is told which rail was used. The ISO 20022 pacs.008 is the message for both rails, but the clearing system, the settlement timing and the cost differ, so the requirement must name the rail, the clearing system and the settlement system, not just the message. A requirement that says the payment is sent, without naming the route, the cost and the fallback, will produce a hub that routes correctly on the happy path and fails silently when the preferred rail is down.