ISO 20022 for Payments for Financial Institutions - CBPR+
Have you ever wondered how the money you send using your bank account to pay for bills, groceries or Friday's blunders gets to its destination? Of course not! Not unless the money doesn't reach its recipient.
These are very intense times in the banking sector due to changes in a certain bank network – changes that are forcing banks to implement very significant upgrades and changes to their technology stacks so they may still participate in the network. According to some business analysts, these are the biggest changes in the last 20 years! I am, of course, talking about the SWIFT network which is currently undergoing ISO 20022 upgrades.
The ISO 20022 contains within itself many changes to be rolled out, but going over all of these changes, in the context of quality assurance, is out of scope for a single blog post, so I will focus on a single but rather significant change in particular - cross-border payments and reporting (CBPR+).
SWIFT 101
You can think of the SWIFT network as a shipping port used by banks to ship money or information. The network receives a message from a bank and understands how to route it further to the beneficiary bank. While using the SWIFT network might not be relevant to most people who don't make cross-border multi-currency payments, it does matter to those who do business abroad or in currencies other than the national ones of the country where business is being done.
SWIFT supports a wide array of currencies – USD, EUR, CHF, GBP, and a whole slew of others. This means that it's the obvious choice for banks to use in order to send payments that are not supported by other payment networks, such as SEPA, TARGET2, or other networks that exist between some banks. In essence, you use SWIFT when you want a message to reach its destination, but you have no other means of transfer, as using the network is not cheap for small remittances.
What is CBPR+ and Why is it being implemented?
As already established, CBPR+ stands for cross-border payments and reporting, and, as the name suggests, this part of the standard describes the new format of payment messages that are being used within the SWIFT network. The standard describes replacement for category 1, 2, and 9 messages. For the sake of simplicity, think of all these categories as one type of message – as a channel of communication between the bank and the SWIFT network.
So why bother implementing the new message type at all if it causes so much headache? Well, because the old message format has severe limitations. The new message format is based on XML and is referred to as MX messages. The old format messages are MT messages, which are proprietary and only used by SWIFT.
Even if the term XML makes your head spin (shout out to developers), it is still less of a pain to deal with than proprietary MT, by the merit of XML having native support in a lot of programming languages, and, while I'm sure there are libraries to deal with the proprietary MT standard, the MX might seem more 'natural' to most due to XML being widely used – HTML is based on XML after all.
However, ease of development is probably not so relevant to banks that are trying to implement this standard. What they might be interested in is the amount of additional info that you can put into MX as opposed to an MT message. While there are some limitations to what you can put in an MX message, they are nowhere near as limited as MT messages, and MTs cannot be extended either. To change how MX messages are handled, all you really need (for optional tags) is to change up the XSD schema and that's about it. This gives the new MX standard the longevity that banks oh-so love.
You might be wondering why implement these changes now of all times. Technological progress has been significant in the last 20 years, and bandwidth cost has never been cheaper, so if banks don't want to be left in dust they have to adapt, ergo, to new changes.
Where do testers come into play?
Banks are doing their job correctly if you don't even notice them doing their job. For that to happen, everything has to work correctly and without a hitch. To ensure that, quality assurance engineers are involved in all of the software development lifecycle phases, as it's cheaper to fix discrepancies if they are discovered sooner according to ISTQB, and our QA engineers have a keen eye for those.
Each organization has its own SDLC guidelines described already, so we adapt to those, however, the job we do doesn't really change in the greater scheme of things, since, as mentioned previously, we participate in all of the phases – the pace between projects might change, but our job of ensuring quality does not.
Our main task is to be a sort of a medium between developers and business analysts, since devs might not necessarily be well-versed in the business side of things, and BAs might not know everything about implementation of the bank's core system which processes these messages. After new requirements are described, and devs have implemented the changes, we have to check that the integrations are working as they should. QA has to know a little bit of everything and must be open to new information and concepts.
The process
I will now describe the process of how testing activities might occur. Note that this is a very broad overview of very intricate process peculiarities, which are also confidential, as such, I will describe the general idea but not the specifics. The specifics for each bank are different, so it doesn't make sense to talk about them. Also, these are not testing phases as described in ISTQB – just the general process.
Requirement analysis
Depending on whether the bank opts to introduce a new system for processing payments using the new standard, or upgrade the existing system, requirements describing how the system should behave will have to be created by BAs and analyzed by QAs. This process usually takes the longest, and for a good reason – if potential defects are caught and reported during this phase, then they are cheaper to fix than if they were caught when the change was already implemented by devs.
During this phase, we mostly work with BAs since we don't always possess domain-specific knowledge – terms and methods specific to banking in this case - so we get explanations from business analysts, and, together with developers, try to figure out how such changes could be implemented, what problems could be caused by such changes, and if any specific data or tool is needed in order for us to test it.
Test design
After requirements have been analyzed, and any discrepancies within them figured out, we start writing test cases in order to test these changes. This phase can also take quite a while depending on the scope of changes, but it's also quite important to write good quality test cases so they can be re-executed during regression if the need arises, as such, it might be a good idea to spend a bit more time in this phase. A good test management tool can help speed up the process.
Once tests have been written, the scenarios are handed over to BAs for them to check if the most important flows are covered by the tests. If something's missing, then more tests are created, but if everything is in order, then testing of the system can be started.
Testing of the test object
This is the fun part of the process (depending on who you ask). When changes are implemented by developers, QA starts system/system integration tests. This is the phase where defects start piling up, and both developers and testers work together in order to fix them all.
New changes are usually tested by more experienced QAs because they already have the intuitions necessary to find unusual and obscure defects. If new changes are being tested on a system that already exists in the production environment, then regression testing may also happen in parallel. Regression testing is oftentimes carried out by testers who are new to the project because the features to be checked are well-known and understood, so it's harder to make mistakes.
Once system tests are done, User Acceptance Testing (UAT) tests should happen – business analysts are involved in these because they possess domain-specific knowledge, which they use in order to find defects that QA engineers with mostly technical backgrounds may not have noticed.
Post-release activities
Once the system is released on production, testing activities do not stop. When a new change is deployed on production environments, it's being monitored closely for any unusual activities. Bugs occur even in production, so QA has to be ready to test them ASAP. The length of this phase depends on the bank, but it's a good idea not to skip it.
Conclusion
Changes this big usually take decades to implement in huge organizations, such as banks, as it's not easy for everyone involved to align with them, but SWIFT expects banks to be ready to drop support for old MT messages by 2025.
It might seem impossible to do for some, but if a proper testing process is introduced, then it's certainly possible to make the change without loss of quality. While quality does not come cheap, in the long run, it's cheaper than dealing with regulatory issues, and possible loss of funds due to the faulty behavior of new or upgraded systems.
Don't hesitate to contact us if you need assistance in certifying your product. Our ISO Advisory experts are ready to help!