Practical ISO 20022 Testing

Introduction

ISO 20022 is perceived as "new" but has in fact been around for a long time - nearly 20 years. Only in recent times has it gained significant momentum beyond a core community of standards geeks and begun to influence the operational and technical strategies of financial institutions and their customers and partners. Now, multiple national and international financial market infrastructures around the world either have adopted, or are committed to adopting ISO 20022 as a messaging and data standard.

SWIFT will introduce ISO 20022 for cross-border payments from November 2022, allowing coexistent operation with the legacy MT payments messages until November 2025. At that point, all cross border payment traffic using the SWIFT network will be transacted using ISO 20022. Multiple national payment schemes are moving in the same direction. In Europe, SEPA has been using ISO 20022 for a long time and both TARGET 2 and EURO 1 are working towards 2022 migration deadlines. CHAPS in the UK is set to move to like-for-like (equivalence with existing message structures) in June 2022, and full implementation for direct participants in February 2023. Fedwire and CHIPS in the US have announced intent, but postponed committing to firm dates at time of writing.

As ISO 20022 has gained strategic momentum, and market infrastructures have imposed deadlines on participants, tactical considerations have begun to kick in for those participants and ripple through multiple aspects of their operations. ISO 20022 is both very rich (in terms of the possible range of data carried) and very flexible (by virtue of its design and the rigour with which extensions and restrictions are managed). This means that adoption of the standard is often likely to impact more than just the immediate network-facing business areas and applications. The most obvious and often-quoted example of that is the structured remittance information introduced by the ISO 20022 payments message types. But even a simple basic aspect of ISO 20022 like fully structured name and address data for beneficiaries (and other actors in the payment flow) facilitates more accurate KYC and compliance checking and thus widens the impact of adoption.

If you are here, our assumption is you already understand the basic ideas behind ISO 20022, you know where it has come from and you are familiar with its structure and evolution. What you need is to know how to approach implementing and testing with it, probably in the context of a specific payment scheme or national/international market infrastructure.

The ISO 20022 landscape

To begin with, it is important to be clear about what we mean by the term "ISO 20022". It is a well-defined standard with well-documented specifications and a healthy ecosystem of users, contributors and industry bodies. The underlying business model gives rise to sets of message type definitions, each of which (re-)use a standard set of components. The message structures are most commonly (but not exclusively) realised as XML schemas, in the expectation that physical transmission will take place by means of XML.

ISO 20022 is used as the baseline standard underpinning many country, region and industry-specific payment schemes and market infrastructures. Often, these schemes and infrastructures impose their own extensions and restrictions to the base standard resulting from the local constraints and business practices being supported. In other cases, supranational bodies such as High Value Payments Plus (HVPS+) create additional rules and constraints (or relaxations) that add further complexity to the picture.

The net result is that while ISO 20022 represents a single, unambiguous standard, it is necessarily extended and restricted according to the needs and intentions of each particular usage of it by national and international infrastructures. At first, this may seem like simple and tedious repetition of the historical way in which the financial community has modified, abused, bifurcated and extended SWIFT-based message "standards" and rendered them hopelessly and bewilderingly disparate.

But the good news is that this specialisation has been well-managed by SWIFT and the ISO 20022 community so that it is reasonably straightforward to understand. There are well-established mechanisms, practices and tooling to support the process of creating, negotiating, socialising and publishing market-specific variants of the base standard. For the most part, this ecosystem lives in and revolves around the SWIFT MyStandards platform that gives access to the base standard and most (if not all) of the variants and specialisations layered on top of it by various industry bodies.

Fig. 1 - The SWIFT MyStandards Portal (source : SWIFT)

Schemas can be downloaded from the MyStandards portal. Validation rules are documented and detailed against the data structures they relate to. MyStandards is effectively the golden source for the basic message structure and intra-message semantic validation logic. This makes it an essential reference tool for building test data and optimising unit test case coverage.

Our approach to testing with ISO 20022

When formulating an approach to testing in an ISO 20022 context, it is important to consider the rules, constraints, relaxations and variations imposed by the various actors involved in the particular scheme or application of concern. Figure 2 below illustrates Incept5's approach to this, using the example of the UK's high-value payment scheme (CHAPS) that is scheduled to begin like-for-like testing at the end of 2021.

Fig. 2 - Dimensions of ISO 20022 Testing - CHAPS (UK High Value Payments)

The first dimension considered in this approach is summarised by the 3 horizontal layers in the diagram.

1 Message Syntax describes the rules and constraints governing the individual data elements and attributes making up each message type used in the scheme. In ISO 20022, the majority of such rules and constraints are expressed in the XML schema definitions of the individual message types. This covers fundamental properties of the data such as type, size, cardinality and so on, and can largely be summarised as testing for schema-validity.

2 Message Semantics describes the rules and constraints that are defined on top of the basic data structures. These are usually expressed in ISO 20022 as "validation rules" that detail additional constraints on the message content over and above basic syntax checks. A simple example from the HVPS rules defined for the CHAPS pacs.008 message is the HVPCategoryPurpose1 rule that says "If CategoryPurpose is used, then InstructionForCreditorAgent/Code/ must not contain CHQB or HOLD". This neatly illustrates the basic ingredients of most such rules - they reference multiple elements within a single message and apply constraints on the existence, content or number of those elements.

3 Scheme/Network Protocol describes additional rule logic that may be imposed by the payment scheme or network over and above either of the other two sets of constraints. Examples of this type of rule are the L4L (Like-for-Like) rules imposed by CHAPS during the initial adoption period where equivalence of content between the MT and ISO 20022 messages is enforced by the scheme.

The second dimension is represented by the four grey vertical columns in the diagram, which describe sets of rules imposed by the basic ISO 20022 message definitions, and extensions/restrictions layered on top by other concerned entities - in this case the CBPR+ and HVPS industry groups, and the individual payment scheme itself. This pattern is commonplace across the various usages of ISO 20022 within financial infrastructures.

Rules are likely to exist in many of these groupings for any given scheme and message type - illustrated for CHAPS in the diagram by the green ticks. Consequently, minimum baseline testing must exercise and demonstrate the creation, sending, receipt, parsing and validation of messages adhering (and not adhering) to each of these sets of rules.

In fact, in the CHAPS example, the keen-eyed will have spotted a third aspect to the problem space. CHAPS has opted for a period of co-existence between old (MT) message syntax and ISO 20022. During this period, the ISO 20022 messages are further constrained to support only data that is also valid in the context of the existing ISO 7775/MT message set - hence "like-for-like". That means there are use cases involving translation between the two sets of messages, which in turn introduce a further set of testing needs. From the perspective of an institution participating in the scheme, multiple internal systems will be handing traffic off to the scheme and consuming traffic from it. Some of these may already be ISO 20022-native, but the likelihood is that many will not, and will therefore still be producing ISO 7775. The conversion to ISO 20022 that will be part of the architecture must also be tested to the same extent and against the same landscape of rules.

Each of the layers described here need to be properly accounted for in a comprehensive test strategy. At a minimum, unit tests for each message definition (XML schema) and associated rules must be in place, exercising the full range of possible pass/fail conditions. Given that foundation, wider-ranging integration and end-to-end transaction tests can be constructed on top.

Down to the detail

One commonly-used message structure in the CHAPS scheme (and many others) is the pacs.008.001.08, or Single Customer Credit Transfer. This ISO 20022 message type is, broadly speaking, the direct equivalent of the existing SWIFT MT103.

In the context of CHAPS, this message is sent to instruct the movement of funds between participants' accounts in the RTGS system.

Fig. 3 - CHAPS Message Flows (source : Bank of England)

Within the diagram in Figure 3, the area highlighted shows (Step 1) that Participant A can use a pacs.008 message to instruct the RTGS system to debit their account and credit Participant B.

(Note that the pacs.008 is just one of several message types used by the direct participant. Note also that each ISO 20022 message has an "MT" equivalent representing the existing CHAPS messages with which the new types will co-exist. This highlights one of the testing needs mentioned earlier - the conversion between old and new structures.)

Participant A is responsible for ensuring that a well-formed and valid pacs.008 is sent to CHAPS. This may also entail ensuring that MT103 messages originating from existing applications that the participant has left unchanged for the coexistence/like-for-like phase are legitimately transformed to the equivalent pacs.008.

Participant A must therefore be able to demonstrate, comprehensively, that each of the 'layers' of syntax, semantic and scheme-based rules are accurately observed by applications facing off to the CHAPS scheme. Incept5 provide a framework for doing this, based on standard sets of pre-built unit tests covering each layer of rule logic and delivered as industry-standard JUnit test fixtures. By way of illustration, here is the list of tests exercising the full set of rules covered for the CHAPS variant of the pacs.008.001.08:

Fig. 4 - CHAPS pacs.008 rule test fixtures (source : Incept5)

Let's pick just one example from this list and look at what is involved.

The rule HVP_NameAndAddressRule is defined in the CHAPS ISO 20022 specification as follows:

"The rule restricts the total length of Name and Address information to a maximum of 4 lines of 35 characters in line with MT NameAndAddress format. If Name is longer than 35, then AddressLine must not occur more than 2 times, else AddressLine can occur up to 3 times."

The rule is associated with the data type FinancialInstitutionIdentification18__1 which is defined in the XML schema provided by CHAPS.

The first testing 'gotcha' to be aware of is that this data type is used in more than one element of the pacs.008 - namely DbtrAgt (Debtor Agent), CdtrAgt (Creditor Agent), and IntrmyAgt1 (Intermediary Agent 1). Tests therefore need to exist for all three like so:

• (Dbtr)

  • Fail_001 : name>35, count(AdrLine)=3
  • Pass_001 : name>35, count(AdrLine)=2
  • Pass_002 : name\<=35, count(AdrLine)=3

• (Cdtr)

  • Fail_002 : name>35, count(AdrLine)=3

  • Pass_003 : name>35, count(AdrLine)=2

  • Pass_004 : name\<=35, count(AdrLine)=3

• (IntrmyAgt1)

  • Fail_003 : name>35, count(AdrLine)=3

  • Pass_005 : name>35, count(AdrLine)=2

  • Pass_006 : name\<=35, count(AdrLine)=3

We must test not only the failure condition in each case, but also the various ways in which the rule is NOT broken. Hence there is a bare minimum of three unit tests per possible usage of the affected data type, giving nine in total, just for this one rule.

These test cases are implemented in the Incept5 CHAPS library as a JUnit test fixture. The simplest way to run them is via JUnit, although (obviously enough) they are easily incorporated in other commonly used testing frameworks:

Fig. 5 - HVP_NameAndAddressRule JUnit tests (source : Incept5)

Other aspects of a comprehensive testing strategy

So far, we have considered functional unit testing of individual message instances - can the required message structures be correctly supported as defined, and how do we validate and verify demonstrably that this is true.

Another aspect of a comprehensive testing strategy, mentioned above in the context of CHAPS, is the need to handle like-for-like scenarios where 'old' and 'new' co-exist for a period of time before full ISO 20022 adoption. This means that end-to-end scenarios initiated using existing ISO 7775 ("MT") messaging must be tested alongside those using ISO 20022, to ensure that any conversion processing is performing correctly and not introducing errors or inconsistencies.

Stress testing at high volume may also be a requirement dependent on the nature of the organisation and its role in the payment ecosystem. Incept5 provides facilities for quickly generating very high volumes of test traffic (hundreds of thousands, or even millions of messages) that can be used to ensure that systems are capable of handling spikes in volume.

Conclusions

We have walked through the Incept5 approach to testing against ISO 20022 from top to bottom, zooming in on a single rule within a single message structure.

Again, this is just one example from just one message type used in just one payment scheme.

There are over 35 distinct validation rules applied to the pacs.008.001.08 in a CHAPS context, and a dozen other message types constituting the total message set for the scheme.

Next, consider that this only covers the "like-for-like" period, and that the full ISO 20022 implementation defines an extended set of rules and schemas that require equal depth of test coverage within a relatively short space of time.

Finally, from the perspective of a financial institution operating in both domestic and cross-border payments, it will be necessary to have considered this level of detail across multiple national schemes as well as the SWIFT CBPR+ guidelines.

For further details on this and other aspects of managing your participation in ISO 20022 initiatives, please do get in touch with us at www.incept5.com/contact