The challenges

Over the last two years an international financial services company and custodian bank has effected a quiet revolution in the way it works with messages. It has addressed the issue of working with complex, frequently updated message standards – a challenge that affects all financial institutions. At the centre of the bank’s strategy was the adoption of an ISO 20022-based canonical model – a message standard controlled by the bank itself, for in-house systems to use across the board.

This case study explores the main strategy pursued and the key role that Transformer has played.

The background

The bank has been in business as a global financial institution for over 100  years and has an installed base of numerous systems that need to adapt to the changing needs of communication with each other; working with external counterparties’ formats and standards; taking advantage of services provided by external third parties; and complying with regulatory and reporting requirements.

The combined effects of these demands led the bank to the conclusion that it needed more fluency in its ability to work with messaging standards and that this capability would become an important business enabler as more standards are introduced and become more complex over time.

Furthermore the bank wanted to establish an internal level of control on standards and decided it would implement an internal canonical data model that would be based on ISO20022.

As standards grow ever more complex the critical task of transforming messages between one format or standard and another has presented a growing challenge. A solution was required that would allow the rapid adoption of this canonical model approach.

Working with messages – the legacy approach

The bank was not unusual in having several different approaches across the organisation when it came to mapping between various message standards, enriching message content, testing validity of messages against standards and carrying out maintenance. The different approaches tended to be associated with the deployment architecture and all used coding or scripting. None offered an approach that encouraged the bank to consider using as a single strategic solution to these problems.

Coding, scripting and XSLT based approaches were unsatisfactory because they became excessively complex, did not enforce the application of complex rules, created communication demands between analyst and developer staff, and were difficult to maintain and test.

A significant issue with the XSLT approach was that it was opaque – it hid the mapping logic, buried business rules in the code, and was difficult to document and maintain. XSLT code was also distributed across many systems, and did not support re-use, so it was hard to enforce the consistent application of validation and other rules. Furthermore implementing cross-field validations and rule checks was not possible.

Another area for improvement was the process for handling upgrades and change management.

Working with messages – requirements for the new approach

To select a new enterprise-wide solution to message transformation the bank was guided by the following considerations:

The need for a less technical approach, moving away from coding and scripting towards a model-based approach – reducing the need for the analyst/developer split and finding a solution that could be used by either;

Availability of regularly updated message libraries covering a wide range of standards – providing insulation from the complexity of published standards

Support for cross-field validations, such as SWIFT’s network validation rules

Ability to work with legacy and proprietary standards – COBOL Copybook, csv, Fixed Width, etc.

Support for re-use – a fundamental idea and benefit from a model based approach is that data structures (e.g. Party, Instrument, Address, etc.) can be modelled once and then re-used in different message instances. Similarly, these structures can be mapped (e.g. Party in 15022 to Party in 20022) once and re-used in message level mappings.

Pre-built mapping actions – the bank needed a rich set of mapping functionality to be already pre-defined so that the majority of its mappings and rules could be configured ‘out-of-the-box’.

Testing – testing at unit, system and regression testing levels needed to be an integral part of the solution

Performance and deployment – the deployables would need to execute in multiple runtime infrastructures

Continuous Integration – support for Continuous Integration was required

One approach for all message standards – The bank works with numerous standards or variants of standards and these are both proprietary as well as external published standards. The bank needed to ensure it could address the needs of any message standard.

One approach for all business areas – the bank is involved in many business areas including payments, securities, FX, asset servicing etc. and it needed a tool that could address the needs of any of its business areas.

Support – although the bank wanted to take control of building and maintaining its own projects it wanted to ensure that the level of support and if necessary services capability would be available to help in the delivery of projects

Having analysed options and carried out extensive proof of concept exercises with various departments and business areas, the Transformer tool from Trace Financial was selected and an agreement put in place.

Organising the Team

Having selected Transformer the question of the best practise approach for providing support for implementing projects across the enterprise was considered. One option was a federated approach where individual departments take control and implement their own projects using their own staff; an alternative option was for a centralised approach where a centre of excellence provides services to the distributed departments. For the initial implementation the bank decided that establishing a centre of excellence team would be best to get the new model and working practices established.

A dedicated Centre of Excellence (COE) was put in place around Transformer and implemented 250+ transformations in less than a year. The bank found that new team members were quickly trained and both IT and non-IT staff with diverse backgrounds soon became proficient Transformer users.

After a year of experience with the COE model, the bank found these advantages:

• Best practices established and used across projects
• Able to utilize common actions
• Faster development time
• Able to brainstorm within team and team code
• Familiarity with the tool allows the team to be more efficient and creative with solutions

Implementing the canonical model

The bank had previously used the SWIFT MT standard as the de facto message format for internal messaging. However because the SWIFT Standards release upgrades the MT formats annually the bank potentially needed to regression test every single system using this message standard every year.

The bank decided to adopt ISO 20022 as the new internal message standard for their canonical model.  A registration authority was established internally to govern the new standard (referred to as ‘BANKISO’).  This new BANKISO format allowed the bank to decouple its internal messaging from the impact of standards changes in general and the annual SWIFT Standards releases in particular, as explained below.

A new approach to SWIFT standards upgrades

The first project leveraging the new internal standard and Transformer enabled the bank to change its approach to the annual SWIFT Standards releases and to SWIFT testing generally.

The bank built a central hub called the Message Gateway, which calls Transformer to transform messages between BANKISO and the MT format, thereby isolating the bank from the MT standard.

At a high level, the solution looks like this:

The annual SWIFT Standards release thus requires an upgrade and regression test of only a single system – the Message Gateway – rather than every system that formerly used MT messages to communicate.

Enhancing SWIFT testing facilities

SWIFT supplies a single Test Network. The Message Gateway was thus forced to use a single environment for both User Acceptance Testing (UAT) and Integration Testing (INT).  This meant that the routing logic in the Message Gateway was different in the test environment than it was in Production (PROD).  It also meant that INT and UAT tests were being executed in the same environment.

To solve this issue the bank deployed Trace Financial’s SWIFT Tester – a Transformer implementation which responds with an ACK or NAK depending on whether the message is valid or invalid.  This effectively delivered a virtual SWIFT Test Network on the desktop. The team was able to test any SWIFT message at any time from the desktop.

This allowed the bank to establish separate UAT and INT testing environments, each of which matched their PROD configuration, simplifying testing considerably.  UAT Testing was insulated from Integration Testing, improving end user productivity in the UAT environment.

It would be possible to use Transformer to create further ‘Testers’ in future, to simulate any other required message standard and network.

Finally the same approach allowed regression testing for any changes and greatly increased confidence in the quality of any changes made.

Conclusion

The bank has taken a tactical and strategic approach with its Enterprise Messaging program.  Transformer offered the capability and flexibility to support both.  The bank acquired Transformer and put a Centre of Excellence framework in place around it as a strategic solution to the challenges of working with a large and diverse range of complex message formats. The bank was then able to establish an internal messaging standard and has migrated a significant number of systems onto this standard in a less than one year.  Where moving to the standard was not practical or cost effective, (when systems that were slated as end of life, for example), the bank leveraged Transformer to build proprietary transformations.

A tactical approach aligned with strategic goals has put the bank into a position to reduce from three messaging platforms to two in 2016, and reduce to a single messaging platform by 2020.  With over 80 systems leveraging messaging, simplifying, reducing and standardizing will bring significant cost savings in the longer term.

The bank sees the new approach as a major enabler and puts it in a great position to meet the challenge presented by working with messages of any type and any complexity.