Understanding the Building Blocks of ISO 20022

Introduction:

ISO 20022 has rapidly become the global language of financial messaging, reshaping how banks, payment systems, and financial institutions share information. But before diving into message structures and complex flows, it’s essential to understand the foundation—the core concepts that make ISO 20022 powerful, flexible, and globally consistent.

These concepts form the backbone of every ISO 20022 message—whether used in cross-border payments (CBPR+), domestic schemes, securities, or cash management.

By understanding these building blocks, you’ll be better equipped to interpret messages, analyze flows, troubleshoot implementations, and navigate the transition from MT to MX. Think of this as the “grammar” you must learn before speaking the ISO 20022 language fluently.

Let’s begin by breaking down the core elements that define ISO 20022 at its most fundamental level.

ISO 20022 Business Domains

ISO 20022 groups all financial messaging content into Business Domains.
A Business Domain is simply a high-level area of financial activity, such as Payments, Securities, or Trade.

Each domain contains:

• specific business processes (e.g., credit transfer, direct debit),
• message sets (e.g., pacs, camt, pain),
• and the business components/data elements used in those processes.

Think of Business Domains as “faculties” in the ISO 20022 University.

Why Business Domains Exist

They help the industry:

• organise ISO 20022 content logically
• avoid duplication of definitions
• standardise processes across markets
• allow different market groups (SEGs) to govern each domain
• reuse common components consistently

For example:
A “Party” in Payments is the same “Party” in Securities — thanks to business domain consistency.

ISO defines 5 primary business domains:

Payments

This is the biggest and most widely adopted domain.
It covers how money moves between:

• customers,
• banks,
• payment systems,
• clearing houses,
• and cross-border corridors.

Covered processes like:

• Credit transfers
• Direct debits
• Mandates
• Standing orders
• Cash management
• Payment status reporting
• Claims/investigations
• Request-to-Pay

This is the domain used for CBPR+ (Cross-Border Payments & Reporting).

Securities

This domain covers all lifecycle activities of securities such as:

• equities,
• bonds,
• ETFs,
• mutual funds.

Process areas include:

• Trading
• Clearing
• Settlement
• Corporate actions
• Collateral management
• Reconciliation
• Reporting

This domain is massive because securities markets depend on clinical precision.

Trade Services (Trade Finance)

Covers the messaging used for international trade instruments such as:

• Letters of Credit (LCs)
• Guarantees
• Bills of Lading
• Documentary collections
• Open account trade

Used heavily by banks supporting corporate trade flows.

FX (Foreign Exchange)

This domain covers processes involving buying, selling, hedging, or exchanging currencies.

Includes:

• FX spot
• FX forwards
• FX swaps
• FX options
• Confirmation and settlement

This area ensures consistent global FX trade communication.

Cards & Related Retail Payments

Covers retail payment instruments like:

• debit cards,
• credit cards,
• mobile wallets,
• POS transactions.

Note:
Card payments traditionally use ISO 8583, but ISO 20022 defines richer, more structured alternatives than classic card messages.

Key Principles Across All Domains

1.Reuse of common components

Regardless of domain:

• A “Party” is a Party
• An “Agent” is a Financial Institution
• An “Account” is an Account
• A “Postal Address” follows the same structure

This is the heart of ISO 20022 consistency.

2. Each domain has a dedicated SEG (Standards Evaluation Group)

They review and approve messages belonging to that domain.

3. Messages are always built from the ISO Data Dictionary

Domains don’t reinvent definitions; they compose from shared building blocks.

4. Domains are designed to interoperate

Example: A corporate treasury instruction may trigger a payment → which results in a securities settlement → which updates cash positions.

ISO ensures all these interactions use compatible data.

Message Sets in ISO 20022

A Message Set in ISO 20022 is a logical grouping of related messages that together support a specific business process within a particular Business Domain.

Think of Message Sets as “Departments” under Business Domains faculties in the ISO 20022 University.

A Message Set includes:

• All related Message Definitions
• Their supporting components
• Documentation linking them
• The business process context in which they operate

Example:
The Payments Clearing and Settlement (pacs) area contains a Message Set that includes all the pacs messages:

• pacs.002 (Status)
• pacs.004 (Return)
• pacs.007 (Cancellation)
• pacs.008 (Customer Credit Transfer)
• pacs.009 (Financial Institution Transfer)
• pacs.010, pacs.028, etc.

This entire collection is a Message Set.

Key point: A Message Set = a group of related Message Definitions.

Message Definitions in ISO 20022

In ISO 20022, a Message Definition is the official, fully-specified blueprint of a financial message.
It describes exactly what information a message must contain, how it is structured, and how it should be interpreted.

It is the authoritative specification from which the actual XML or JSON message schemas are generated.

In simple terms: A Message Definition is the detailed recipe for a specific ISO 20022 message or called “blueprint” of one ISO message.

Think of Message Definitions as “Courses” in Message Sets Departments under Business Domains faculties in the ISO 20022 University.

What a Message Definition Contains

Each Message Definition includes:

1️.Message name & identifier

Example:

• Name: FIToFICstmrCdtTrf
• Identifier: pacs.008.001.08

2️.Purpose of the message

What business process it supports (e.g., Customer Credit Transfer).

3️.Business context

Which Business Area / Domain it belongs to (e.g., Payments — pacs).

4️.Message structure

A hierarchical breakdown of all components:

• Group Header
• Transaction Information
• Party structures
• Amount blocks
• Remittance blocks
• Agents, accounts, dates, IDs

5️.List of all elements & their definitions

For each field:

• Name
• Definition
• Data type
• Cardinality (mandatory/optional, single/repeating)
• Constraints/rules
• References to Data Dictionary components

6️.Message components

These are reusable building blocks in ISO.
A Message Definition picks components from the Data Dictionary.

7️.XSD/JSON schema (syntax binding)

ISO publishes schemas derived from the Message Definition so systems can validate messages.

Where Message Definitions Live

Every Message Definition is stored in the ISO 20022 Repository, which provides:

• Message Definition Reports (MDRs)
• XML schemas
• Documentation
• Dictionaries
• Model diagrams

The Repository is the authoritative source for all ISO message content.

Example: Message Definition for pacs.008

The Message Definition for pacs.008.001.08 will specify:

• The message supports FI-to-FI customer credit transfer
• It contains a GrpHdr element
• It contains one or more CdtTrfTxInf blocks
• Each block requires:
  • Payment ID
  • Settlement amount
  • Debtor, creditor, accounts, agents
  • Purpose, remittance info
• Optional/mandatory rules for each element
• Data types & constraints
• XML layout

This ensures all banks worldwide implement pacs.008 exactly the same way.

Why Message Definitions Are Important

Global consistency: Everyone uses the same structure → no ambiguity.

Interoperability: Systems worldwide can exchange messages reliably.

Machine-readability: Schemas allow automatic validation and STP (straight-through processing).

Mapping from MT becomes clear: MT fields map to specific elements in the Message Definition.

Basis for usage guidelines; Communities (like CBPR+, SEPA) create rules around the core definitions.

Where Message Definitions Fit in the ISO 20022 Model

ISO 20022 has three conceptual layers:

1. Business Model

Defines the process and actors.

2. Message Definition (you are here)

Defines the structured message to support the process.

3. Syntax (XML/JSON)

The physical message derived from the definition.

Message Definitions sit in the middle — turning business needs into formal technical specifications.

In One Sentence

Message Definitions in ISO 20022 are the official, fully-specified templates that describe every allowed element, structure, and rule of a financial message, ensuring global consistency and machine-interpretable communication.

ISO 20022 Message Identifier

Every ISO 20022 message has a standardized, structured name called the Message Identifier.
It looks like this: pacs.008.001.08

This identifier tells you:

1. Which business area the message belongs to
2. What the specific function of the message is
3. Its version, release, and revision

The name is not random — it follows a strict 4-part structure.

The 4-Part Message Identifier Structure [ 4!a . 3!c . 3!n . 2!n ]

1️.Business Area (4!a = 4 letters)

Example: pacs

This identifies what domain the message belongs to.

Common business areas:

• pacs – Payments Clearing & Settlement
• pain – Payments Initiation
• camt – Cash Management
• acmt – Account Management
• semt – Securities Settlement
• fxtr – Foreign Exchange Trade
• tsmt – Trade Services

Each business area groups messages serving similar purposes.

2️.Message Number (3!c = 3 digits)

Example: 008

This identifies the specific message function within that business area.

Examples:

• pacs.008 → FI-to-FI Customer Credit Transfer
• pain.008 → Customer Direct Debit Initiation
• pacs.009 → Financial Institution Transfer
• pain.001 → Customer Credit Transfer Initiation
• camt.053 → Bank Statement

The message number is unique inside its business area.

3️.Variant (3!n = 3 digits)

Example: 001

This identifies the variant of the message. A variant is a more restricted or “slimmed down” version of a global ISO 20022 message definition.

Why variants exist:

• Some markets require a customized version for their specific use case
• Different payment schemes may use different flavors of the same general message

Variant 001 usually means “the primary or original version”, but more variants may be added as needed.

A notable example of “002” variant is in the securities domain, where the DTCC uses a “002” variant for some corporate actions messages (e.g., seev.001.002.xx or similar) to ensure compatibility with legacy systems like ISO 15022. This is a specific implementation by a market infrastructure. 

Currently, in payments domain, we do not have any “002” variants created. It may be because:

1. The global definitions for CBPR+ are already widely adopted, and there hasn’t been a strong business case yet to restrict them into a simpler “002” version.
2. CBPR+ implementers may prefer to use Usage Guidelines (Implementation Guides) instead of creating a variant — because usage rules (what fields must / must not be used) can often solve the same problem without making a new variant.
3. Variant creation is a formal process: someone needs to file a Business Justification with the RA, and then develop and maintain the variant definition.

4️.Version (2!n = 2 digits)

Example: 08

This tells you which version of the message you’re working with.

ISO releases new versions to:

• Add new fields
• Deprecate outdated elements
• Reflect regulatory changes
• Add richer structure or correct specifications

Versions increment over time if there are changes during annual message releases.
Example:

• pacs.008.001.08 (older)
• pacs.008.001.13 (current 2025 Message Release)

So pacs.008.001.08 means:

“The version 8 definition of the primary variant of the FI-to-FI Customer Credit Transfer message in the Payments Clearing & Settlement domain.”

Why the Identifier Is So Important

Because it guarantees precision.

It tells implementers:

• exactly what fields,
• exactly what rules,
• exactly what XML schema,
• exactly what business function

they should implement.

Two systems anywhere in the world can exchange messages confidently because the identifier uniquely locks both parties to the same definition.

How the Identifier Helps in Real Projects

• Tells middleware which schema to use
• Ensures CBPR+ institutions use the same version
• Controls compatibility between banks and schemes
• Ensures regulatory consistency
• Helps map MT ↔ ISO during coexistence
• Supports version-by-version migration planning

Example:
A bank receiving pacs.008.001.08 must validate the XML against exactly that schema.
No guessing. No local interpretations. 

This identifier is one of the most important fundamentals of the entire ISO 20022 framework.

Party Identifiers in ISO 20022

Party Identifiers are standardized pieces of data used to uniquely identify a party involved in a payment.
A “party” can be:

• a person,
• a company,
• a bank,
• a financial institution,
• a legal entity,
• a government body,
• or even a branch of an organization.

ISO 20022 defines structured components to hold those identifiers so machines can read, validate, and interpret party information consistently.

Why Do Party Identifiers Exist?

They were introduced because older MT messages used unstructured free text to identify parties (e.g., fields 50K, 59F and Field 58 with options A, B, C and D).

Example MT103 free text:

:59:/BE62510007547061

JOHANN WILLEMS

RUE JOSEPH II, 19

1040 BRUSSELS

ISO 20022 improves this by providing:

• Structured identification
• Multiple options for identifying a party
• Clear, machine-readable hierarchy
• Better AML / KYC screening
• International interoperability

This is essential for:

• CBPR+
• Sanctions Screening
• Correspondent Banking
• Automated routing
• Payment repair reduction

Where Party Identifiers Are Used in ISO 20022?

In payment messages (like pacs.008, pacs.009, pain.001), identifiers appear in components such as:

• InstgAgt (Instructing Agent – Sender)
• InstdAgt (Instructed Agent – Receiver)
• Dbtr (Debtor)
• DbtrAgt (Debtor Agent / Debtor’s Bank)
• Cdtr (Creditor)
• CdtrAgt (Creditor Agent / Beneficiary Bank)
• UltmtDbtr (Ultimate Debtor)
• UltmtCdtr (Ultimate Creditor)
• InitgPty (Initiating Party)
• FwdgAgt (Forwarding Agent)
• IntrmyAgt1/2/3 (Intermediary Agents)
• PrvsInstgAgt1/2/3 ( Previous Instructing Agents)
• RmbrsmntAgt (All three Reimbursement Agents)

Each of these has identification components that hold party identifiers.

Each of these has “Acct” Account section separately except Ultimate parties, Initiating Party and Forwarding Agent as these are not financially linked to the Payment Instruction.

How ISO 20022 Structures Party Identifiers

ISO 20022 uses two main components to identify parties:

1️. Party Identification

Used for persons and organizations (non-financial institutions).

It may contain:

• Name
• Postal address (fully structured)
• Country
• Tax Identification Number (TIN)
• Date and place of birth (for individuals)
• Organization ID (business registration numbers, national IDs)
• LEI (Legal Entity Identifier)
• Proprietary identification schemes

Example:

<Dbtr>

   <Nm>John Doe</Nm>

   <PstlAdr>

       <StrtNm>High Street</StrtNm>

       <BldgNb>15</BldgNb>

       <TwnNm>London</TwnNm>

       <Ctry>GB</Ctry>

   </PstlAdr>

   <Id>

      <OrgId>

         <AnyBIC>HDFCINBB</AnyBIC>

      </OrgId>

   </Id>

</Dbtr>

2️. Financial Institution Identification

Used for banks and financial institutions.

It can include:

• BIC (ISO 9362)
• LEI
• Clearing System Member Identification
• Name & Address
• Other proprietary financial IDs

Example:

<DbtrAgt>

   <FinInstnId>

      <BICFI>DEUTDEFFXXX</BICFI>

   </FinInstnId>

</DbtrAgt>

Types of Party Identifiers in ISO 20022

ISO supports multiple identification types because not all jurisdictions use the same system.

1. BIC (Business Identifier Code)

• Standard way to identify a bank
• 8 or 11 characters
• Mandatory for many CBPR+ flows (though ISO allows alternatives)

2. LEI (Legal Entity Identifier)

• 20-character global legal entity identifier. GLEIF (Global LEI Foundation) manages the LEI ecosystem.
• They identify Companies, Banks, Corporations, etc. any party that is a legal person.
• They do not identify individuals (unless acting as sole traders in some jurisdictions)

3. National ID (Tax ID, Company Registration Number)

• ISO allows country-specific formats
• Structured with <Othr> + <SchmeNm> for custom schemes

4. Clearing System Member ID

Used when a bank is identified by its local clearing code:

• Sort Code (UK)
• IFSC (India)
• Fedwire ABA (US)
• CNAPS (China)
• SIC (Switzerland)

5. Account Identifiers (IBAN or BBAN)

These identify accounts, not parties—but are closely linked.

6. Person Identification

For individuals: passport number, national ID, customer ID, etc.

Why Party Identifiers Matter So Much in CBPR+

CBPR+ requires highly structured party data to meet:

• FATF requirements
• Sanctions screening
• AML rules
• Travel Rule
• Intermediary transparency

Legacy MT text blocks don’t differentiate between:

• name,
• address,
• country,
• unique identifier,
• type of entity.

ISO solves this by giving structured tags.

Sanctions engines, AML tools, and AI screeners rely heavily on structured identifiers to reduce false positives.

Summary — What Are Party Identifiers?

1. Structured data elements for identifying people, organizations, and banks.
2. Used in almost every ISO payment message.
3. Support multiple ID types (BIC, LEI, registration numbers, clearing codes, etc.).
4. Provide rich, machine-readable data for AML, compliance, and automation.
5. Critical foundation for CBPR+ and global payments modernization.

External Code Set Lists in ISO 20022

In ISO 20022, an External Code Set (often called an “External Code List”) is a list of allowed values that is not defined inside ISO 20022, but is created and maintained by another standards body or authority.

ISO 20022 references these lists but does not manage or control the contents.

Examples:

• ISO 4217 — Currency Codes (USD, EUR, INR)
• ISO 3166 — Country Codes (US, GB, AE)
• ISO 9362 — BIC Codes
• LEI ROC — Legal Entity Identifiers
• SWIFT — Purpose codes, Category Purpose codes
• International postal bodies — Address type codes

These are considered external because the code sets exist outside the ISO 20022 repository.

Why External Code Sets Exist (Why Not Define Everything Inside ISO 20022?)

ISO 20022 intentionally avoids re-defining information already standardized elsewhere because:

• Better global consistency: Banks worldwide already use ISO 4217 for currency and ISO 3166 for countries. Recreating them would cause duplication and confusion.
• Avoids conflicts between standards: If ISO 20022 created its own EUR / GBP list, who would maintain it? External owners keep their lists current.
• Allows updates without updating ISO 20022 messages: If a new currency is introduced (e.g., new African or Middle Eastern currencies), ISO 20022 does not need a message revision — it automatically supports it because the external standard updates.

• Keeps ISO 20022 flexible and future-proof: ISO 20022 doesn’t need to republish messages every time the world changes — instead, it references the official authority for each type of code.

How ISO 20022 References External Code Lists

ISO 20022 uses a naming convention:

• ExternalXxxxxCode
• ExternalXxxxxIdentification
• ExternalXxxxxTypeCode

Examples:

• ExternalOrganisationIdentificationCode
• ExternalPurposeCode
• ExternalCategoryPurposeCode
• ExternalClearingSystemIdentificationCode
• ExternalFinancialInstitutionIdentificationCode

In the message schema (XSD), these fields appear as:

<Cd>XXXX</Cd>

But the XSD does NOT list all valid values — instead it includes documentation stating:

“This element must use values from External Code List XXXX published on iso20022.org.”

So the validation of the actual value is done by:

• Market infrastructure (RTGS systems, CBPR+),
• SWIFT network validation rules,
• Banks’ internal systems – not by the XML schema itself.

Where External Code Lists Are Published

ISO 20022 hosts an official webpage called:

“External Code Sets” – Link : https://www.iso20022.org/catalogue-messages/additional-content-messages/external-code-sets
This contains:

• The name of the external code list
• Its definition
• Link to its authoritative source
• Update frequency

SWIFT also publishes curated lists as part of:

• CBPR+ Usage Guidelines
• Network Validation Rules
• Implementation Guides

Why External Code Lists Are Critical in ISO 20022 (especially CBPR+)

1. Interoperability across countries

Cross-border payments require common values across 200+ markets.

2. Regulatory compliance

Purpose codes, tax codes, and country identifiers often come from local regulators.

3. Machine readability and automation

Clear, structured codes reduce false positives in sanctions/AML.

4. Scalable and maintainable

External authorities update codes; ISO 20022 doesn’t need constant releases.

5. Zero duplication

Avoids ISO redefining things already standardized worldwide.

Summary — In Simple Words

ISO 20022 External Code Sets are:

• Lists of allowed values
• Maintained by external authorities (not ISO 20022)
• Referenced inside ISO 20022 fields
• Used for currencies, countries, BICs, LEIs, purposes, clearing systems, IDs, and more
• Critical for consistency and global interoperability

They keep ISO 20022:

• lightweight,
• globally aligned,
• up-to-date without constant schema changes.

Supplementary Data in ISO 20022

Supplementary Data is a special extension mechanism inside ISO 20022 messages that allows additional information to be included without modifying the core message definition.

Think of it as an “official extension slot” within ISO 20022 messages.

It appears in ISO messages as:

<SplmtryData>

    <PlcAndNm>…</PlcAndNm>

    <Envlp>…</Envlp>

</SplmtryData>

This structure is standardized and can appear in many ISO payment messages (pacs, camt, acmt, etc.).

---

Why Supplementary Data Exists

ISO 20022 messages are globally standardized. Any change to the official schema must go through:

• Business Justification
• Change Request (CR)
• ISO Registration Authority (RA)
• Global consultation
• Schema redesign
• Migration planning

This process can take years.
But businesses often need to exchange new information quickly, for example:

• A scheme needs new fields (e.g., consent ID, local clearing references).
• A country needs fields only relevant to its domestic regulations.
• A bank wants to transport extra metadata without breaking ISO rules.

Supplementary Data solves this by enabling:

• Rapid extension
• Local/regional customization
• Backward compatibility
• Strict isolation from standard core fields

Structure of Supplementary Data

Supplementary Data always follows the same 3-part structure:

1️. <SplmtryData>

The parent wrapper for the extension.

2️. <PlcAndNm>

A string where the creator identifies:

• where this data applies
• which party created it
• or a reference (e.g., scheme name)

Examples:

CBPR

UK.FPS

TARGET2

BANKXYZ

3️. <Envlp>

A generic container for custom XML that holds the extra fields.

Inside <Envlp>, you can put any structured XML you define, as long as it complies with:

• XML schema rules
• The message’s namespace rules
• Any scheme governance rules

Practical Uses of Supplementary Data

1. Local Market Add-ons

Domestic payment systems often require information not covered by global ISO fields.

Example:

• Australian NPP
• UK Faster Payments
• SEPA regulatory extensions
• Saudi domestic requirements (Sarie)

All can insert local fields without touching core ISO.

2. Regulatory Requirements

Supplementary Data allows fast compliance with new rules:

• FATF requirements
• Domestic AML/KYC data
• Transaction category codes
• Purpose of Payment extensions

Regulators can mandate new fields without needing ISO to redesign the pacs.008 schema.

3. Migration Support

Banks migrating from local proprietary formats can embed remaining fields temporarily in Supplementary Data until the ISO standard evolves.

 4. Bank-to-Bank Metadata

Banks sometimes need to exchange:

• Internal routing codes
• Processing timestamps
• Investigations metadata
• Internal references

Embedding them in <Envlp> allows transmission without violating ISO validation rules.

Benefits of Supplementary Data

• Ensures extensibility: You can evolve faster without changing ISO itself.
• Ensures stability: Core ISO fields remain untouched.
• Ensures global + local coexistence: Global message stays standard, local needs are met.
• Supports innovation: Banks can test new fields before submitting to ISO as a formal Change Request.

Limitations

• Tools may ignore Supplementary Data if not recognized
• CBPR+ will reject unapproved use
• No guaranteed interoperability
• Must be pre-agreed between participants