Real-Time Payments Implementation Considerations for Financial Institutions

Introduction

Implementing a real-time payments (RTP) solution is an incredible opportunity for any financial institution, but the journey can be a bumpy one for institutions who are not prepared. To help banks build a knowledge base and prepare themselves to ask the right questions (both internally and externally), Levvel has composed a list of key questions and considerations that you can use to prepare.

These questions are based on Levvel’s extensive experience with RTP, including both business considerations (e.g., ideation, use case design, user stories) and technical considerations (e.g., architecture, design, coding & implementation); however, there are always unforeseen considerations. The key is to always ask a lot of questions of your internal teams and any external providers you speak with. And don’t forget—TCH (The Clearing House) is always available as your partner and guide.

Integration to Deposits Core

• Does your core deposits system offer real-time hard posting or soft posting with immediate funds availability? If not, how frequent are batch updates and how will you meet real-time posting requirements?
• If you can only do real-time soft posting, do you have controls to provide proper access and also prevent inaccurate account overdraws?
• What options do you have to initiate money movement within your core deposit system? (i.e. via synchronous SOAP service calls, RESTful APIs, or messaging)
• How do external systems interface with your core? What are the interface type, transport, and message format? Do you need new interfaces, wrappers, translation layers, etc.?
• How do you manage core outages today? Do you have a stand-in system to cover ATM withdrawals and other transactions while your core is in maintenance mode? What is your strategy for dealing with core outages for RTP?

Customer & Servicing Channels

• What in-house or vendor solutions may be impacted?
• Have you identified all the systems that must be available 24/7 in order to support all mandatory RTP requirements?
• How will your channel systems initiate or receive RTP transactions?
  • If your channel applications are COTS (commercial off-the-shelf), are your vendors ready for RTP?
  • If your channel applications are homegrown (custom), what is your roadmap for integrating them with RTP?
• More broadly than transactions, how will your channels interface with the RTP rails? Can existing pathways handle all necessary data, functionality, etc. or will some sort of integration layer be required?
• Have you finalized the data model for any money movement APIs (Application Programming Interfaces)? Are you using the ISO 20022 standard (like TCH’s RTP solution) or a different template? If different, do you have an existing wrapper/translation layer?
• If you plan to use a TPSP (third-party service provider) to access RTP:
  • Are there timelines (to support RTP) known or do they need to be determined?
  • Do they allow for easy access to data via APIs, or do you need to log into a vendor UI to troubleshoot issues?

Connectivity to RTP via a Third Party Service Provider (TPSP)

• Does the TPSP allow for easy access to data via APIs and data extracts or do you need to log into a vendor UI to view data?
  • If you need to log into a vendor UI to view data, will this meet all the requirements from your teams that need visibility into RTP transactions such as fraud, AML, and reconciliation?
  • What about internal data retention requirements for compliance and other teams?
• How can you monitor your liquidity operational messages? Can you receive messages from the TPSP or are you required to log in to the vendor’s UI?
• What type of deployment model are you seeking? Cloud? On-premise? Hybrid?
• How easily can the TPSP scale meet your expected volume demands?
• Does the TPSP control any decisions (e.g. fraud) where you want the last word? Are they flexible to match your internal operating model?
• Does the TPSP offer flexible interfaces, such as an iFrame model?

Orchestration & Integration

• If using a TPSP, what functionality is handled?
  • Do they send you a single message or a sequence of messages?
  • Do they handle all necessary orchestration?
  • How flexible is their solution? Can it accommodate any custom workflows you have in place or may otherwise desire?
• Which integration points are mandatory vs. optional? Are there ways to reduce the number of mandatory integrations (e.g. by tying fraud checks into a data cache used by your TPSP)
  • Have you looked at vendor variations, internal tech limitations, and the overall customer experience? These can all impact how you handle each integration point, as well as where you do individual calls to internal systems.
• What integrations to existing systems are needed?
  • Do these systems have existing endpoints (e.g.web services or APIs)? Do you need to update or create any new endpoints for these systems?
  • Have you mapped out the different formats each system requires?
  • Do you need any translation or orchestration layers (or any type of wrapper)?

Fraud, Risk, Reconciliation, and Compliance

• What do your fraud/AML/OFAC solutions look like? Do the solutions support near real-time responses?
• Are the fraud/AML/OFAC/etc systems designed to work with real-time decisioning via enterprise services?
• Can your fraud system ingest data synchronously and use that data to help score the current transaction?
• How will your reconciliation and compliance systems receive and process RTP data?
  • How does any TPSP or other vendor make that data available?
  • Do you require any additional data store specifically for these systems?
• How are ancillary tools and processes supported today? Can they support 24x7x365 requirements?
• Is there a system that can react to alerts from a centralized activity monitoring utility?
• Do you have a strong authentication system? For example, including the ability to offer multi-factor authentication adds additional data for scoring the RTP transaction.

Other Technology Systems

• Have you done a comprehensive review of your entire workflow (both business and technology processes) to determine which systems are required 24x7x365?
• At a minimum, will the following systems be available to support a 24x7x365 network?
  • Core deposit system
  • Fraud system
  • AML
  • OFAC
  • Notifications system (SMS and email)
• Have you confirmed whether there are critical systems that cannot meet the real-time requirement, and thus determined how often you may have to sign-off the RTP network? (e.g. during maintenance of one of those systems)

Operations

• Does your organization have both the operations staff and technology tools to monitor real-time health for all of the systems listed above? Can they respond to failures in real-time?
• Have you reviewed each of the RTP messages (particularly the Control, System Notification, and Administration Advice messages) to determine where you may want to automate operations processes?
• How robust is information availability/linkage in your systems? Can operations gain a full view across all systems and messages? Can they easily recognize the linkages between a Request for Payment, a Remittance Advice, a subsequent Credit Push, a Request for Information, a Response to Request for Information, and a subsequent Request for Return of Funds?
• Are your operations teams outsourced? If yes, then you need to ensure you have the necessary access and contractual protections, especially given the real-time speed.
• Does your TPSP provide access to data via APIs? Or are you required to use their toolset? Can you export all desired data so you have your own internal records?
• Do your customer onboarding processes meet the KYC and preference needs of RTP (e.g. for alerts, notifications, etc.)?

Liquidity Management

• Do you have the capability to monitor the real-time liquidity position in your RTP settlement account?
• Should you automate liquidity management since RTP is a 24x7x365 system and additional funds may be needed over the weekend?
• Can your liquidity management system accept and respond to liquidity management operational messages from TCH?
• If you want to automate liquidity management, can you integrate with your wire system to automatically transfer funds into and/or out of the RTP settlement account?
• How can reconciliation windows be configured or scheduled using existing systems?
• What balance reports may need upgrades or may need to be created?
• Is any of your liquidity management process outsourced today? If yes, what are the implications and limitations you may face with RTP?
• Reporting, Monitoring, and Analytics
• Where can you add value to customers with real-time reports? How are customer expectations (for data and information access) changing with RTP payments?
• What internal reports and analytics tools exist? Which ones need to be real-time? Have you thought through what information you want to be able to provide your executive team?
• How will RTP data be received and processed by your reporting and analytics systems?
• Do you have a technical deployment strategy to ensure real-time availability of the systems?
• What has been done for account privacy?
• Is there 27/7 monitoring of payment activity?
• How are billing and fee systems going to be connected to the workflow of RTP transactions? Are calculations and reporting flexible to accommodate the expected changes from RTP?

Next Steps

Use this RTP checklist to accurately assess your current architectural environment, identify the challenges your institution will need to address, and plan appropriately to deliver a high-quality experience for your customers. Whether you are in the process of implementing RTP or planning your integration, this checklist will help guide your decisions and ensure you are on the right track.

As payment systems domestically and internationally adopt faster money movement, your customers are doing the same. In order to remain competitive, providing your customers with accessible, competitively-priced real-time payments will secure your position both in the market and as their financial institution.

About Levvel

Our team is made up of leaders, thinkers, designers, and builders whose collective experience spans many industries and companies of all sizes. We’re avid fans of technology but even bigger fans of solving business problems. An understanding of the difference between an idea and a solution is just one of the things that set us apart.

Our Payments practice combines enterprise payments experience, technical expertise, and a pulse on emerging technologies to ensure our clients create the right approach the first time. Our team has broad, strong industry relationships and expertise across the payments ecosystem.