As real-time payments become ingrained across the globe, banks and payment service providers (PSPs) face testing times aligning their payments systems with ongoing innovation and regulatory shifts. Fundamental to minimising risk is effective end-to-end testing, but limited and costly methods can make the process far from optimised. XMLdation’s Tricia Balfe, CEO, Fabien Girard, Strategic Project Manager, and Ville Valén, Lead Service Delivery, discuss how pioneering self-service and automation tools are enabling a simple, configurable, on-demand approach that is redefining end-to-end real-time payments testing – and positioning banks for the real-time cross-border payments future.
“Why a self-service simulator is the answer to real-time payments testing headaches for banks
The rapid pace of innovation, combined with ongoing regulatory change, means that banks and payment service providers (PSPs) need to adapt their payments systems on a seemingly continual basis. Progression in the real-time payments space has been particularly striking, with around 80 countries having implemented their own domestic payments systems [1], and the industry now heavily focused on interoperability between these rails to facilitate seamless real-time payments across the globe.
Meanwhile, the One-Leg-Out Instant Credit Transfer (OCT Inst) scheme - which uses SCT Inst for the euro leg to enable EURO to non-EURO (or SEPA to non-SEPA) payments - is also on the radar.
“As banks and PSPs join the real-time payments revolution, the need to keep on top of industry changes to different rails and manage risk when updating their own systems becomes more involved and complex.
Real-time payments are undoubtedly becoming a regulatory standard and a market staple, with many banks joining multiple rails in order to meet regulatory and client demands. As banks and PSPs join the real-time payments revolution, the need to keep on top of industry changes to different rails and manage risk when updating their own systems becomes more involved and complex, with real-time payments testing an ongoing requirement.
For banks, delivering real-time payments capabilities requires significant infrastructure upgrades - including implementing the underlying infrastructure that facilitates the transfer of funds - ie. the payments rail itself - and considerable time, effort and costs are inevitable. Moreover, failure to get the implementation right can also prove costly, with banks facing hefty fines for compliance breaches, as well as reputational risk and potential restrictions to their operations if an offending bank's real-time offerings are considered unsafe. With much at stake, thorough and rigorous testing is an imperative part of the real-time payments reality.
Joining a new rail (often also referred to as a payment market infrastructure) is a huge undertaking from a testing perspective. Not only are there compulsory use cases to perform before they can go live, but banks also need to be able to test their own operations to understand how their specific system behaves under different scenarios. The need to test doesn't end once live. New regulations, changes to banks' internal systems and rail developments are regular occurrences - in fact most rails, including Swift CBPR+ and STEP2, have annual updates - and all demand testing to ensure there is no impact to ongoing rail usage and performance (see Figure 2).
| More rails = more testing: The increasing payments testing challenge for banks and PSPs | |||
|---|---|---|---|
| Bank type | # Rails | # Annual updates: rail + bank system | # Test cycles annually |
| Domestic | 2 | 2 + 4 = 6 | 2 * 6=12 |
| Multi-country | 20 | 2 + 6 = 8 | 160 |
Figure 2: the number of end-to-end testing cycles required annually by banks, dependent on rail numbers, rail updates and approximate payments systems updates
The reality is that regulatory and digital developments mean that banks' systems will need to keep changing. And banks can't change their systems unless they can test effectively, end-to-end, on an ongoing basis. This applies whether a bank or PSP is a direct participant of a real-time rail or connected indirectly through a direct participant bank or vendor. Indeed, for indirect participants - which can often be smaller banks or non-local banks, there is still a need to perform testing to verify their systems are working proficiently.
“Regulatory and digital developments mean that banks’ systems will need to keep changing. And banks can't change their systems unless they can test effectively end-to-end, on an ongoing basis.
Currently, there are three methods for real-time payments testing, with banks usually choosing to utilise them all:
Each approach has limitations, however (see Figure 3). Market infrastructure tools are focused on certification from the market infrastructure perspective and do not take into account the specific requirements around bank system testing. This restricts the ability for banks and PSPs to test the tenacity of their own systems and detect potential issues and risks early on.
Implementing an internal testing suite addresses this issue as it enables banks to design and run their own test cases, but building out end-to-end test cases using this method requires significant investment into a large-scale, technical project that demands considerable time, effort and input from skilled subject matter experts. Even more challenging is maintaining these test cases.
Certainly, banks cannot afford to invest in such a project each time there is a regulatory or system update, especially given the number of different rails that they can be connected to and therefore the degree of end-to-end testing required.
Testing with partner banks, while an extremely useful form of end-to-end testing, is not straightforward either, as a bank is fully dependent on the availability and readiness of another party. It is in a bank's interest to test as soon as it is ready, and waiting for another bank to catch up causes unnecessary delays, inefficiencies and frustration. A further restriction is that only use cases that the partner bank is able and prepared to perform can be tested.
Partner bank testing also requires careful planning and coordination and a strong relationship with a bank on the rail in question, which isn't always possible when testing in new geographies. Moreover, end-to-end testing is important for verifying the impact of an individual bank's own system upgrades, and for troubleshooting issues encountered in live payments processing. But because the partner bank approach is usually only undertaken when onboarding to a rail or when a new regulatory standard is being introduced, it is therefore not a good fit for these use cases.
As payments testing becomes an ever-larger part of banks' and PSPs' ongoing operations, the need for a practical, optimised approach is clear. This thinking has only been reinforced by the recent global migration to the ISO 20022 messaging standard, which has been massively complex and underestimated by many, resulting in some banks not being ready. This, in turn, contributed to rollouts being delayed and increased preparatory pressure to get everything validated to ensure a smooth "go live". Certainly, there is a growing desire among banks and PSPs to manage their own testing processes more effectively.
| Testing type | Challenges |
|---|---|
| Internal testing suites | Costly, with investment in maintenance updates required to ensure ongoing compliance and risk assessment |
| Focused on bank system integration testing, and not on the end-to-end testing that requires testing with rail and bank (real or virtual) | |
| Skilled input needed, with the requirement to design your own test cases | |
| Significant time and effort | |
| Complex | |
| Market infrastructure tools | Limited use cases available for testing, focused only on certification from a market infrastructure perspective |
| Usually no history of tests conducted | |
| Usually doesn't support test automation | |
| Bank-to-bank testing | Fully dependent on another bank |
| Strong relationships in the country/region required | |
| Limited test cases, and dependent on what the other bank is able to support | |
| No history of tests conducted and no control or visibility of the payment messages on the partner bank side | |
| Coordination challenges (e.g. availability, time zones, same level of readiness needed) |
As such, pioneering self-service capabilities are being introduced in the form of a simulated banking partner - a virtual "buddy" bank. Acting like a partner bank, the simulator is directly integrated with a real-time payments scheme or infrastructure through a standard interface, enabling independent, automated, end-to-end testing for both sending and receiving payments - and making getting started seamless. And, since the bank already integrates with the scheme, there is no additional effort required by its IT team to get things working.
“Pioneering self-service capabilities are being introduced in the form of a simulated banking partner – a virtual “buddy” bank.
All of this means low investment and cost of ownership for the bank in terms of time and resources. |
As well as facilitating compulsory tests, these solutions are fully configurable. A bank simply provides a list of transactions - from delays, duplicates, late payments and volume testing to the most obscure, unlikely types of scenarios - and those complex use cases will be constructed by the simulator. Such comprehensive testing allows banks and PSPs to investigate and iron out the scope of situations it may encounter in advance, thus avoiding uncovering potentially sensitive issues when testing with another bank.
With automated regression testing another key feature, which can be easily integrated with their existing regression testing ecosystem, banks have the assurance of ongoing system robustness, reliance and compliance, with greater cost efficiency due to freed-up resources and the eradication of the need for ongoing investment into testing in accordance with future standard and configuration shifts.
This ability to perform continuous, rigorous end-to-end testing automatically, and with far greater
control, is an optimised means of reducing risk for banks and PSPs. This, combined with overall cost
savings and reduced strain for overstretched internal teams, makes this form of testing a true
gamechanger.
“The ability to perform continuous, rigorous end-to-end testing automatically, and with far greater control, is an optimised means of reducing risk for banks and PSPs.
The XMLdation Virtual Buddy Bank for example (see Figure 4), is a market leading tool with EBA Clearing approval to connect directly to RT1. It is fully aligned with the suite of pre-configured EBA Clearing RT1 test cases, thereby enabling users to send and receive test payments, and run all the test cases needed for certification, as well as their own scenarios. Buddy Bank is positioned to support testing for direct and indirect participants and, in the case of indirect participants, they can access the tool if their direct participant partner has that capability.
Since the Virtual Buddy Bank is connected to the rail, it is easily reachable by banks' core systems. The RT1 Virtual Buddy Bank is already reachable by banks on TIPS since TIPS and RT1 are interconnected, and so the RT1 Buddy Bank can also be used by banks connected to TIPS for their end-to-end testing.
XMLdation is currently extending the Virtual Buddy Bank and adding support for Swift CBPR+ and STEP2, OCT Inst and R2P, and plans to expand capabilities to other instant payment rails across the globe as client needs dictate. As support for additional rails and overlays becomes available, banks and PSPs will therefore be able to use a common solution for the end-to-end testing of all their rails - indeed, many banks will connect to in excess of 20 - something that is becoming increasingly important as the global, real-time cross-border payments landscape takes shape.
“The XMLdation Virtual Buddy Bank is a market leading tool with EBA Clearing approval to connect directly to RT1.
Interoperability between different domestic systems is set to grow, with G20 initiatives and Project Nexus currently at the forefront of real-time cross-border payments developments. Nexus aims to enable the connection of multiple domestic instant payment systems, standardising the way these systems interact using a centralised interface.
“To ensure the robustness and interoperability of regional and domestic real-time infrastructures and interconnections between rails, end-to-end testing on an international level will become essential.
As these global initiatives become more established, automated testing must evolve in tandem. To ensure the robustness and interoperability of regional and domestic real-time infrastructures and interconnections between rails, end-to-end testing on an international level will become essential. Here, a buddy bank simulator could be integrated as another layer, enabling testing of all the local instant payments schemes, and the testing and validation of the overall infrastructure.
Such an approach would remove the need for banks to find partner banks and testing windows for rails in every country that they want to operate, thus enabling far greater ease and efficiency in terms of roll-out. For PSPs, which are increasingly looking to provide direct rail connectivity to their clients but find identifying a partner bank to test with a particular challenge, the benefits are also evident. In addition, operating in multiple markets, each with varying regulations and standards, brings great complexity, and an automated buddy bank can provide banks with the assurance that tests are up-to-date and factor in new developments to ensure ongoing compliance. Coordinating effective testing with global initiatives could ultimately act as an enabler for real-time cross-border payments adoption, and is a vital tool for banks with ambitions for growth.
Virtual buddy banks have the potential to revolutionise real-time payments testing. With today's real-time payments landscape in transition, and industry standards ever-evolving, banks and PSPs require comprehensive, configurable and cost-effective end-to-end testing methods to minimise risk and deliver new capabilities seamlessly to clients.