One of the most interesting and prevalent changes to the current payments landscape is the accelerating adoption of ISO20022, an initiative to simplify and standardise payments. What is there not to like? So far so good; but what if ISO20022 is mutating? How do you adapt when things are not quite as simple as you first thought? Are development teams speedily able to cope with change?
Jack of all trades, master of none
ISO20022 is broad enough to cover many bases, many devices (NEXO), real time/immediate payments, SWIFT, and central banks. The consequence of course is that this increases clamour for change, as specialists all want to tweak the ISO slightly to accommodate their own worldview. And they usually demand this change straight away.
Changes then come thick and fast and people are sorely tempted to break and bend the rules. So, you see embedded ISO8583 messages and fields used for things they shouldn’t be, just for it to be convenient. And before you know it, in the ‘real world’ it is no longer a standard. Standards are always useful, in the way that planning is always useful, but the standard and the plan can change along the way.
Changing standards
If there were dependable standards, there would be greater confidence in building and releasing new payments features. There would be more baselines to compare with, more reusable components and, as a consequence, more confidence when releasing them into production environments. So, the challenge is to build as much confidence as possible within the constraints of internal and external pressures to get things done, to keep up, to innovate, and to extract value from your software.
Deviation from a standard, or the adoption of multiple versions of it, isn’t going to hold up your development function too much. However, what it will do is present new and significant challenges for those who wish to test and release your software. So how do you test a standard that isn’t a standard?
Here are a few observations to help you build a checklist.
It’s not just the standard
A new technology message exchange will use the ‘best’ technology it can. At present that battle is being won by ISO20020. However, if you take the simplest form of immediate payments as an example, you have to consider what kind of information 50 fields in this shiny new format need to hold and process.
This information will generally be held on multiple systems within a financial institution, including Ledgers or AML check components. The temptation is to think the information is from the dreaded ‘legacy’ systems, such as those holding balances in ledgers, but in reality it could be from a microservice or an Open API call. The aggregation of this data ahead of an ISO20022 call is complex and has many ‘edge’ cases. As we connect to more and more systems, the fundamental question is whether the test plan can cope. And if it can, then can we actually execute the test?
It’s always quicker to cut corners
If you want to play in the new space you must be quick, and to be quick you might have to cut corners at the expense of quality and resilience. To fix it later is often the only approach when confronted with an immoveable deadline, but if you have lots of people doing this, then the shiny new scheme is being compromised. Robust testing can fix this but only if you have a robust automated test platform which everyone has access to. If you’re relying on test simulators, which do not test the complete infrastructure end to end, then you’re heading for a problem. A major problem.
Testing is more important than ever before
If you can’t test accurately, you can’t deliver. Without a unified view of all the systems in the test, you are going to be slowed down, resulting in a desire to cut corners. The result is that your test infrastructure will be brittle, less able to expand and less able to be re-used. The desire for pace is building up bigger problems for the future.
You need to be able to simulate everything, and DevOPS means you need to simulate multiple versions of everything. It must be globally accessible 24/7 and able to cope with any change in the plan. If the test plan (or execution of it) is fragmented, it becomes impossible to automate multiple components, and you cannot derive value from multiple components without complex frameworks.
The answer to this is a change in the approach to launching new technology. ISO20022 will not be the standard that everyone thinks and hopes it will be. We all need to be prepared for a mutation in the same way that the developers of COVID-19 vaccines are preparing their subsequent adaptation.
Where are we heading?
Some people in the industry are already gaining an advantage over their competitors by investing in testing platforms able to accommodate the micro-changes to ISO20022 anticipated over the coming weeks, months, and years. Their innovation teams must work with a test platform accessible globally 24/7, able to simulate every component of an infrastructure, and providing a true framework for success. In a world where any outage becomes instant and global news, the reputational risk of cutting corners is now far too great.
About Anthony Walton
Anthony Walton is the CEO and founder of Iliad. A veteran of 25 years in the payments industry he started his career with the software division of Stratus Computer (S2). This led him to work in Frankfurt, Germany where he founded his first company DNA in 1996 with the intention of bringing an open system switch and test tools to the payments market. Following a merger with EPS GmbH in 2001 these products (ASx and ASSET) were acquired by ACI in 2004.
About Iliad Solutions
Iliad Solutions has over 25 years of experience in payments. We have been at the forefront of building, implementing, and supporting major payment solutions. Our experience has led us to develop the most comprehensive and resilient test solutions available in the world today. Iliad’s global customer base trusts us to take the risk out of payment testing.
Every day we send out a free e-mail with the most important headlines of the last 24 hours.
Subscribe now