Video Series: Real-time Payments Architecture—Solution Design for a Real-time Environment

Introduction

This video blog series covers the architectural and solution design aspects of real-time payments. Throughout this series we’ll provide answers to frequently asked questions surrounding architectural considerations for RTP, like which options are available for banks, differences in integration options, general tips and helpful insights for FIs integrating, how to break the entire process down into phases, and more.

Also see our real-time payments strategy and decision making and RTP product and design vlog series.

Episode 1: What are the Options for Banks to Integrate with TCH’s RTP System?

Episode 1 Transcription

Phil Mork: For banks looking to integrate with TCH’s real-time payment system, at a high level, they have a couple of options. One option is to integrate directly into the TCH RTP rails, and the other option is to integrate through a third party service provider, also known as a TPSP. So, some factors that will influence which option a bank chooses to integrate with include things like looking at your existing architecture and determining how RTP is expected to be treated.

Is it just another payment rail or is it part of a much bigger enterprise strategic effort? Also, what are your key vendors in the payment space and what are their capabilities? Do they have a strong RTP offering? Another question to ask yourself is, do you have a payments hub? If you do, that’s a very natural integration point to tie RTP in. If not, then consider your key vendors in the payments space for things such as ACH wire, etcetera, and since they are already integrated into your environment, it’s a very natural question to ask.

Do they have a strong RTP offering and have you looked at their offerings to evaluate how well they would fit with your enterprise? Another key question to ask yourself when you’re looking at these options is what is your organizational preference on solutions? Is it to build or to buy? If your preference is to buy, then you’re going to want to look at using a third party service provider.

Is your financial institution ready for real-time payments? Find out with our 2020 Real-time Payments Readiness Report.

If your preference, however, is to build to maintain maximum flexibility, you have a couple of options. You can definitely connect directly to the TCH RTP rails or you could consider more of a hybrid-type option where you use a more lightweight TPSP who will connect to the RTP rails on your behalf, and then expose to you all the messages so that you can then build and implement that core RTP processing logic, which then integrates with your existing systems.

To go a bit deeper, integrating directly into the RTP rails involves establishing the required connectivity between the bank and TCH. Whereas if a bank chooses to integrate through a third party service provider, then it is the TPSP’s responsibility to connect to TCH. Depending on the particular third party service provider, they often will do more than just provide the connectivity to The Clearing House.

TPSPs can assist your institution with other activities such as conducting message format and syntax validations, validating messages for cryptographic correctness, interacting with other systems within your organization as needed, and also logging messages, and then providing some way for you to view those later through something like an operational dashboard. The TPSP can provide a lot more than just connectivity, and because they are adding this core RTP processing logic as well, it can save your institution quite a bit of time and effort in your RTP implementation.

Use our 2019 RTP Implementation Checklist to help guide your decisions and ensure you are on the right track.

Episode 2: Integration Differences Between RTP and ACH

Episode 2 Transcription

Phil Mork: If you’re a bank looking to integrate with RTP, you should be aware of some of the biggest differences between RTP and another payment type such as ACH. The three differences I want to highlight are first moving from batch-based processing to real-time. Second, real-time payments are irrevocable. And third, RTP is a credit push only system.

First, one of the biggest shifts in integrating with RTP, versus another payment type such as ACH, is the move from batch-based processing to real-time processing. So this is a shift that’s not unique to financial institutions in RTP. It’s really happening across many different industries and domains, and it’s occurring because customers continue to expect more and more of their interactions to be real-time. So from smart speakers to social media, to video streaming services, customers expect systems to be up 24/7 and to be responsive. Banking is not immune to this expectation.

Is your financial institution ready for real-time payments? Find out with our 2020 Real-time Payments Readiness Report.

A second big difference between RTP versus ACH is the fact that real-time payments are irrevocable. This means that once the money is sent and both the participating FIs accept and acknowledge the credit transfer, the money moves, and there is no concept of a reversal. This is a different paradigm and takes some getting used to, but it also has some advantages of removing the complexity of things like reversals.

A third key difference between RTP and ACH is that RTP is a credit push only system, so there’s no equivalent of an ACH debit. This, again, has its tradeoffs, but it puts more control back into the customer’s hands.

Episode 3: Key Architectural Considerations for RTP Integration

Episode 3 Transcription

Phil Mork: Some key architectural evaluations that I’ve seen help FIs as they integrate with RTP include first separating out critical processing systems from those systems that just need to be informed. Second, determining if interactions should be synchronous or asynchronous. And third is doing performance budget analysis and focusing first on those flows that directly impact The Clearing House’s five-second service level agreement.

So first, separating out systems that are absolutely critical to processing a given RTP message, such as a credit transfer, from the other systems that just need to be informed. Now, this may sound obvious, but it can be pretty surprising if you ask a group of folks representing those different systems to raise their hand if they are critical to a given flow. How many of them would raise their hand and say, yes, I’m critical. But upon deeper analysis, you find out that maybe there’s just two or three systems that are absolutely critical and the other ones absolutely need to be informed, but like a near real-time messaging may be sufficient for them.

Use our 2019 RTP Implementation Checklist to help guide your decisions and ensure you are on the right track.

For example, in the case of a credit transfer, your core system absolutely needs to be in the critical path, whereas something like an enterprise data warehouse absolutely needs to be informed, but it is not in the critical path of actually processing that message. It’s not involved in the movement of the money, so as long as they are informed in a near real-time fashion, that will be adequate. This leads to a second key activity.

Determining whether synchronous or asynchronous integration is the most appropriate for each system that’s going to be involved in your overall RTP solution. It may be that many systems needs can be satisfied asynchronously, while for others, synchronous integration might be the most appropriate approach. This is critical in determining whether you can meet the required SLAs, and it also has a big impact on things like scalability, responsiveness, and resilience of the overall solution.

The third key activity is to do performance budget analysis, especially on those flows that directly impact the TCH five-second service level agreement. Be very mindful of the fact that the longer the chain of critical systems involved, the more challenging it becomes to meet the SLA. Let’s say for example, that you have service A that calls service B, which then talks to a back-end system such as a core.

Is your financial institution ready for real-time payments? Find out with our 2020 Real-time Payments Readiness Report.

When you consider those response times added together, they may not comfortably fit within the TCH five-second service level agreement, and if you’re using the TPSP, you also need to factor in their processing time as well. If you run into situations where you know you can’t meet the SLA, or you believe it will be at significant risk, you need to carefully consider other alternative approaches such as potentially caching information. This could be appropriate in a received credit transfer flow, for example.

Episode 4: Breaking Down the RTP Integration Into Phases

Episode 4 Transcription

Phil Mork: Since RTP is the first net new U.S. payment rail in over 40 years, it can seem like a rather daunting task for a financial institution to integrate with RTP. You can make this a lot more achievable by breaking it down into phases such as receive only, send, and request for payment.

For receive only, some of the key activities in this flow include things like account validation and fraud checks, and once your institution receives an RTP credit transfer message, it must respond back to The Clearing House within five seconds indicating whether you want to accept, reject, or accept without posting. For send, you need to consider real-time account validations as well as real-time fraud checks. Here are some questions you should ask yourself: Do you have solutions for fraud, AML, and OFAC, et cetera, that support near real-time responses? Are the systems designed to work with real-time decisioning via enterprise services?

Use our 2019 RTP Implementation Checklist to help guide your decisions and ensure you are on the right track.

Can your fraud system ingest data real-time and then use that data to help score the current transaction? You can also break the send phase down even further by considering which customer types you want to support first. For example, you may choose to enable RTP send for commercial customers first, followed later by small businesses, and then retail. It’s totally up to what makes the most sense for your institution. A request for payment is really just a non-monetary message that does exactly what it sounds like. It allows a customer to request a payment from another customer or company.

A way that you can simplify the send phase also is choosing to move the request for payment into its own phase. This will allow you to remove some of the technical complexity as well as the user experience and design choices you’re going to have to make on how you want to enable the request for payment. This will let you get to market faster with your basic core functionality of receive and then send before you move into something that is slightly more complex. Additionally, you can refer to The Clearing House’s message personas for more details.

See more from our Financial Services team:

• Read: 2020 Real-time Payments Readiness Report
• Read: Real-time Payments Implementation Checklist for Financial Institutions
• Read: Drive and Sustain Your Digital Innovation Effort