Over the last two decades, many banks have faced the frustration of being locked into high operating costs. Minimal budgets cannot meet business needs for expansion or support the improvement of product offerings.

This is partly due to regulatory requirements consuming the lion’s share of the budget and the high cost of maintaining legacy systems. Simultaneously, capital investment in infrastructure has been scarce. Therefore, payments CTOs and CIOs have been left with the challenge of ‘doing more with less,’ and this efficiency trap is compounded by a shortage of talent.

Finextra spoke to Jarkko Turunen, head of payment products and services, Tietoevry Banking; Katja Lehr, managing director, head of EMEA markets payments product management, JP Morgan; and Jonathan Churchward, payments transformation lead, NatWest, about composable banking, outsourcing, and considering buying vs. building payment infrastructure.

Why composable processing is the best approach

Many vendors advise that full payment hub replacements can drive down costs and increase agility and flexibility. However, such approaches aren't just risky: they can also cause delays and budget over-runs with no obvious benefit.

Unravelling this complexity calls for a paradigm shift, one that hinges on a versatile, API-first platform that fosters a composable payments approach. The essence of composability lies in allowing banks to selectively assemble capabilities that meet their specific business requirements, rather than attempting to boil the ocean with large scale modernisation projects.

Whilst assembling those capabilities, banks can embark on a transformation journey that is progressive, avoiding risky and at times, paralysing big bang approaches. Banks can focus on areas generating the greatest impact with reduced effort.

This will help resolve accumulated problems within payment processing, such as:

• outdated systems that hinder agility, efficiency, and security;
• new regulations requiring continuous system upgrades consuming a substantial part of budgets;
• resource constraints to ensure maintenance of the extremely complex payment system; and
• the ever-growing end customer demands for faster, cheaper, and more convenient payment options; and
• newer value added services that significantly improve the overall payments experience.

According to Turunen, challenges will continue to be compounded if no transformation is made.

Why rip and replace is rarely an option for banks

Taking a rip and replace approach is rarely an option for banks. In conversation with Turunen, he reiterated that remaining compliant with regulatory requirements is costly, particularly alongside the high cost of maintaining legacy systems.

He continued: “Another challenge that has emerged is many banks still rely on mainframe systems, and the employees that know how to operate 30-40 year old systems are close to retiring or have left the business. In addition, it is not only IT competencies that are a challenge to find today, but also the business leaders who know payments end-to-end from customer processes and customer channels to clearing and settlement who are scarce. This is impacting the renewal and improvement of systems, which is finally having an effect on the customer experience, where expectations are also shifting.”

Lehr explained that as banks “continue to evolve and modernise how they process payments as technology advances. But it’s important to remember that a bank’s payments processing setup is complex since it consists of various systems interacting with and feeding into each other. Because of that, quickly replacing or modernising any singular dimension – or the whole of it – naturally has ripple effects to manage and mitigate.

A recent Finextra Research and Tietoevry Banking survey revealed that 88% of banks outsource their payments processing to other banks in order to streamline cost and operational resource. Others farm out to IT service providers because of their neutrality in regard to competition, as well as their technical agility.

How will DORA impact payments processing?

Different organisations will have different reasons for leveraging different providers, but Finextra and Tietoevry Banking research revealed that 61% outsource back-office operations; 57%, customer service; 35%, KYC; and 28%, fraud management. However, the same report revealed that the primary challenges banks encounter in payments processing are security and fraud prevention, along with compliance and regulatory requirements.

Despite allocating a significant portion of their budget to these areas, they are among the least likely to be outsourced. One such regulation is DORA – the Digital Operational Resilience Act – which rules that all PSD2 requirements on IT security controls and mitigation for payment services should align with DORA. This will result in a renewed responsibility for overall system resilience and security, and reflect the nature of the payments and banking industry as it is today.

Churchward said that “UK banks are no stranger to third party risk management frameworks and DORA builds on existing UK regulation which is top of mind. The principles of the Act align with our purpose-driven strategy and keeping customers safe and secure. Such frameworks allow our payments engineering experts to solve resilience problems creatively, within the guard rails of the Act, and force business leaders and technology teams to investigate, fund and prioritise scenario planning exercises.”

Build or buy?

Lehr advised continuously “evolving payments processing, while also not changing too much at one time, is to rebuild or replace systems while simultaneously limiting the interdependency of the various systems by adding an orchestration layer. This allows single systems to be changed, updated or replaced without impacting the full infrastructure. Being able to select the right option based on what your payments processing infrastructure needs or is solving for is ideal. This allows the choice for the right path forward – whether that means building your own solutions or sourcing outside options.

“The most important thing to remember when evaluating building, buying or partnering is that any changes or additions to your infrastructure need to be compatible and communicate with your existing systems. And fortunately, vendors have become quite agile and are adopting their products along with the changing landscape.” Churchward has a similar view.

“A near term complete overhaul of IT infrastructure is not a viable solution for any major UK bank unless they are prepared to accept the risk of pausing payment processing in the worst-case scenario. Our payments modernisation journey is multi-phased and by replacing components within our payment journeys we have been able to build resilience by design. This ensures that both ‘old’ and ‘new’ infrastructure can co-exist safely. This is crucial as it means in some cases we can protect customers and colleagues from invasive change while strategically rewiring the house with the lights on.”

Churchward continued: “Every situation warrants careful consideration of build vs buy, and choosing the right vendor is crucial. These multi-year strategic engagements morph into far more complex relationships than the traditional ‘buyer’ and ‘seller’ roles.” He went on to say that by partnering with technology vendors, engineering capabilities are enhanced and allows the bank to “transcend the incumbent ‘build vs buy’ mentality – we buy the ability to build!”

What this means is that their teams are “armed with the tools to build products and experiences our customers love, in turn reducing the proportion of budget we spend on running the bank and regulatory change.” 

6 steps to success

The answer lies in taking a composable approach. This can be sliced into six steps a bank must take to succeed:

1. Assess and understand the current IT system. Conduct a thorough assessment to understand the limitations and the overall business needs it should serve. Identify the areas needing improvement and prioritise the replacements.

2. Clearly define the bank’s target state goals and objectives for new functionality. Determine the specific cloud-native functionality that should be achieved including configurability, scalability, resilience, and automation, setting a clear direction for the replacement process.

3. Identify critical capabilities for replacement. Break down the legacy system into smaller components and identify the ones critical for replacement. Starting with low-risk capabilities to gain confidence and experience before tackling more complex ones is a useful risk-mitigating strategy to apply.

4. Select appropriate cloud-native capabilities from a technology provider aligning with your needs.

5. Conducting small proof-of concept projects using selected cloud-native capabilities could be worth-while during the process. This will help to validate the approach, test integration points, and uncover any potential challenges early on.

6. Continue with gradual deployment and migration approach rather than full replacement at once. Deploy the selected capabilities alongside the existing system to keep control and minimise disruption during the replacement process.