Payments modernisation in financial services: building the foundations for future success

In recent years, waves of change have swept across the payments industry. This has resulted in many financial institutions struggling to accommodate changes to payments estates that were not designed for the modern payments business. The tactical approach that most banks have taken to ISO20022 is a great example where most banks have chosen, or effectively been forced into, the ‘minimum compliance’ route because a strategic solution is too complex on their current architecture. With the level of change looking unlikely to abate in the coming years, it is essential that organisations modernise their payments architecture now to set the foundations for future success.

Alignment with the business strategy

Although there are many different drivers for these changes, which have been well documented elsewhere, arguably the most important driver is business strategy. This includes the organisation’s payments strategy, coupled with its overarching strategy – is the organisation an industry leader on innovation? What is the risk appetite? Are payments a differentiator? What are the customer needs? Both strategies will impact the direction of travel for payments, meaning architecture modernisation should not be seen as ‘just’ an IT initiative. Modernising a payments architecture does not guarantee business benefit, and just promising lower IT operating costs and quicker speed to market for products is rarely enough to justify a business case. It is essential to gain business buy-in and collectively identify opportunities for delivering business value throughout the modernisation journey.

What does a modern payments architecture look like? 

Unfortunately, there is no one-size-fits-all, and it requires careful analysis of both internal and external drivers to identify what’s right for each organisation. The payments needs of a mass-market, multinational bank are vastly different to those of a specialist, regional bank. But there are some aspects that are consistent across almost all modern architectures, related to data, APIs, and cloud. 

Data

Data needs to be at the heart of any architecture – a clear data model across all systems, enabling traceability and accessibility of payments data. With more and more schemes moving to ISO20022 there is a huge opportunity to settle on a more consistent data set for payments, increasing efficiency and the potential for a higher straight through processing (STP) rate. Awareness of data residency regulations for each jurisdiction is critical, particularly when using cloud providers. Providing easy access to the data, such as payments status, to other systems and end users should also be a goal, with the use of event streaming an enabler for this. An often-overlooked usage of data is for observability of the end-to-end flow of payments which can provide greater insight for data-driven, strategic decisions, greater confidence to the regulator of the resilience of the solution, and a more proactive response to incidents. As a stretch target, enabling self-service analytics to customers, particularly in the corporate space, can be a real differentiator over competitors. While there are undoubtedly potential benefits from having more data, consideration also needs to be given to the impact on performance of having more data to process, reconcile and store.

APIs

Modular, service-based architectures, enabled by APIs provide significantly more flexibility than traditional tightly coupled architectures, making change easier and increasing the extensibility of the solution. Whilst using APIs internally has many benefits, using these externally also simplifies partnering – increasingly organisations are looking to partner with niche providers to offer specific services, such as cross-border payments, or buy now pay later (BNPL) solutions. The payments, and broader banking, landscapes continue to fracture, and boundaries are blurring between market participants – the cross-border payments market is a great example of this, where Swift’s recently announced partnerships with Wise and Visa are just the latest in a series of movements. It is essential that banks have the flexibility of a partner ecosystem to rapidly adapt to this shifting competitive landscape, and APIs are the literal and metaphorical gateway to this ‘plug-and-play’ ecosystem. The use of external APIs to offer customer propositions is also growing, with PSD3 and the era of Open Finance likely to make APIs as a channel even more important for payments and its associated services.

Cloud

Within financial services, payments has been slower than most areas to embrace cloud, in part caused by the uncertain stance of regulators, and in part by the broader organisational risk appetite. This has changed significantly in the last couple of years with cloud technologies now being used by over 90% of banks undertaking payments change. A decision also needs to be made on the type of cloud solution to adopt – deploying a vendor platform in a private cloud, a Platform-as-a-Service solution (PaaS, sometimes called low-code), Software-as-a-Service (SaaS), or even a Payments Platform-as-a-Service. There are as many different terms as there are interpretations of these terms, so it is important to work with vendors to really understand their offerings, and crucially, the maturity of these offerings. 

Although the regulatory position is becoming clearer, moving payments to the cloud is considered material outsourcing and requires notification to the regulator a full 12 months before implementation. And while cloud provides ‘resilience by design’, there will still be focus on stressed-exit scenarios and how to manage concentration risk with cloud providers. The model chosen will also significantly impact the level of control the organisation has over its payments processing – are you prepared to cede much of this control to a third party? In contrast, outsourcing to a third party that is incentivised to keep pace with every change in the payments landscape reduces the burden on the bank to continuously adapt and maintain the in-house payments expertise.

It is clear that payments in the cloud is the target state for most banks but, at least in the short to medium term, it is likely that other parts of the IT landscape, such as the accounting platform, will still be hosted on-prem, potentially introducing more ‘hops’ into the end-to-end payments flow. The performance of this new architecture will need to be carefully tested and monitored to ensure processing speeds are maintained.

Considerations for delivery

Defining the target state for a payments architecture is the easy part; delivery is significantly harder. This is rarely a short, single release project; more typically it is a multi-year journey through a series of transition states, delivering manageable levels of IT change, within the risk appetite, but also giving time for the business to adapt. This all needs to be done while continuing to deliver mandatory change, and inevitably some level of discretionary change. Given the level of scrutiny that any payments change attracts, architecture modernisation should expect oversight from risk teams, internal audit, and the regulators – ensuring they are brought ‘inside the tent’ early on the journey is essential to enable a smoother delivery. 

While defining and delivering architecture modernisation is not easy, having the right payments architecture, aligned with the strategy and customer needs, can provide the foundations to flourish not despite the constant change in the industry, but because of it.