Payments Architecture

Payments Processing

A payment system is a set of processes and technologies that transfer monetary value from one entity to another. Payments are typically made in exchange for the provision of goods, services, or to satisfy a legal obligation.

An efficient payment system reduces the cost of exchanging goods, services, and assets, and is indispensable to the functioning of the interbank, money, and capital markets. Increasing globalisation is driving individuals and corporations to transact more frequently across borders. For the payments industry, the result is higher volumes of payments—in terms of both currency value and number of transactions. New innovations and technologies are everywhere and quickly become an integral part of how we work and live. Like many others the payments processing domain is evolving as markets, customers and technology change.

The payments processing domain comprises a number of features which broadly break down under three headings:-

1. Technical / Support features – those technology capabilities which enable the automation of the processing.
2. Value Add / Opportunity features – those capabilities which might be included to enhance the customer experience or to provide insights which enable revenue generating opportunities.
3. Security / Regulatory features – those capabilities which are either mandated by legislation, or by payment schemes or which represent best practice, and which ensure the stability and safety of the payments solutions across the industry.

Disruptions and Challenges

There are several matters to consider concerning an idealised model of processing payments.

• Most, if not all Banks will have implemented diarised payments i.e. standing orders and bill payments on a legacy platform outside of their regular payments processing systems. These then effectively become an originator of payments instructions.
• Access to and from payments schemes such as BACS, SWIFT, FPS must be through a certified Gateway (a third party product).
• But… these payment schemes often come pre-packaged with a number of other payments domain features (e.g. store and forward, validation, routing, transaction co-ordination, formatting and enrichment)
• Switching these features off at best means paying for functionality that you don’t need or use. At worst, it can result in bespoke instances of the product installation, complicating upgrade paths.
• Using these pre-packaged features means duplication of logic, as they must be repeated in every Gateway - bearing in mind that no certified Gateway currently provides universal access to all schemes.
• Most Banks already have one or more scheme specific Payments Processing solutions operational. Often this has involved the purchase of vendor products which embed the payments processing capabilities. This is an efficient way to introduce industry standard solutions for each payments scheme, but restricts the re-use of common functionality.
  
  At best this results in repeat maintenance costs. At worst makes it impossible to realise the benefits of a single solution.
  
  For example, a Bank-wide view of all payment activity is widely seen as a great customer service offering, as well as a potential source of fraud detection and or marketing data.

Significant changes for payments are upon us with Instant Payments, Open Banking, ISO 20022, and significantly increased payment volumes. This is creating the need to deliver significantly more value at a much lower cost.

Monolithic legacy systems with spagetti-like interfaces to similar monolithic legacy systems result in poor efficiency and unreliable processing - as reported in the national press more and more regularly. A growing emphasis on clean, organised data have presented Banks with several further challenges to overcome, not least of which is staying relevant and competitive in a disrupted and busy market.

In order to remain competitive Banks are now seeking out more and more vendor solutions based in the Cloud, with those monolithic legacy systems replaced by SaaS cloud-native microservices. This approach is needed to allow future Payments transformation initiatives to be agile and responsive to market trends, and to provide customers with the latest in-vogue products and services.

The net outcome is generating new revenue streams and the ability to compete with challenger Banks.

The new approach to Payment Scheme Gateways

Traditionally, physical deployments of payments gateways were required Bank side, which were expensive to deploy and costly to maintain.

Now many of the new entrants are using an API to access a native Cloud payments processing platform, and through that the national payment systems.

This function would have been provided by a payment hub with multiple gateways but now all this can be delivered ‘as a service’ through a single API. The good news is that market coverage includes FPS, BACS, SEPA SCT, SEPA Instant, SEPA DD, International Payments and FX.

Back office infrastructure ‘as a service’ which connects to a Bank's customer channels and core ledgers is also possible, reducing time to market from 1 year plus to a matter of weeks in some cases.

The established banks are now waking up to the fact that developing in house is no longer a sensible option when so many off-the-shelf solutions are available that are easy to integrate, secure and deliver outcomes in a fraction of the time and cost of traditional builds.