Misc

Understanding RTGS: Message Standards and Protocols

Created   Updated
RTGS Financial Infrastructure
  1. 1 Evolution of Payment Message Standards
  2. 2 ISO 20022 Fundamentals
  3. 3 Key ISO 20022 Messages for RTGS
  4. 4 SWIFT MT to ISO 20022 Migration
  5. 5 Further Reading
  6. 6 Summary

Message standards are the language of RTGS systems. This article explores the message formats, protocols, and standards that enable interoperability between financial institutions in real-time gross settlement networks.

1 Evolution of Payment Message Standards

1.1 Historical Context

timeline title Payment Message Standards Evolution 1973 : SWIFT Founded : First standards developed 1977 : SWIFT MT Messages : Category 1 (Customer Transfers) 2004 : ISO 20022 Published : XML-based standard 2018 : RTGS Migration Begins : TARGET2, Fedwire adopt ISO 20022 2023 : SWIFT MT Migration : Coexistence period begins 2025 : ISO 20022 Dominance : Most major systems migrated

1.2 Standards Comparison

Standard Format Era Status
SWIFT MT Fixed-length text 1977-2025 Legacy (phasing out)
ISO 20022 XML/JSON 2004-present Current standard
Fedwire Proprietary 1918-present US-specific
CHIPS Proprietary 1971-present US clearing only

2 ISO 20022 Fundamentals

2.1 What is ISO 20022?

📋 ISO 20022 Overview

ISO 20022 is an international standard for financial services messaging that provides:

✅ Common Platform

  • Unified methodology for message development
  • Standardized data dictionary
  • Consistent modeling approach (UML)

✅ Rich Data Structure

  • XML-based format (primary)
  • JSON support (emerging)
  • Extensible data model

✅ Global Adoption

  • Used by 70+ countries
  • Major RTGS systems migrated
  • SWIFT migration underway

2.2 Why ISO 20022?

The development of ISO 20022 was driven by fundamental limitations in legacy messaging standards that had served the financial industry for decades but could no longer meet modern requirements.

The Problem with Legacy Standards:

When SWIFT MT standards were created in the 1970s, system storage and bandwidth were expensive commodities. Message designs prioritized minimalism—every character counted. This resulted in fixed-length text formats with severe constraints:

Limitation Impact
Field size constraints Names truncated to 35 characters, addresses to 4 lines
Unstructured formats Free-text fields led to inconsistent interpretation
Ambiguity “CA” could mean Canada or California; “NYC” vs “NEW YORK”
Limited data capacity Only essential transaction data could be transmitted
Manual intervention Insufficient structure hampered automation

The Business Case for Change:

By the early 2000s, these limitations created critical problems:

  1. Regulatory Pressure: Post-9/11 AML/KYC regulations demanded greater transparency about payment participants and purposes. Legacy messages couldn’t provide sufficient detail for compliance screening.

  2. Automation Barriers: Unstructured data required manual review and intervention, increasing operational costs and error rates. Straight-through processing (STP) was impossible without standardized, machine-readable fields.

  3. Global Fragmentation: Different regions and systems used incompatible formats, creating friction in cross-border payments. The G20 identified this as a barrier to efficient international trade.

  4. Innovation Constraints: New financial products and services couldn’t be supported by rigid legacy formats. The industry needed an extensible standard that could evolve.

The ISO 20022 Solution:

ISO 20022 addresses these challenges through:

  • Rich, structured data – XML format supports comprehensive information exchange with unlimited field lengths and hierarchical organization
  • Rules-based methodology – Standardized data dictionary eliminates ambiguity (e.g., separate fields for country codes vs. state codes)
  • Extensibility – New message types and data elements can be added without breaking existing implementations
  • Global harmonization – Single standard replaces fragmented regional formats, enabling seamless cross-border payments

The result is a standard that supports straight-through processing rates exceeding 95%, compared to 60-70% under legacy MT formats, while simultaneously meeting regulatory transparency requirements and enabling innovation in financial services.

2.3 ISO 20022 Message Structure

graph TB A["ISO 20022 Message"] A --> B["Message Header"] A --> C["Message Body (Payload)"] A --> D["Message Trailer"] B --> B1["Message Definition Identifier"] B --> B2["Business Application Header"] B --> B3["Security Elements"] C --> C1["Transaction Information"] C --> C2["Party Information"] C --> C3["Amount & Currency"] C --> C4["Dates & Times"] C --> C5["Remittance Information"] D --> D1["Security Trailer"] D --> D2["Validation Data"] style A fill:#1976d2,stroke:#0d47a1,color:#fff style B fill:#e3f2fd,stroke:#1976d2 style C fill:#fff3e0,stroke:#f57c00

2.4 Message Naming Convention

ISO 20022 uses a standardized naming pattern:

👥 For Implementers

Want to know what ISO 20022 knowledge your team actually needs? See ISO 20022 Skills Guide for RTGS Developers for role-based guidance on practical competencies vs. theoretical knowledge.

<BusinessArea><Function><SubFunction><Variant>

Example: pacs.008.001.08
├── pacs  = Payments Clearing and Settlement
├── 008   = Customer Credit Transfer
├── 001   = Message variant
└── 08    = Version number

Common RTGS Message Types:

Message Type Code Usage
Customer Credit Transfer pacs.008 High-value customer payments
Financial Institution Transfer pacs.009 Bank-to-bank transfers
Payment Status Report pacs.002 Payment status notification
Cancel Request pacs.004 Payment cancellation
Return pacs.004 Payment return

2.5 Consistent Modeling Approach (UML)

ISO 20022’s foundation lies in its rigorous, model-driven methodology. Unlike legacy standards that defined message formats directly, ISO 20022 starts with abstract business models that are then transformed into concrete message schemas.

What “Consistent Modeling Approach” Means

The consistent modeling approach ensures that all business concepts across financial services are represented uniformly, regardless of the specific message type or use case. This consistency delivers three critical benefits:

Principle Description Benefit
Uniform Business Concepts All business entities (parties, transactions, accounts) are modeled using the same definitions Eliminates ambiguity; “Debtor” means the same thing in every message
Unambiguous Models Each model element has a precise, documented semantic meaning No interpretation required; reduces implementation errors
Reliable Message Generation Messages can be automatically generated in multiple syntaxes from the same model Single source of truth; XML, JSON, ASN.1 stay synchronized
graph TB A["Business Requirement"] --> B["UML Model"] B --> C["Message Definition"] C --> D["XML Schema (XSD)"] C --> E["JSON Schema"] C --> F["ASN.1 Schema"] B --> G["Business Data Dictionary"] G --> B style A fill:#e3f2fd,stroke:#1976d2 style B fill:#1976d2,stroke:#0d47a1,color:#fff style C fill:#fff3e0,stroke:#f57c00 style D fill:#f5f5f5,stroke:#616161 style E fill:#f5f5f5,stroke:#616161 style F fill:#f5f5f5,stroke:#616161 style G fill:#e8f5e9,stroke:#2e7d32

The ISO 20022 UML Profile

While ISO 20022 uses UML (Unified Modeling Language) as its modeling foundation, it applies a constrained UML profile specifically designed for financial messaging. This constraint ensures consistency and tool compatibility.

Constrained Elements:

UML Element ISO 20022 Usage Semantic Meaning
Class Business concept or message Represents a business entity (e.g., Payment, Party)
Attribute Data field Single piece of information with defined type
Association Relationship Reference from one class to another
DataType Reusable structure Common patterns (e.g., Address, Amount)
Enumeration Code list Fixed set of allowed values
Inheritance Specialization Extended message types inherit base structure

Not Allowed (or Restricted):

  • Multiplicity markers beyond 0…1, 1, 0…, and 1…
  • Complex UML behaviors or state machines
  • Free-form notes without semantic definition
  • Custom stereotypes outside the ISO 20022 profile

Key Elements of the ISO 20022 UML Approach

1. Business Concept Layer — Defines what the message represents:

classDiagram class PaymentInstruction { +PaymentIdentification +PaymentTypeInformation +Amount +Date } class PartyIdentification { +Name +Address +BIC +LEI } class FinancialInstitution { +BIC +Name +Branch } PaymentInstruction --> PartyIdentification : references PaymentInstruction --> FinancialInstitution : references

2. Data Type Layer — Reusable building blocks:

Data Type Purpose Example
Max35Text Short text field Transaction ID
ActiveCurrencyAndAmount Currency + amount USD 1,000,000.00
ISODate Date format 2025-12-10
CountryCode Country identifier US, GB
BICFIIdentifier Bank identifier BANKUS33XXX

3. Message Structure Layer — How elements combine:

classDiagram class FIToFICustomerCreditTransfer { +GroupHeader +CreditTransferTransactionInformation[] } class GroupHeader { +MessageIdentification +CreationDateTime +NumberOfTransactions +SettlementInformation } class CreditTransferTransactionInformation { +PaymentIdentification +Amount +DebtorAgent +CreditorAgent +UltimateDebtor +UltimateCreditor } FIToFICustomerCreditTransfer "1" *-- "1" GroupHeader FIToFICustomerCreditTransfer "1" *-- "1..*" CreditTransferTransactionInformation

Simple UML Diagram Example

Here’s a simplified UML class diagram showing the core structure of a payment message:

classDiagram class Document { +FIToFICstmrCdtTrf } class FIToFICstmrCdtTrf { +GrpHdr : GroupHeader +CdtTrfTxInf : CreditTransferTransactionInformation[] } class GroupHeader { +MsgId : Max35Text +CreDtTm : ISODateTime +NbOfTxs : Max15NumericText +SttlmInf : SettlementInformation } class CreditTransferTransactionInformation { +PmtId : PaymentIdentification +IntrBkSttlmAmt : ActiveCurrencyAndAmount +DbtrAgt : BranchAndFinancialInstitutionIdentification +CdtrAgt : BranchAndFinancialInstitutionIdentification +UltmtDbtr : PartyIdentification +UltmtCdtr : PartyIdentification } Document --> FIToFICstmrCdtTrf FIToFICstmrCdtTrf --> GroupHeader FIToFICstmrCdtTrf --> CreditTransferTransactionInformation note for Document "Root element" note for CreditTransferTransactionInformation "Repeating transaction block"

How UML Maps to XML (MX Messages)

The transformation from UML model to XML schema follows deterministic rules:

UML Element XML Representation Example
Class XML Element <CdtTrfTxInf>
Attribute Child Element or Attribute <MsgId>MSG-123</MsgId>
DataType Element with type definition <IntrBkSttlmAmt Ccy="USD">
Association Nested Element <DbtrAgt><FinInstnId>...</FinInstnId></DbtrAgt>
Enumeration xsd:restriction <Cd>URGP</Cd> (from fixed list)
Multiplicity 0…1 minOccurs="0" Optional element
Multiplicity 1…* minOccurs="1" maxOccurs="unbounded" Required repeating

For detailed coverage of cardinality rules and multiplicity, see ISO 20022 Cardinality Rules Deep Dive.

UML to XML Transformation Example:

  • Note: The ASCII art diagram below provides a proposed example illustrating how a UML class definition can be transformed into its corresponding XML output. This is a simplified representation of the auto-generation process.
┌─────────────────────────────────────────────────────────────┐
│ UML Class                    │ XML Output                   │
├─────────────────────────────────────────────────────────────┤
│ class PaymentIdentification  │ <PmtId>                      │
│   +TxId : Max35Text          │   <TxId>TRANSACTION-001</TxId│
│   +InstrId : Max35Text       │   <InstrId>INSTR-001</InstrId│
│                              │ </PmtId>                     │
└─────────────────────────────────────────────────────────────┘

The XML schema (XSD) is auto-generated from the UML model, ensuring:

  • Schema always matches the business model
  • Changes to business rules propagate automatically
  • No manual schema editing errors

ISO 20022 UML vs. Traditional SWIFT MT Modeling

The difference between ISO 20022’s model-driven approach and SWIFT MT’s format-driven approach is fundamental:

Aspect SWIFT MT ISO 20022 UML
Starting Point Message format specification Business domain model
Structure Fixed-length text fields Hierarchical XML elements
Data Dictionary Implicit in field definitions Explicit, reusable entities
Extensibility Limited (new MT types needed) High (add elements without breaking)
Ambiguity High (free-text fields common) Low (structured, typed fields)
Validation Position-based parsing Schema-based validation
Tool Support Manual interpretation Automated model-to-code generation

SWIFT MT Approach (Format-Driven):

:20:TRANSACTION-001          ← Field tag + free text
:32A:251210USD1000000,00     ← Packed format (date+currency+amount)
:50:ABC CORPORATION          ← Unstructured name
     WALL STREET 100         ← Free-text address
     NEW YORK, NY            ← Interpretation required
:59:XYZ LIMITED              ← Beneficiary
:70:INVOICE PAYMENT          ← Unstructured remittance

ISO 20022 Approach (Model-Driven):

  • Note: The XML snippet below is a proposed example illustrating the model-driven approach of ISO 20022. This is a simplified and partial representation of a pacs.008 message, serving as an illustration.
<TxId>TRANSACTION-001</TxId>                    ← Typed element
<IntrBkSttlmAmt Ccy="USD">1000000.00</IntrBkSttlmAmt>  ← Structured amount
<IntrBkSttlmDt>2025-12-10</IntrBkSttlmDt>      ← ISO date
<UltmtDbtr>
  <Nm>ABC Corporation</Nm>                      ← Explicit name field
  <PstlAdr>
    <StrtNm>Wall Street</StrtNm>                ← Structured address
    <BldgNb>100</BldgNb>
    <TwnNm>New York</TwnNm>
    <Ctry>US</Ctry>
  </PstlAdr>
</UltmtDbtr>
<RmtInf>
  <Ustrd>Invoice Payment</Ustrd>                ← Explicit remittance
</RmtInf>

Key Advantages of the UML Approach:

  1. Semantic Clarity — Every element has a defined meaning; no interpretation needed
  2. Validation — XML Schema validates structure automatically
  3. Extensibility — New fields can be added without breaking existing implementations
  4. Automation — Code generators can produce classes, schemas, and documentation from models
  5. Consistency — Same business concept (e.g., “Party”) appears identically across all messages

This model-driven methodology is why ISO 20022 achieves straight-through processing rates exceeding 95% compared to 60-70% under MT formats—the structured, unambiguous data enables full automation without manual intervention.

3 Key ISO 20022 Messages for RTGS

3.1 pacs.008 - Customer Credit Transfer

The primary message for customer payments:

  • Note: The XML snippet below is a proposed example of a pacs.008 message. While pacs.008 is a standardized message type, the specific values and some elements presented here are illustrative and may vary in actual implementations.
<?xml version="1.0" encoding="UTF-8"?>
<Document xmlns="urn:iso:std:iso:20022:tech:xsd:pacs.008.001.08">
  <FIToFICstmrCdtTrf>
    
    <GrpHdr>
      <MsgId>MSG-12345-2025</MsgId>
      <CreDtTm>2025-12-10T10:30:00Z</CreDtTm>
      <NbOfTxs>1</NbOfTxs>
      <SttlmInf>
        <SttlmMtd>INDA</SttlmMtd>
      </SttlmInf>
    </GrpHdr>
    
    
    <CdtTrfTxInf>
      <PmtId>
        <InstrId>INSTRUCTION-001</InstrId>
        <TxId>TRANSACTION-001</TxId>
      </PmtId>
      
      
      <PmtTpInf>
        <InstrPrty>URGT</InstrPrty>
        <SvcLvl>
          <Cd>URGP</Cd>
        </SvcLvl>
      </PmtTpInf>
      
      
      <IntrBkSttlmAmt Ccy="USD">1000000.00</IntrBkSttlmAmt>
      
      
      <IntrBkSttlmDt>2025-12-10</IntrBkSttlmDt>
      
      
      <DbtrAgt>
        <FinInstnId>
          <BICFI>BANKUS33XXX</BICFI>
        </FinInstnId>
      </DbtrAgt>
      
      
      <CdtrAgt>
        <FinInstnId>
          <BICFI>BANKGB2LXXX</BICFI>
        </FinInstnId>
      </CdtrAgt>
      
      
      <UltmtDbtr>
        <Nm>ABC Corporation</Nm>
        <PstlAdr>
          <StrtNm>Wall Street</StrtNm>
          <BldgNb>100</BldgNb>
          <PstCd>10005</PstCd>
          <TwnNm>New York</TwnNm>
          <Ctry>US</Ctry>
        </PstlAdr>
      </UltmtDbtr>
      
      
      <UltmtCdtr>
        <Nm>XYZ Limited</Nm>
        <PstlAdr>
          <StrtNm>City Road</StrtNm>
          <BldgNb>50</BldgNb>
          <PstCd>EC1V</PstCd>
          <TwnNm>London</TwnNm>
          <Ctry>GB</Ctry>
        </PstlAdr>
      </UltmtCdtr>
      
      
      <RmtInf>
        <Ustrd>Invoice INV-2025-001 Payment</Ustrd>
      </RmtInf>
    </CdtTrfTxInf>
  </FIToFICstmrCdtTrf>
</Document>

3.2 pacs.009 - Financial Institution Transfer

Used for interbank transfers (own account transfers):

graph LR subgraph "pacs.008 (Customer Payment)" A1[Customer A] --> A2[Bank A] A2 --> A3[RTGS System] A3 --> A4[Bank B] A4 --> A5[Customer B] end subgraph "pacs.009 (Bank Transfer)" B1[Bank A] --> B2[RTGS System] B2 --> B3[Bank B] B2 -.-> B4[Own Account] end style A3 fill:#1976d2,stroke:#0d47a1,color:#fff style B2 fill:#1976d2,stroke:#0d47a1,color:#fff

Key Differences:

Aspect pacs.008 pacs.009
Purpose Customer payments Interbank transfers
Ultimate Parties Customer to Customer Bank to Bank
Remittance Info Required Optional
Use Case Commercial payments Liquidity transfers

3.3 pacs.002 - Payment Status Report

Provides status updates on payments:

  • Note: The XML snippet below is a proposed example of a pacs.002 message. While pacs.002 is a standardized message type, the specific values and some elements presented here are illustrative and may vary in actual implementations.
<Document xmlns="urn:iso:std:iso:20022:tech:xsd:pacs.002.001.10">
  <FIToFIPmtStsRpt>
    <GrpHdr>
      <MsgId>STATUS-12345</MsgId>
      <CreDtTm>2025-12-10T10:31:00Z</CreDtTm>
    </GrpHdr>
    
    <OrgnlGrpInf>
      <OrgnlMsgId>MSG-12345-2025</OrgnlMsgId>
      <OrgnlMsgNmId>pacs.008.001.08</OrgnlMsgNmId>
    </OrgnlGrpInf>
    
    <TxInfAndSts>
      <OrgnlTxId>TRANSACTION-001</OrgnlTxId>
      
      
      <TxSts>ACSC</TxSts>
      
      
      <StsRsnInf>
        <Rsn>
          <Cd>SETC</Cd>
          
        </Rsn>
      </StsRsnInf>
      
      <SttlmInf>
        <SttlmSts>STLD</SttlmSts>
        
      </SttlmInf>
    </TxInfAndSts>
  </FIToFIPmtStsRpt>
</Document>

Status Codes:

Code Meaning Description
ACSC Accepted Settlement Completed Successfully settled
ACCP Accepted Customer Profile Customer validated
ACSP Accepted Settlement in Process Being processed
RJCT Rejected Payment rejected
PDNG Pending Awaiting processing
ACTC Accepted Technical Validation Technically valid

4 SWIFT MT to ISO 20022 Migration

4.1 MT Message Categories

graph LR A["SWIFT MT Messages"] A --> B["Category 1: Customer"] A --> C["Category 2: Financial"] A --> D["Category 9: Confirmations"] B --> B1[MT103: Customer Transfer] B --> B2[MT103+: Enhanced] C --> C1[MT202: Bank Transfer] C --> C2[MT202COV: Cover Payment] D --> D1[MT910: Credit Confirm] D --> D2[MT900: Debit Confirm] style A fill:#1976d2,stroke:#0d47a1,color:#fff style B1 fill:#ffebee,stroke:#c62828 style C1 fill:#ffebee,stroke:#c62828

4.2 MT to ISO 20022 Mapping

MT103 to pacs.008:

MT103 Field ISO 20022 Element Notes
:20 (TRN) PmtId.TxId Transaction ID
:32A (Value Date/Currency/Amount) IntrBkSttlmAmt + IntrBkSttlmDt Amount and date
:50 (Ordering Customer) UltmtDbtr Ultimate debtor
:52 (Ordering Institution) DbtrAgt Debtor agent
:59 (Beneficiary Customer) UltmtCdtr Ultimate creditor
:57 (Account With Institution) CdtrAgt Creditor agent
:70 (Remittance Info) RmtInf.Ustrd Remittance details

MT202 to pacs.009:

MT202 Field ISO 20022 Element Notes
:20 (TRN) PmtId.TxId Transaction ID
:32A (Value Date/Currency/Amount) IntrBkSttlmAmt Settlement amount
:52 (Ordering Institution) DbtrAgt Debtor agent
:57 (Account With Institution) CdtrAgt Creditor agent

4.3 Migration Timeline

gantt title SWIFT MT to ISO 20022 Migration dateFormat YYYY-MM axisFormat %Y-%m section Coexistence MT & ISO Parallel :active, coex, 2022-11, 2025-11 section Migration Phase 1 Readiness :done, phase1, 2022-11, 2023-06 Phase 2 Testing :done, phase2, 2023-06, 2024-06 Phase 3 Migration :active, phase3, 2024-06, 2025-06 Phase 4 Completion :phase4, 2025-06, 2025-11 section End of MT MT Shutdown :crit, shutdown, 2025-11, 1m

5 Further Reading

For technical implementation details including XML validation technologies, communication protocols, and testing, see the companion article:

→ Understanding RTGS: Message Implementation and Validation

This companion article covers:

  • XML validation stack (XSD, Schematron, XMLDSig)
  • Communication protocols (TLS, REST APIs, Message Queues)
  • Testing and certification requirements

6 Summary

📋 Key Takeaways

Essential message standards knowledge:

✅ ISO 20022 Dominance

  • Global standard for RTGS messaging
  • XML-based with rich data structure
  • Replacing legacy SWIFT MT formats

✅ Why ISO 20022?

  • Legacy MT standards had severe data limitations
  • Regulatory pressure demanded greater transparency
  • Enables straight-through processing rates exceeding 95%

✅ Key Message Types

  • pacs.008: Customer credit transfers
  • pacs.009: Financial institution transfers
  • pacs.002: Payment status reports

✅ Migration from MT

  • SWIFT MT sunset November 2025
  • Mapping between MT and ISO 20022
  • Coexistence period ending

Footnotes for this article:

Share