The Nightmare at ISO 20022 Standards Street

What about ISO 20022 is really keeping you awake at night?

If you are like many financial institutions, you are eagerly awaiting ISO 20022 so that your customers and partners will have to start sending you richer, better structured data and payment messages in a single, globally consistent standard. ISO 20022 will minimize the need for complicated messaging hubs and complex parsing engines that translate inbound payment data into usable formats for origination, processing and settlement processes. But then, you wake up in a cold sweat with a chill running down your spine as you’re quickly confronted with the devil on your shoulder chiding you about modernizing, replacing or rearchitecting your existing payment systems and centralized messaging hubs to meet the same standards. This dream has turned into more of a nightmare.

To prepare for ISO 20022, you have likely read countless articles and posts about the “best” migration approach. Most start with an assessment of the payments landscape with a lens toward understanding the impact of ISO. This is typically followed by a lower-level application and data assessment that informs a retention, modernization or migration plan. These plans are then sequenced, funded and executed resulting in either an updated, compliant application or the migration of data to a new commercial-off-the-shelf (COTS) software or software-as-as-service (SaaS) solution. Although oversimplified, the program above is not new. Enterprises have been updating, replacing and rearchitecting software for 30+ years. If it isn’t the development work, what is keeping you awake at night?

In a word, it’s risk

Simply put, ISO 20022 dictates how money electronically moves between financial institutions. As expected, these standards impact foundational banking activities that are both business-critical and highly regulated. Failures among those activities and processes can not only result in fines and penalties but also significantly erode confidence in the bank. On a personal level, failure can result in job loss and be career limiting/ending (hence the nightmare!). Changes to existing payment systems that process and formulate these intrabank messages are not complicated, assuming the data is present. The challenge is guaranteeing that the changes are successfully deployed, properly configured, performing at expected levels, meeting security policies and not breaking anything currently working/running in production. For many large companies, this quality effort can represent 60% or more of the total program’s cost and time.

Reduce risk through testing

Rather than starting with a drawn-out assessment of what should be done and by when, I recommend starting with the goal in mind, namely mitigating risk of your ISO migration. In software development, risk is best mitigated through testing – period. With ISO, we know what the future state must be – it is defined in the standards. By employing test-driven development practices, we can build a collection of automated test cases to validate that inbound payment services can accept ISO 20022-compliant messages and outbound services can send ISO 20022-compliant messages. These basic functional tests can be integrated into a development environment or a DevOps pipeline and run as part of patch, upgrade or implementation effort. By running these basic checks during the development and installation, application owners and development teams can be confident that their applications can receive and transmit compliant messages. But the testing should not stop here.

Enhance performance

Now that the application is both compliant and performs to expectations, you must verify that it works in a production context and it´s fit for purpose.

Challenge if your application is fit for purpose:

• Did the changes inadvertently break the end-to-end payment process?
• Is the application/process receiving, transforming and sending the right data to the right applications in the right format at or in the right timeframe?

Ensuring the application is fit for purpose requires a combination of regression and integration testing. This is perhaps the most complicated and complex form of testing since it is critical to understanding data and process dependencies across the payment landscape. Leveraging advances in mock/stub testing frameworks and programs like the SWIFT (https://www.swift.com/standards/iso-20022) Test Sparring Partner program are just a couple of the strategies you can implement to support regression and integration tests.

Fit for purpose

Now that the application is both compliant and performs to expectations, you must verify that it works in a production context and it´s fit for purpose.

Challenge if your application is fit for purpose:

• Did the changes inadvertently break the end-to-end payment process?
• Is the application/process receiving, transforming and sending the right data to the right applications in the right format at or in the right timeframe?

Ensuring the application is fit for purpose requires a combination of regression and integration testing. This is perhaps the most complicated and complex form of testing since it is critical to understanding data and process dependencies across the payment landscape. Leveraging advances in mock/stub testing frameworks and programs like the SWIFT Test Sparring Partner program are just a couple of the strategies you can implement to support regression and integration tests.

Secure the enterprise

The last step is security testing. As changes are being made to payment services and application interfaces, ensure those adjustments have not compromised the security posture of the enterprise.

Three steps to cross-check security:

1. Verify encryption policies, coding vulnerabilities and perimeter configurations as these steps are critical to securing the payment process and associated data.
2. Employ tools that check for coding vulnerabilities and support both static/dynamic code analysis and pen testing, which are critical components in the broader testing.
3. Integrate these tools and tests into the development and deployment process (DevSecOps pipeline).

Confidence from compliance. Value from testing.

When brought together in a unified test plan, large and small enterprises can have confidence in both their compliance as well as in the success of ISO-related changes. While ensuring a successful ISO migration requires a lot of testing, there are several strategies that can be implemented to reduce the overall testing burden, increase reusability of testing IP and build a DevSecOps competency in your organization.

Benefits from continuous testing:

• A continuous testing platform can largely be leveraged across multiple applications and interfaces across your payment ecosystem.
• Investments made to build this continuous testing platform and competency in the enterprise will pay dividends over time as ISO standards continue to evolve.
• Tools, tests and practices developed for ISO compliance are entirely reusable for other development work, which is most important.

So why don’t you wake from the nightmare and instead start living the dream?

Topics

Automation
Cloud
Cybersecurity
Digital Transformation
Internet of Things and Edge
Data and Artificial Intelligence