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

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.

Table of Contents

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 2019 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 2019 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 2019 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

Episode 4 will be posted shortly. Check back soon!

Phil Mork

Phil Mork

Senior Payments Architect

Phil Mork is a Senior Payments Architect for the Payments Practice at Levvel. He is responsible for providing architectural insight and guidance on various payment topics which enables clients to deliver on their strategic payments initiatives.

Related Posts