< Back to Blog post Romania

Part 2- Building a Solution for Real-Time Payments

In the first part of this blog series, I outlined some of the payment industry trends. In this second part, I am excited to share a few insights about the challenges in supporting faster payments and a solutions approach for real-time payments:

The Faster Payments Landscape

Faster Payments, aka Real-Time Payments, has been gaining steady adoption around the globe. In the U.S., TCH (The Clearing House) introduced Real-Time Payments (RTP) in 2017, following which, several Financial Institutions, FinTechs and other stakeholders have been using the platform, accounting for over $250B worth of transactions in 2018.

Real-time payment apps such as Zelle and Venmo have been popular for some time now; however, these are consumer facing apps for P2P payments, although the underlying platforms such as Visa Direct and Mastercard VocaLink can handle B2C payments. TCH and 40 such instant payment rails worldwide, are suited to B2B and B2C payments which have the complexities of cross-border payments, cross-currency, high-value transactions, multiple Methods of Payment (MOP), account switching, payment re-routing, and handling a multitude of clearing schemes, protocols, channels, etc.

The U.S. isn’t the only country – or even the first – to come up with a faster payment scheme. South Korea ushered in fast payments in the early 2000s, followed by Malaysia, Iceland, and South Africa. The United Kingdom became the first major economy to launch Faster Payments in 2008, followed by China, India, Brazil, Mexico and Singapore. The European Union launched SCT Inst for Credit Transfers, and then rolled out the TIPS (Target Instant Payment Settlement) platform in 2018. Australia, too, started the NPP Service in 2018 for real-time payments.

Faster Payments and an enhanced infrastructure are enabling financial institutions and FinTechs to bring new products and services to the marketplace and create new revenue streams, such as providing intra-day loans to corporations and offering liquidity management services. The drivers for RTP adoption include technology advancements with smartphone and payments linked with social apps, merchants’ desire to receive funds fast and reduce fraud, and customer expectations of an immediate settlement with no transaction fees.

Challenges in Supporting Faster Payments

Traditionally, Treasury Operations teams at banks have been controlling payments using a manual process involving fixing errors, making liquidity arrangements, bypassing cutoff requirements, etc. The underlying systems are slow, batch-driven and lack instantaneous processing 24/7/365.

The challenges are quite enormous: being highly available, always-on, scaling up or down depending on the speed of incoming RFPs (request-for-pay), meeting the stringent SLAs mandated by the RTP Payment rails, predicting liquidity needs to a certain limit, integrating with core banking platforms for account hard-postings and balances, MOP selection based on a multitude of rules, enriching the payments data as required in various steps of the flow, providing an omnichannel experience across devices, and checking with back-end systems for fraud detection, sanctions, and AML.

Financial Institutions and FinTechs started integrating/consolidating their back-end systems into ‘Payment Hubs’. However, most of these have been built 15-20 years ago and do not satisfy the requirements & SLAs demanded by the new wave of Real-Time Payments platforms. 

A Solutions Approach

The problem lends well to a solution based on Domain Driven Design and Microservices. Each piece of functionality mentioned in the previous section can have a clear bounded context. E.g., the Method of Payment selection can be a domain which serves only one purpose: given the details of a payment request, to determine the form of payment based on a set of rules embedded within the context. Similarly, Sanctions can be an autonomous domain that determines whether values in certain fields of the payment request, e.g., the destination country, is in a sanctioned list. Core Banking or legacy accounting systems can be front-ended with a separate domain that checks for limits, balances, liquidity, and makes hard-postings to accounts. A Routing domain may be designed to enrich the payments data to include any intermediaries for the payment, e.g., a cross-border payment may be re-routed through a correspondent bank in the destination country.

Thus, stateless microservices can be designed for about 15-20 autonomous domains, each defining its interface API and data model, usually a subset of an enriched payments message defined by ISO 20022, a standard for the payments industry. The solution needs to take into consideration traditional methods of payments, e.g. ACH and wire-transfers, and not just real-time payment rails such as TCH and TIPS.

Once the domains and microservices have been designed, the problem is of coordination; how do these microservices interact with each other? One can think of an orchestration layer at the top, which is the traditional way of handling interactions with a central controller handling request-response from various microservices. Given the asynchronous nature of the problem as described in the previous section and the stringent SLAs for faster payments, I’d tend to think of an event-driven, reactive architecture to better suit the needs of the solution. Thus, each microservice is a consumer of events and produces events back into the event stream, without the need for central orchestration. Building orchestration logic in the middle layer like an ESB, is going out-of-style in modern, containerized applications.

A hybrid architecture combining these two paradigms is also possible. In either case, a number of open-source technologies are available to implement these architectures with the desired scalability and fault-tolerance.

While infrastructure rationalization and modernization are underway and new open banking standards and APIs are enabling collaboration between unusual partners to develop new value propositions, Ness brings its leading-edge Microservices and Event-Driven Architecture expertise and hard-core engineering capabilities for helping clients achieve a flexible and highly scalable business solution, migrating away from a monolithic architecture. We also help create an end-to-end data platform architecture, integrating multiple payment gateways, systems, and channels, so a company can build a 360-degree view for its customers.

Click to Read Part 1-Payment Industry Trends