SWIFT’s experience with major initiatives across multiple geographies to enable and encourage the adoption of harmonized practices in an environment where no 2 businesses are alike led it to establish a best-practice approach to implementing interoperability. 

The central component of successful projects says that each initiative builds a single, central, and complete view of all data fields, standards, and workflows across all impacted business processes, and their interdependencies. 
Typically, one of the first tasks would be the “as-is” and “to-be” data analysis across existing and future data and business flows. Building a single, central view across all of the data ensures that design, integration, implementation, and ongoing maintenance are accurate, fast, and efficient. 

The approach promoted by SWIFT to achieve this outcome links the impact assessment and solution design into a seamless process. SWIFT states that this process safeguards the development and implementation of effective and efficient solutions while ensuring minimum disruption to normal business, by ensuring that business requirements and industry-level considerations are factored into the development of interoperable solutions. 

The process also ensures that a cross-functional holistic perspective guides the development process, which includes ensuring the balanced involvement of third-party IT service providers and commercial businesses. 

As described below, the best-practice approach championed by SWIFT includes impact assessment and solution design process flows. Each of the steps shown in the image is described below. 

An interesting insight is that the impact assessment and solution design flow in opposite directions in terms of macro in contrast to micro considerations. The impact assessment process first looks at the wider operating environment from a macro level, then steadily narrows its focus down to a micro perspective. 

Macro-type questions that would drive the assessment include: “what gap would the proposed message change fill, or what opportunity would it create compared to the current enabling environment, for which stakeholders and how?” 

Micro-type questions that drive the assessment may include: “why would a business adopt this proposed message change, and in which sub-sector of the finance industry do such businesses operate?” 

In contrast, the solution design process starts with micro considerations and ends with macro considerations. The process begins by assessing intra-firm considerations, such as “will the proposed change positively impact the current process flows and performance of the target stakeholder; and if so, how?” 

Subsequent assessments focus on quantifying relationships between inter-and intra-firm considerations, such as “what enablers are required to ensure the proposed benefits are realistic and realisable, and where and why they presently do or do not exist?”

ISO 20022 Impact Assessment


The impact assessment process has 4 distinct steps: business assessment, technical assessment, roadmap, and business case. 

Business Assessment: This stage reviews the firm’s current ISO 20022 landscape from an external business perspective, summarizing dependencies, business flows and message types with trading partners (for example, other financial institutions), customers, service providers, and market infrastructures. This means answering: 

         i. What functions will the firm need in order to provide better service or increase efficiency? 

       ii. What customer requirements do the firm need to meet, and thus what capabilities does it need to introduce?

Technical Assessment: This stage reviews the landscape from an internal perspective by summarizing internal data flows and message types, including any new functions that may be required. This means answering: 

         i. What existing applications will be affected? What are the needs, either to produce or to use                          ISO20022 data? and 

         ii. What new capabilities will be required?

Roadmap: The Roadmap outlines the future-state business architecture and general business case for a specific communication change being proposed. Factors considered during the process of establishing the “to be” environment and enabling factors are the scope of the project/investment (including phasing in the new messaging and the expected organizational impact by business area, system, or geography), and addressing any items raised during the impact assessment. The roadmap should list, by phase, impacts on/involvement of: 

          i. External organizations, 

          ii. Internal business applications, and 

          iii. Message flows, message types, and versions. 
         
Each impact should be included in the timetable, and then agreed upon by all stakeholders so that the broader interdependencies are fully understood, and the need for action is recognized. 

Business Case: The expected costs and benefits of the proposed roadmap across involved stakeholders and each phase of the proposed change are assessed to develop a business case for the proposed change. Costs included in the assessment are categorized as one-off and recurring costs. Benefits are categorized as quantified cost savings, incremental revenues, and strategic benefits.

ISO 20022 Solution Design 


The solution design process also comprises 4 distinct steps/layers: business, data, application, and technology.
 
- Business Layer: This phase of the design looks at the current design of the business process flows and the impact that the proposed change is expected to have on business processes. This phase also determines the guidelines and definitions that need to be considered in the development and eventual communication of the intended change(s).

- Data Layer: This stage of the development process includes examining the extent to which the proposed changes align with the ISO 20022 open business model and the existing ISO 20022 Data Dictionary. Where possible, underlying ISO 20022 data elements will be used in developing the new initiative, thereby helping to ensure its smooth integration alongside current systems and processes. 

- Application Layer: The requirements for ensuring the effective and efficient operation of the software and associated tools are assessed. This includes, for example, assessing the impact of the proposed change on existing applications, middleware, interfaces, connections, and converters. The ultimate purpose of the development phase is to ensure harmonization across new and existing applications. 

- Technology Layer: The final phase of the development process is to ensure that the networks and processing systems that underlie the successful implementation of the change are adequate in terms of their speed, capacity, bandwidth, and any differing protocol provisions associated with message size or syntax. The scope of this work may extend to the development of recovery and resilience procedures. 

As a SWIFT partner, we at Nth Exception collaborate with Banks and Financial Institutions to analyze, solutionize, and optimize their ISO 20022 adoption leveraging our experience and purpose-built tools. 


Extract from publicly available resources.