Financial Forensics in a fragmented ecosystem

· 1629 words · 4 minute read

Over the past decade, several cyber incidents have shed light on how SWIFT operates between institutions. In 2017, I covered the vulnerabilities with PASSFREELY and the JEEPLEA SIGINT operations revealed in TheShadowBrokers leaks. Additionally, the 2016 Bangladesh Central Bank Heist, orchestrated by North Korea, offered valuable insights into the workings of international inter-bank SWIFT messaging.

Since then, financial messaging standards have undergone significant changes. Legacy standards like ISO 15022 and ISO 8583 are being phased out in favor of ISO 20022. At the same time, new competing standards have emerged, particularly from Russia’s SPFS, India’s Unified Payments Interface, and China’s CIPS. Additionally, Central Bank Digital Currency (CBDC) initiatives have been launched, and smart contract-based centralized stablecoins like USDC, USDT, and BUSD now include features like the ability to freeze transactions.

China’s Cross-Border Interbank Payment System (CIPS) and India’s Unified Payments Interface (UPI) are key digital payment systems with distinct focuses. In 2023, CIPS processed RMB123.06 trillion ($17.09 trillion) through 6.6133 million transactions, connecting 150 Direct Participants and 1,401 Indirect Participants worldwide, with significant influence in Asia. Meanwhile, UPI, which handles primarily domestic transactions, reached ₹182 lakh crore ($2.2 trillion USD) in 2023, now accounting for nearly 80% of India’s digital payments. While CIPS facilitates cross-border transactions, UPI has become essential to everyday financial activity in India. Both systems play crucial roles alongside SWIFT, the global interbank messaging service that processes $150 trillion annually across 11,000 institutions.

In this blog post, I’ll examine the differences between traditional SWIFT MT messages, ISO 20022, BESP (БЭСП), and CIPS (人民币跨境支付系统) in anticipation of more technical details about BRICS Pay. BRICS Pay is poised to be a major development, with 159 countries expected to adopt it as a new payment system at the time of writing. This analysis will also serve as a useful reference for tracking current fintech developments and gaining insights into the future of financial forensics and AML.

BRICS Pay

Formats 🔗

ISO 15022 🔗

ISO 15022 is an standard for messaging in the financial industry, specifically for securities trading and settlement. It defines a format for electronic data interchange (EDI) messages, which are typically legacy plain text files.

A helpful illustration from Alessa shows what an MT202 COV containing an underlying MT103 looks like. The MT202 COV was introduced to address issues with intermediary banks processing payments for originating and/or beneficiary banks attempting to evade OFAC sanctions.

MT202 COV

The use of MT202 cover payments highlighted the AML challenges posed by the lack of metadata between institutions. This issue has led to increased inclusion of source, origin, and destination data in current formats.

ISO 20022 🔗

You have Business Application Header (BAH) defined as head.001.001, this is a mandatory message but which can be proved useful for AML purposes.

Workflow 🔗

Here is a diagram showing a payment workflow on ISO 20022 which includes pacs.008 messages.

ISO20022 pain.001 flow

UPI 🔗

UPI is essentially an XML document embedded within JSON data, which is sent to NPCI/IMPS RESTful APIs.

CIPS 🔗

Although CIPS currently uses its own message codes, it plans to adopt the ISO 20022 XML syntax for future messages. In contrast, India’s UPI has not announced any plans to make this change. CIPS’s approach will include incorporating the ISO 20022 Business Application Header, which other systems might omit.

CIPS seems to have the most mature standard and framework, I would not be surprised if they are leading the BRICS Pay efforts.

web3 🔗

This topic warrants a separate blog post, but Web3 applications (smart contracts), Layer-1 solutions (domain-specific VMs), and Layer-n innovations (ZK-rollups) offer significant advantages, whether in decentralized or traditional infrastructures. It’s no surprise that we are witnessing a rise in Central Bank Digital Currency (CBDC) projects. It wouldn’t be surprising to see the US Federal Reserve or BRICS announcing their own CBDCs to drive global adoption. Zimbabwe, for example, recently introduced a new gold-backed currency (ZiG) and has been exploring a gold-backed CBDC for some time.

Comparison 🔗

All standards are converging on ISO 20022 for international interbank transfers, but regional and national messaging formats may still vary, as noted earlier.

For a comprehensive overview of the upcoming Financial Market Infrastructure (FMI) migrations, refer to the ISO 20022 roadmap from Citi Treasury and Trade Solutions (Dec 2023).

ISO20022 Roadmap. Source: Citi Treasury and Trade Solutions

Banks and Non-Bank Financial Institutions connected to the Swift FINPlus platform must be capable of sending, receiving, and processing MX messages by November 2025.

Message Codes 🔗

MT / MX / CIPS 🔗

Here is a table that outlines the primary SWIFT message types, along with their MX (ISO 20022) and CIPS equivalents. It includes a brief description of each message type and highlights the differences between the standards. These message types are emphasized due to their relevance in Anti-Money Laundering (AML) and cyber incident scenarios.

SWIFT Message Type ISO 20022 Message Code CIPS Message Code CIPS Message Type Description
MT 101 pain.001 (CustomerCreditTransferInitiation) N/A N/A Request for Transfer.
MT 102 pacs.008 (FIToFICustomerCreditTransfer) cips.111 (Customer Credit Transfer) Financial Transfer Facilitates bulk customer credit transfers between financial institutions.
MT 103 pacs.008 (FIToFICustomerCreditTransfer) cips.111 (Customer Credit Transfer) Financial Transfer Used for individual customer credit transfers, typically in cross-border payments.
MT 202 pacs.009 (FinancialInstitutionCreditTransfer) cips.112 (Financial Institution Transfer) Financial Transfer Enables the transfer of funds between financial institutions, often for settlement purposes.
MT 203 pacs.009 (FinancialInstitutionCreditTransfer) cips.112 (Financial Institution Transfer) Financial Transfer Similar to MT 202, used for interbank transfers, particularly for lower-value transactions.
MT 900 camt.054 (BankToCustomerDebitCreditNotification) cips.305 (PaymentStatusQuery) Account Statement Notifies the customer of a debit transaction on their account.
MT 910 camt.054 (BankToCustomerDebitCreditNotification) cips.305 (PaymentStatusQuery) Account Statement Confirms the crediting of funds to a customer’s account.
MT 950 camt.053 (BankToCustomerStatement) cips.358 (AccountManagement) Statement Provides a comprehensive statement of account activity over a defined period.

ISO 20022 are composed of multiple Message Definition Reports (MDRs), but we will mainly focus on the following in the context of transfers. CIPS has different PaymentTypeCode but we are mostly interested in FTFX (Financial Institution Transfer), CTFX (Cross-border Capital Transfer)

  • Payment Initiation (pain)
  • Payments Clearing and Settlement (pacs)
  • Cash Management (camt) In addition to camt.052-054, the messages pacs.002 and pacs.004 (Payment Return Message) are also interesting to confirm the status of payment in a pacs message chain.

БЭСП-SWIFT 🔗

This table compares legacy БЭСП-SWIFT codes with their SWIFT MT equivalents and provides English translations for clarity.

БЭСП-SWIFT Code БЭСП-SWIFT Description SWIFT MT Equivalent Description
ED101 Платежное поручение (Payment order) MT103 Single Customer Credit Transfer
ED206 Платежное поручение (Confirmation of debit/credit) MT900 / MT910 Debit Advice / Credit Advice

This table only contains MT 103 and MT 900/910, as it seems there are no distinct codes for MT 102, MT 202/203 and MT 950 as they seem to be already covered by ED101 and ED206.

Conclusion 🔗

In future implementations, one crucial factor to consider is XML Serialization/Deserialization. Implementing those standards in .NET, Java, or NodeJS could result in significant performance costs. However, Rust appears to be an ideal candidate for [such tasks]((https://github.com/EmergentFinancial/iso-20022).

Another key consideration is the architecture of the messaging workflows. Will they be cloud provider-specific or fully on-premise? How much control do stakeholders want over this? The Central Bank of Bangladesh’s 2016 heist highlighted the severe infrastructure issues faced by some financial institutions, while the SWIFT Service Bureau demonstrated that managing one’s own infrastructure may not be feasible for everyone.

I came across an Architecture Diagram for ISO 20022 Messaging Workflows on AWS, which effectively showcases AWS core capabilities like API Gateway, SQS, and Lambda functions. While this may seem like a convenient solution, the performance cost may not be sufficient.

ISO20022 pain.001 flow

A third point to consider is the use of Large Language Models (LLMs) for Extract, Transform, and Load (ETL) processes across different formats and standards. This could help build a robust unit testing framework and manage documentation in multiple languages. However, LLMs are unlikely to be practical for real-time data transformation due to their slow processing speeds. Transactions per second (TPS) will become increasingly important, especially with the rise of Web3 Layer 1 and Layer 2 solutions.

There will be many exciting developments in the coming years, and there may also be opportunities for interoperable Anti-Money Laundering (AML) solutions. If you’re interested in discussing this further, feel free to reach out.

Technical Documentation 🔗