ISO 20022 Translators, SWIFTgpi plugins and Process Optimization

Payments systems have always been complex but critical parts of the banking world. Over the last decade, the payments environment has become much more dynamic, creating even greater challenges for financial institutions. 

Complex regulatory requirements, outdated and poorly integrated legacy systems and an increasingly competitive marketplace all put pressure on traditional financial institutions to evaluate opportunities for payments transformation. 

SWIFT gpi and ISO 20022 migration have set the stage to meet the need for consistent customer experience across multiple access channels and drive standardisation in payments. 

These demands have pushed banks to consider major technology investments as well as significant process and cost improvement activities. In this environment, bank executives are challenged to balance a range of considerations: customer experience, technology disruption and regulation.

Focus Area 1 - Technology. 

When organizations start going down a technology path too quickly, the broader operating context and the business objectives that the organization wishes to achieve often get lost.

Banks need to focus on ‘Banking’ - Customers do not expect you to be Google or Amazon! 

ISO 20022 Translator, SWIFT gpi plugins -  Build, Buy or Collaborate with a FinTech?

Build? 

If building in-house, it does not simply involve the integration between internal systems and SWIFT - there is the application of business rules and processes to consider as well. Systems must be updated every year to comply with the annual SWIFT standards release. 

Another perhaps unintended consequence of the build option is yet more siloed systems. And, with the on-going drive to eliminate silos within banks there is a general consensus that having a central, unified payments system should be the way forward. 

Pro - Customized

Con - Inefficient resource utilisation, maintenance costs, siloed solution.  

Source - EY Report

Buy? 

With the buy option, banks have the ability to purchase a solution ready to integrate into their own legacy systems. This eliminates some of the challenges associated with building in-house, but again there are some serious considerations to take into account before taking this route.

The main challenge with the buy option is centred around the integration with existing legacy systems, which can be very complex and time-consuming. Once the integration is complete, firms must still contend with the on-going maintenance issues that are present with the build option, around updating changing messaging standards and connectivity costs to the SWIFT network.

Pro - No build effort 

Con - Maintenance 

Third-Party? 

At the other end of the spectrum is the option to outsource completely to a third party. The main benefit to this option is the reduction in manual intervention and back-office processes, as the third party will take care of message reconciliation, only sending back the final message.

Works for tier 1 banks. 

Pro - No build or direct maintenance costs. 

Con - Fluctuating costs of outsourcing and no clear line of responsibility. 

Collaborate with FinTechs? 

Work with a technology provider to augment legacy systems with a “plug and play” solution. This provides a fast, cost-efficient way to insulate existing systems, while also giving the organisation control and transparency over the payments processes. Another benefit to this option is the reduction in costs of on-going maintenance, as any updates and migrations are handled by the technology partner.

Ensure the solution provided by the FinTech is cloud-native as it will be one of the key components to drive cost efficiency. 

Pro - Customisation, Plug and Play. Pay on Use. 

Con - None So Far. 

Legacy build-versus-buy approaches have yielded mixed success. Clients who have gone all-in with one vendor have been stuck with too many vendor product customizations to meet their business needs and hence have failed in their flexibility goal, as many FinTechs have entered different areas of the payment value chain offering these flexible and scalable experiences. 

A middle road approach is recommended to finding a strategic fintech partner for commodity payment product solutions that provide an industry-standard solution. This avoids vendor lock-in and to create a flexible payments ecosystem that does not solely rely on the vendor for all change when future needs arise.

Focus Area 2 - Process Optimization and Building a payments platform of the future. 

We believe that while technology solutions play a key role, successful transformation requires a broader view that optimizes an end-to-end business system perspective, rather than a purely functional, product or even market segment view. 

Effective payments transformation should start with an end-to-end assessment of the entire payment business system. The end-to-end business system analysis should identify key metrics, including costs, transaction volumes, processing times and other key requirements that may vary across segments. 

Add the emergence of instant payment schemes, Open banking, SWIFT GPI, increased volumes and instrument complexity, and the necessity of changing a bank’s entire ecosystem is almost compulsory.

ISO 20022 Impact on Customers - Source - SWIFT 

Optimization should outline not only the most obvious technology and process requirements but also look for opportunities to transform processes to reduce waste, enhance self-service, and improve customer experience and speed outcomes, not to simply automate processes or move them from one platform to another. It’s also critical to consider key people issues, including fungibility of customer support resources, level of knowledge and back-office infrastructure required to address exceptions. 

A comprehensive review of payments processes would identify a set of services and processes that are common across parts of the value chain that can easily be consolidated into a common utility or process.

Ultimately, the goal is for each bank to understand the end-to-end customer requirements for each payment path, with a view to creating shared infrastructure and processes wherever possible while preserving the appropriate customer-driven distinctions for specific channels, segments and offerings. This will enable the development of business services that can be initially created and shared across each payment path. When payment processing functions are similar, they can be handled as utilities, with rules to accommodate differences.