🔒 Instant Credit Tranfers

Discussing the design of real-time customer credit transfers in ISO20022 infrastructures

Welcome to The Engineer Banker, a weekly newsletter dedicated to organizing and delivering insightful technical content on the payments domain, making it easy for you to follow and learn at your own pace

Learn payments with The Engineer Banker

---

Welcome back to our series on connecting the world instantly through real-time infrastructures. In our previous post, we delved into an introduction to ISO20022 real-time systems and explored the FedNow infrastructure. Building on that foundation, today's article will shift the spotlight onto one of the most crucial flows - the customer credit transfer. By examining this essential flow, we will draw insightful comparisons between the American and European design approaches. Specifically, we'll dive into the specific messages utilized in each system and how they are employed to facilitate seamless transactions. Through this exploration, we aim to shed light on the distinctive features and functionalities of these real-time payment systems, providing a comprehensive understanding of their unique attributes.

But before we deep dive into the real-time transfer lets review what are the properties of an instant payment:

• Immediate credit: The funds become available in the payee’s account immediately (within a few seconds) of the payment being initiated by the payer.

• Finality: Once an instant payment is processed, it is considered final and irrevocable. This means that once the funds are transferred, the transaction cannot be reversed or canceled, providing a high level of certainty and security.

• Certainty of fate: Both the payer and payee receive immediate confirmation of the transaction status, ensuring transparency and quick resolution of any issues.

• Availability: Instant payments are available 24/7, allowing transactions to be initiated and processed at any time, including weekends and holidays. This constant availability provides greater convenience to users.

• Straight Through Processing (STP): In the case of an immediate payment, the transaction is processed end-to-end, and any issues that arise lead to an immediate rejection. This prompt rejection provides the payer with an opportunity to correct the problem and retry the payment promptly.

As a result, the ISO20022 real-time systems have been purposefully designed to meet these specific requirements as we will see in today’s article.

Credit transfer fundamentals

Within this visual representation, we can see the fundamental message exchange that takes place during a basic credit transfer between a debtor and a creditor.

• The payment is initiated, and the debtor's account balance is temporarily held for the payout amount. The amount is reserved for the transaction end to end and the transaction with all payment details is sent to the payment scheme via a pacs.008 message.

• The payment is validated and then is routed to the correct destination using the beneficiary BIC or RTN contained in the payment message. The central system then awaits a response from the beneficiary side, allowing a few seconds for the receiving institution to acknowledge the transaction. The receiving institution screens the transaction and promptly provides a response within the specified time frame. Both FedNow and RTP offer the "accept without posting" option to the creditor institution, which is not available in RT1 and TIPS.

• In case of acceptance the transaction is settled in the master accounts of debtor and creditor institutions. If rejected the amount reserved is released from the originator institution account.

• At this stage the transaction is settled, participants must sync their state accordingly, therefore the central infrastructure sends a settlement notification so that books can be synced on both sides. Creditor side clears the pay-in and posts the transaction to the end beneficiary. Debtor side confirms the outbound transaction and commits the hold.

Clocks and timeouts

Below, you can see the customer credit transfer end to end and how it is affected by the clock. It commences when the debtor agent triggers the flow by sending the pacs.008 to the interbank space, inserting the timestamp in the message and activating the timeout clock of the transaction. Throughout each stage of the process, from message receipt to processing, and ultimately to receiving the pacs.002 in response, the infrastructure diligently adheres to the timeout defined in the rulebook. For RT1 and TIPS the timeout is set to 10 seconds and for RTP and FedNow it is 20 seconds.

The 10/20-second timeout covers the entire roundtrip from A to point E (from debtor agent initiation to the central infrastructure receiving the creditor agent decision). Delay in the process is introduced at every step of the roundtrip, therefore it is of extreme importance that the creditor agent takes the screening decision within few seconds as it is this window they can influence and control.

A + B + C + D + E <  10 or 20 seconds

In the event that the timeout setting is surpassed, the pacs.008 is promptly discarded and rejected by the system, ensuring swift and efficient transaction processing.

It is essential to note that the settlement of the transaction, upon receiving the confirmation from the beneficiary bank, and the final notification to both parties are not subject to the timeout SLA, this crucial steps lies outside the scope of the SLA.

The critical messages that come under the scope of the timeout clock are those with significant settlement implications, namely pacs.008, pacs.009, and pacs.004.

The timeout structure we've presented aligns with the practices followed by most payment infrastructures like RT1 and TIPS. However, FedNow stands out with its unique approach, as it allocates an additional timeout for the receiver institution to respond. Once FedNow dispatches the pacs.008 to the creditor agent, a receiver timeout of 5 seconds is initiated. During this period, the system patiently awaits a response from the recipient, allowing sufficient time for processing. This dual-clock mechanism ensures a thorough and efficient evaluation, as the system continues to monitor until either of the two clocks reaches its timeout threshold. By implementing this thoughtful design, FedNow streamlines the communication process between the parties involved and enhances the overall responsiveness and reliability of the payment system

A crucial aspect to bear in mind within the payment process is that the beneficiary should initiate the posting and downstream logic only upon receiving the settlement confirmation, and not a moment earlier. By adhering to this sequence, we ensure that no unconfirmed payments are mistakenly booked and processed. Acting upon a payment before receiving the confirmation may lead to undesired consequences, requiring manual compensation efforts later on to rectify any potential discrepancies. To maintain a seamless and accurate payment experience, it is imperative that all parties involved exercise prudence and follow the established order of operations, ensuring that each transaction is confirmed and settled correctly before proceeding with further actions.

Lost in translation

So far we have discussed the happy basic pacs.008/pacs.002 request-reply interaction common to all ISO20022 infrastructures which is the basic implementation for a funds transfer but what happens when central system settlement confirmations get lost?