ISO 20022 Implementation in FinTech Services

by Adam Sandman on

Introduction

One pivotal standard for the financial payments industry is ISO 20022. Due to be implemented in 2025, it provides a common framework for electronic data interchange (EDI) used by financial institutions in the banking, investment, and insurance sectors. It enables seamless communication, reduces operational risks, and facilitates cross-border financial transactions.

This whitepaper outlines how organizations can ensure that their software applications comply with ISO 20022 and are prepared to adopt the new standard in 2025.

Cash usage is becoming increasingly rare as non-cash or cashless transactions dominate our everyday transactions. The FinTech industry has driven this shift with digital wallets, QR code-enabled payments, with providers like PayPal, Google Pay, Square, Venmo, Samsung Pay, Apple Pay, and Zelle leading the way in North America. This rapid evolution of finance is mirrored globally, with each region adopting different cashless payment services. Paytm, PhonePe, Amazon Pay, and BHIM are prevalent in India, while the UK relies on CHAPS and BACS. Japan sees widespread use of PayPay, Line Pay, and Rakuten Pay, illustrating the diverse landscape of cashless transactions worldwide.

Source: Synthesized from World Payments Reports, Capgemini

The graph above highlights findings from the World Payments Report 2023, illustrating global trends in cashless transactions. It projects that non-cash digital payments will reach USD 2,297 billion. Enforcing the lawful use of financial transactions has become paramount with the increasing complexity and globalization of digital payments and the proliferation of providers tracking money flows. Adherence to standards is now a crucial factor in the banking, investment, and insurance sectors.

Introduction to ISO 20022 Standard

One pivotal standard for the financial payments industry is ISO 20022. It provides a common framework for electronic data interchange (EDI) used by financial institutions in the banking, investment, and insurance sectors. It enables seamless communication, reduces operational risks, and facilitates cross-border financial transactions by offering a standardized format and structure for financial messages, as well as enhanced efficiency, accuracy, and interoperability. The adoption of ISO 20022 is set to revolutionize the FinTech industry by streamlining processes, minimizing errors, and improving overall communication.

Many of FinTech's sophisticated features have become so normalized in our personal and business transactions that we may not fully understand the need for standardization in these financial message transactions. So, let us consider a few simple yet powerful scenarios.

Scenarios

Consider a scenario where a bank in the United States wants to send a payment to a bank in Europe. When the two banks use different message formats, processing the payment efficiently and accurately becomes challenging. However, if the banks use a standardized format, processing risks are minimized, and compliance is improved.

In an investment scenario, a mutual fund manager wants to trade stocks with a brokerage firm in the APAC region. Time is critical in market transactions, and any delay due to inconsistent message translation can lead to currency and investment risks. Using a standardized format expedites execution, eliminating risks of misinterpretation and ensuring customer satisfaction.

Multinational corporations (MNCs) manage cash flows across multiple banks in various geographies and regions. When consolidating financial statements like the balance sheet, income statement, and cash flow statement, having a standardized view of cash positions is essential for financial accuracy. This standardization is mandated by generally accepted accounting principles and regulated by regional regulations, such as the Sarbanes-Oxley Act (SOX) in the United States.

These scenarios highlight the essential need to establish credibility in financial transactions and trust in financial institutions. "Communication is not about what you said but what the other person understood," emphasizes Dr. Sriram Rajagopalan (2020), Global Head of Agile Strategy, Transformation, and Training services at Inflectra, drawing on his extensive experience in both technical and project management domains.

The concept of a standardized message format is not new. In the technology space, the necessity for objects to exchange data through interface definition languages (IDL), remote procedure calls (RPC), common object request broker architecture (CORBA), simple object access protocol (SOAP), and representational state transfer (REST) has been established for a long time.

The ISO 20022 standard brings these concepts to the financial sector, providing a standardized format that allows financial institutions to communicate effectively using a common language. This standard actively reduces the risks of misinterpretation, errors, and delays. It also automates processes, boosting efficiency and cutting costs. Additionally, ISO 20022 enhances the interoperability of financial systems, enabling institutions to connect and exchange information seamlessly.

Benefits of ISO 20022 Standard

As the financial landscape evolves, ISO 20022 is set to drive innovation and ensure the long-term stability and resilience of the financial system. The Society for Worldwide Interbank Financial Telecommunication (SWIFT), used by many countries for foreign payments, has announced its adoption of ISO 20022 (Baker, 2024). Similarly, the American Banking Association (ABA), which uses the FedWire system for Routing & Transit (R&T) numbers, will adopt ISO 20022 starting in March 2025 (Federal Reserve System, 2022).

Without such a standard, achieving sophisticated globalization with proper governance of electronic financial data would be impossible. The adoption of ISO 20022 is expected to create a more efficient, accurate, and interconnected financial ecosystem, benefiting payments, trade, and foreign transactions for all stakeholders, including financial institutions, corporations, and consumers. Summarized below are the essential benefits of the ISO 20022 standard:

  • Increased Efficiency: Standardized messages eliminate the need for manual intervention and enable straight-through processing (STP), boosting efficiency and reducing processing costs.
  • Improved Accuracy: Standardized messages minimize errors and misinterpretation, ensuring precise and reliable communication between financial institutions.
  • Enhanced Interoperability: Standardized messages enable seamless integration between different financial systems and applications, facilitating cross-border payments and reporting, often referred to as CBPR+, and reducing the need for multiple message formats.
  • Regulatory Compliance: ISO 20022 is increasingly becoming a regulatory requirement in many countries. Its adoption helps financial institutions meet regulatory obligations.
  • Global Connectivity: ISO 20022 is a global standard allowing financial institutions to communicate effectively with their counterparts worldwide.
  • Enhanced Security: ISO 20022 messages are encrypted, protecting them from unauthorized access and improving security while reducing the risk of fraud.
  • Reduced Risk: ISO 20022 helps reduce the risk of fraud and other financial crimes.
  • Increased Transparency: ISO 20022 enhances transparency in the financial industry, benefiting consumers and investors.

Elements of the ISO 20022 Standard

Many financial institutions have already implemented the ISO 20022 standard. J.P. Morgan Chase (n.d.) adopted this standard in early 2023, claiming it set the stage for automating frictionless payments. The Bank of England (2024) implemented it in their Clearing House Automated Payment Systems (CHAPS) and Real-time Gross Settlement Systems (RTGS) in mid-2023 and published their roadmap to embrace this standard further. Other banks, such as Citibank (n.d.), are working feverishly towards adopting it.

The ISO 20022 standard uses an extensible markup language (XML) based structure to tag transactions into the extensible business reporting language (XBRL) structure. This approach employs message exchange (MX) and differs from the earlier fixed-length message type (MT) based on ISO 15022. The MX format includes four identifiers: message type, message number, message variant, and version number. This enhances message clarity with better data for multilingual support, a clearer structure for regulatory compliance, and greater robustness for improved reconciliation.

Below is a synthesis of the support for numerous message structures under payments, securities, trade, and foreign exchange, says Dr. Sriram Rajagopalan, based on his research on ISO 20022 business areas (n.d). Organizations adopting or implementing the ISO 20022 standard in their software, whether for existing applications or new innovative products, must consider translating fixed message types (MT) to the new XML-based message exchange (MX) format. This summary provides a high-level overview but falls short of listing every potential message or business area.

Table 1: ISO 20022 Business Area and Message Exchanges

Business Area

Message Exchange Description

Payments

Domestic Payments to send/receive money within the same country

Cross-border Payments to send and receive money from different countries

High-value Payments requiring an exchange of large sums of money exceeding USD 1 million

Retail Payments requiring an exchange of small sums of money under USD 1,000

Securities

Issuance of stocks, bonds, and mutual funds

Trading of stocks, bonds, and mutual funds

Settlement of stocks, bonds, and mutual funds

Foreign Exchange

Spot transactions involving buying and selling of currency instruments on the spot market

Forward transactions involving buying and selling of currency instruments for future date

Swap transactions involving the exchange of one currency for another currency for a future date

Trade Finance

Messages to provide letters of credit to buyers of goods and services

Messages to collect payment from consumers for goods and services

Messages for giving payment guarantees for goods and services

Cash Management

Messages to provide account holders with information on their accounts

Messages used to deposit checks into accounts and retrieve updates

Messages used to transfer money from one account to another

Implementing ISO 20022 in Spira

Whether developing a new software product that supports ISO 20022 standards or modifying existing software to comply with this new standard, both product and process changes must be factored in. Although this implementation involves consulting various stakeholders to solicit the needs and agree on scope, developing the solution with the minimum viable product within the context of the organizational constraints, and monitoring the change to the value due to emerging risks or identified issues, some common concepts are important.

Get the Right Requirements

Any software development process must address both functional requirements for feature development and non-functional requirements to ensure standards adherence in areas such as security and reporting. For ISO 20022 compliance, it's essential to identify and implement both requirements.

Functional requirements for ISO 20022 compliance may include:

  • Capturing the ISO 20022 Message Catalog: Store the message catalog in the project repository.
  • Constructing the Business Application Header (BAH): Evaluate and build the BAH for every message type.
  • Schema Conformance: Ensure that all sent and received messages adhere to the schema mandated by the standard.
  • Audit Trail Tracking: Track the audit trail of each message.
  • Message Code Value Registration: Register the use of message code values for various use cases.

Spira from Inflectra supports ISO 20022 compliance in multiple ways, as demonstrated below.

  • It allows the product development team to seamlessly build the "business rules canvas" in a hierarchical fashion, allowing plan-driven or predictive project delivery teams to build this progressive set of functional requirements.

Depending on the Spira edition used, Spira provides five views (tree, list, board, document, and mind map) to facilitate requirements solicitation, analysis, and prioritization.

  • It provides "components" as a standard field for business rules, allowing the business lens to incorporate the non-functional features associated with each business rule.

  • It provides "requirement types" to facilitate a more controlled review and evaluation of the business rules, depending on their nature. Each requirement type can also have its independent workflow to provide robust control over the functional and non-functional business rules and provide scenarios to promote flexible requirements analysis.
  • It provides a document repository that allows users to upload pre-existing documents and create different types of documents natively within the instance, allowing these documents to be associated with various artifacts.

Build the Right Solutions

"Designing a solution is much more than what meets the eye" is a common agreement among the engineers who architect the solution. Architecture is not just programming the user interface but designing scenarios such as the basic flow, alternative flow, and exception flows, understanding the preconditions and postconditions. As part of solution development, designing the solution from the end-in-mind is one of the good practices.

Such good practices lead to risk-driven development (RDD) (Rajagopalan, 2021; Rajagopalan, 2024). Spira supports risk-driven development by identifying risks as a separate artifact subject to the risk management life cycle that can be associated with requirements and tasks to promote both risk-driven prioritization and risk-driven testing.

For instance, this RDD approach can unfold into the following approaches the product development team can build.

Compliance-Driven Development (CDD)

CDD is an approach that focuses on developing systems that comply with specific standards, regulations, or requirements. In the context of ISO 20022, CDD would involve ensuring that the software system is designed, developed, and tested to meet the requirements of the ISO 20022 standard. By bringing compliance-specific requirements to the forefront while drafting the requirements (use cases, epics, features, or user stories, depending upon the project delivery framework chosen), the organization can ensure compliance by design.

Such principles are seen in privacy by design, security by design, and quality by design frameworks. Critical to these considerations is to develop scenarios for specific requirement types. Spira provides this support to progressively elaborate on such requirements.

In implementing ISO 20022 standards, the organization should develop such use cases depending on the specific business needs. Below are a few examples in simplified use-case format.

Use Case 1: Sending a compliant ISO 20022 message

  • Actors:
  • Sender (e.g., a bank)
  • Receiver (e.g., another bank)
  • Goal:
  • To ensure that an XML-based MX message sent from the sender to the receiver complies with the ISO 20022 standard.
  • Preconditions:
  • The sender and receiver have agreed to use the ISO 20022 standard for message exchange.
  • The sender has a message that needs to be sent to the receiver.
  • Multiple internal stakeholders, such as the InfoSecurity team and Steering Committee, approve the XML data scheme before it is adopted by product development.
  • Postconditions:
  • The message is sent from the sender to the receiver in a format that is compliant with the ISO 20022 standard.
  • The receiver can process the message successfully.
  • The details of the actions taken on the transaction are logged with appropriate timestamps and success/failure codes as applicable.

Use Case 2: Receiving and validating a compliant ISO 20022 message

  • Actors:
  • Receiver (e.g., a bank)
  • Sender (e.g., another bank)
  • Goal:
  • To ensure that a message received by the receiver from the sender is compliant with the ISO 20022 standard.
  • Preconditions:
  • Multiple internal stakeholders, such as the InfoSecurity team and Steering Committee, approve the XML data scheme before it is adopted by product development.
  • The receiving message is validated against the InfoSecurity rules for phishing and spoofing (among many others) before being passed to the application layer to avoid compromising data and business operations.
  • The sender and receiver have agreed to use the ISO 20022 standard for message exchange.
  • The receiver has received a message from the sender.
  • Postconditions:
  • The receiver validates the message to ensure compliance with the ISO 20022 standard.
  • If the message is compliant, the receiver processes the message.
  • If the message is not compliant, the receiver rejects the message and sends a notification to the sender.
  • The details of the actions taken on the transaction are logged with appropriate timestamps and success/failure codes as applicable.

Use Case 3: Maintaining compliance with the ISO 20022 standard

  • Actors:
  • IT department
  • Business users
  • Goal:
  • Ensure the organization sustains the benefits of ISO 20022 standard compliance in ongoing operations by creating comprehensive system and user documentation for multiple internal and external users and continuously assessing and enhancing internal users' knowledge through ongoing training.
  • Preconditions:
  • The organization has decided to adopt the ISO 20022 standard.
  • The organization has identified the software systems and processes that need to be compliant with the ISO 20022 standard.
  • The organization has confirmed the repository through which ongoing feedback is collected for internal and external users for documentation and training needs.
  • The organization has established a process for external members to review documentation, ensuring its meaningful use and relevance.
  • The organization has a process for training users and assessing them after testing to reinforce the concepts and update the training materials, including documentation.
  • Postconditions:
  • The organization's software systems and processes comply with the ISO 20022 standard.
  • The organization can demonstrate compliance with the ISO 20022 standard to auditors.
  • The organization can assert that its training, documentation, and processes comply with the ISO 20022 standard.

Model-Driven Development (MDD)

MDD is an approach that uses models to represent the system being developed. These concepts leverage the optimal balance of the engineering principles for designing the system architecture and the value engineering principles for behavioral and operational considerations. The true benefit of the MDD is that the systems are designed and developed with the strategic initiatives of the performing organization, benefit sustenance imperatives of program management, and operational considerations of the portfolio and operations management, continuously focusing on total quality management. This notion is integral to quality initiatives like the Six Sigma, Capability Maturing Model (CMM) and the ISO 9001 standard on quality.

For instance, the system engineering principles can evaluate the software development design patterns (like factory method, singleton method, chain of responsibility, and interpreter), database design patterns (like atomicity, consistency, isolation, and durability), and network design patterns (like confidentiality, integrity, availability, resiliency, scalability, security, simplicity, and supportability). Similarly, the value engineering principles can incorporate both the product and process changes, adapting the lean, agile, and project management principles of streamlining flow (Kanban, Kaizen), reducing queues (work in progress limits, central point of failure), avoiding waste (Management Debt, Technical Debt), optimizing processes (refactoring, supply chain inefficiencies), and leveling resources (critical chain, rotating resources).

In the context of ISO 20022, Model-Driven Development (MDD) can be utilized to create models of ISO 20022 message formats and protocols. These models ensure that the proper process environment exists to produce benefits that are compliant with ISO 20022. Below are examples of how MDD can be achieved by applying a combination of principles

Use Case 1: Eliminating Waste

  • Actors:
  • Software Developers
  • Quality Assurance Engineers
  • Goal:
  • To reduce the amount of waste in the software development process.
  • Preconditions:
  • The software development team is aware of the ISO 20022 standard and its requirements.
  • The definition of ‘Ready’ for initiating a requirement within an iteration or phase is agreed upon.
  • The definition of ‘Done’ including both work completion (tasks) and acceptance criteria (test cases) are agreed upon.
  • Appropriate WIP limits are set in the proper stages to avoid queuing work that can’t be completed.
  • The development team incorporates test-driven development (TDD) principles and related paradigms to avoid rework or scrap work.
  • The management team (outside of the product development team) is engaged in exploratory testing or behavior-driven development (BDD) to ensure that validation is done outside of verification to eliminate escaped defects as part of the cost of quality considerations.
  • Postconditions:
  • The software development team has reduced the amount of waste in the software development process.
  • The management team is aware of the product features they must test and bring the right level of support to address the team's impediments.
  • The software is compliant with the ISO 20022 standard.

Use Case 2: Streamlining Flow

  • Actors:
  • Software Developers
  • Product Owners
  • Goal:
  • To streamline the flow of work through the software development process.
  • Preconditions:
  • The development team is aware of the ISO 20022 standard and its requirements.
  • The development team uses a flow improvement methodology, such as Kanban or Scrum.
  • An independent steering committee reviews the product backlog to align the product strategy to the organizational strategy supporting the product development team.
  • The development team integrates the use of naming standards, peer review, continuous code check-in, CICD pipelines, automation, and code coverage tools to streamline the build process and promote quality.
  • Postconditions:
  • The product development team is aware of the priority schemes.
  • The development team has committed to a balance of must-do stories and should-do stories, giving them time to support other team members and improve documentation.
  • The development team has streamlined the flow of work through the software development process and measures progress using cycle time and lead time.
  • The development team monitors interim health checks like the earned value indicators, velocity, and burn rate as agreed upon to monitor continuous improvement opportunities.
  • The software is compliant with the ISO 20022 standard.

Use Case 3: Improving Resiliency

  • Actors:
  • Software Developers
  • System Administrators
  • Network Administrators
  • InfoSecurity Team
  • Goal:
  • To improve the resiliency of the software to failures and disruptions.
  • Preconditions:
  • The development team has an integrated view of the ISO 20022 standard and its requirements, as well as the InfoSecurity standards (ISO 27001) and related mandates (GDPR, SOX, etc.).
  • The development team is using a resiliency improvement methodology, such as Fault Tolerance or Disaster Recovery.
  • The development team incorporates the automatic and graceful shutdown principles in the event of an exception to protect the integrity of infrastructure and resources while allowing recovery.
  • Postconditions:
  • The development team has improved the resiliency of the software against failures and disruptions.
  • The development team incorporates refactoring more frequently during development as well as continually engages in technical debt reduction.
  • The software is compliant with the ISO 20022 standard.

Right Transition to Operations

Transitioning benefits from development to operations is critical in upholding ISO 20022 standards. This transition ensures that the software developed meets the requirements of the standard and continues to do so throughout its operational life. Several factors need to be considered to ensure successful benefit transition to operations.

  • Understanding the ISO 20022 standard and its requirements clearly is essential. All stakeholders involved in the transition process, including developers, operations personnel, and management, should share this understanding.
  • A well-defined process for transitioning benefits from development to operations is necessary. This process should include steps such as testing, documentation, and training to ensure the software meets the standard's requirements.
  • Having the right tools and resources in place is crucial to support the transition process. These tools and resources can include automated testing tools, documentation generators, and training materials.
  • It is essential to have a robust governance structure in place to oversee the transition process. This governance structure should ensure that it adheres to the ISO 20022 standard and that it is continuously improved.

Consequently, in addition to the technical nature of deploying ISO 20022 software to the production environment, organizations also need to consider the following:

  • Documentation: The software application needs to be documented to explain how it supports ISO 20022 compliance.
  • Business process changes: The adoption of ISO 20022 may require changes to business processes. For example, organizations may need to update their systems to generate and process financial transactions.
  • Training: Employees who use the software application need to be trained on the ISO 20022 standard and how it impacts their work.
  • Communication: Organizations need to communicate the changes to their customers and partners.

From a constant measurement of value realized, organizations can use the key performance indicators below in operational maintenance.

  • Number of ISO 20022 messages processed successfully
  • Percentage of ISO 20022 messages processed with errors
  • Average time to process an ISO 20022 message
  • Number of security incidents related to ISO 20022 compliance
  • Level of customer satisfaction with ISO 20022 compliance

By following these considerations, organizations can ensure that their software applications comply with ISO 20022 and are prepared to adopt the new standard.

Summary

ISO 20022 compliance encompasses not only technical aspects but also organizational considerations. To achieve compliance successfully, organizations must ensure that all stakeholders thoroughly understand the standard and its requirements. Furthermore, establishing a clearly defined transition process from development to operations is crucial, including testing, documentation, and training. Having the appropriate tools and resources, such as automated testing tools and documentation generators, is essential. A strong governance structure should oversee the transition process, ensuring adherence to the standard and continuous improvement. Additionally, organizations need to document the software application to explain how it supports ISO 20022 compliance. By addressing these considerations, organizations can effectively implement ISO 20022-compliant software and reap the benefits of improved efficiency, reduced risk, and enhanced interoperability.

References

Baker, J. (2024). Swift and ISO 20022: The impact on payments explained. FX Intelligence. Retrieved June 1, 2024, from https://www.fxcintel.com/research/reports/swift-iso-20022-impact-payments-explained

Bank of England (2024). ISO 20022: Implementing the global payments messaging standard in CHAPS and RTGS. Retrieved June 4, 2024, from https://www.bankofengland.co.uk/payment-and-settlement/rtgs-renewal-programme/iso-20022

Citibank (n.d.). ISO 20022 Migration and Adoption. Retrieved June 4, 2024, from https://www.citibank.com/tts/sa/iso-20022-migration/index.html

Federal Reserve System (2022). New Message Format for the Fedwire® Funds Service. Retrieved June 1, 2024, from https://www.federalregister.gov/documents/2022/10/24/2022-23002/new-message-format-for-the-fedwire-funds-service

ISO 20022 Business Areas (n.d.). Retrieved June 2, 2024, from https://www.iso20022.org/sites/default/files/documents/D7/ISO20022_BusinessAreas.pdf

J.P. Morgan Chase (n.d.). ISO 20022 Migration: The journey to faster payments automation. Retrieved June 4, 2024, from https://www.jpmorgan.com/insights/treasury/treasury-management/what-is-iso-20022

Rajagopalan, S. (2020). Organized Common Sense: Why do Project Management Skills Apply to Everyone. Denver, CO: Outskirts Press. https://outskirtspress.com/sriramrajagopalan

Rajagopalan, S. (2021). INVEST: Deeper look into Iteration Planning. Retrieved May 28, 2024, from https://agilesriram.blogspot.com/2021/02/invest-deeper-look-into-iteration.html

Rajagopalan, S. (2024). Using Risk Driven Development in Software Delivery. Retrieved May 28, 2024, from https://www.inflectra.com/Ideas/Whitepaper/Using-Risk-Driven-Development-in-Software-Delivery.aspx

World Payments Report 2023 (n.d.). Capgemini. Retrieved May 29, 2024 from https://www.capgemini.com/gb-en/insights/research-library/world-payments-report/

Disclaimer

The information provided on this website is to be used for informational purposes only. The information should not be relied upon or construed as legal or compliance advice or opinions. The information is not comprehensive and will not guarantee compliance with any regulation or industry standard. You must not rely on the information found on this website as an alternative to seeking professional advice from your attorney and/or compliance professional.

Spira Helps You Deliver Quality Software, Faster and with Lower Risk.

Get Started with Spira for Free

And if you have any questions, please email or call us at +1 (202) 558-6885

Free Trial