SWIFT Messages

SWIFT Messages Introduction and ISO20022

What is SWIFT?

SWIFT (Society for Worldwide Interbank Financial Telecommunication) is a global financial messaging network that enables banks and financial institutions to exchange secure, standardized financial messages.

🔹 SWIFT does not move money
🔹 It transmits payment instructions and related information

Today, over 11,000 financial institutions in more than 200 countries use SWIFT.

What Does SWIFT Do?

SWIFT provides:

• A secure messaging network

• Standard message formats

• Rules and governance for financial messaging

• End-to-end tracking and reporting (e.g., SWIFT gpi)

SWIFT messages instruct banks how to move money, but the actual fund movement happens via correspondent banking and settlement systems.

Traditional SWIFT Messaging (MT)

Historically, SWIFT used MT (Message Type) formats.

Examples:

• MT103 – Customer credit transfer

• MT202 – Bank-to-bank transfer

• MT199 – Free-format message

Limitations of MT Messages

• Unstructured text

• Limited field length

• High manual intervention

• Poor compliance screening

What is ISO20022

ISO 20022 is a global financial messaging standard used to exchange rich, structured, and standardized data between financial institutions across payment, clearing, settlement, trade, and securities processes.

How SWIFT Uses ISO 20022

SWIFT is migrating its cross-border payments and reporting to ISO 20022 under the CBPR+ (Cross-Border Payments and Reporting Plus) program.

Benefits of ISO 20022

1. Rich & Structured Data

ISO 20022 uses structured XML formats, allowing more detailed and clearly defined payment information compared to legacy formats.

Benefit:
✔ Fewer ambiguities
✔ Reduced manual intervention
✔ Better data quality

2. Improved Compliance & Regulatory Reporting

Structured data enables more accurate AML, sanctions screening, and regulatory reporting.

Benefit:
✔ Better risk detection
✔ Reduced false positives
✔ Easier regulatory compliance

3. Higher Straight-Through Processing (STP)

Clear data elements reduce the need for payment repairs and manual handling.

Benefit:
✔ Faster processing
✔ Lower operational cost
✔ Higher automation

4. End-to-End Transparency

ISO 20022 supports detailed remittance information and tracking identifiers.

Benefit:
✔ Better payment traceability
✔ Faster issue resolution
✔ Improved customer experience

5. Global Interoperability

ISO 20022 is a globally accepted standard across multiple payment systems and regions.

Benefit:
✔ Seamless cross-border payments
✔ Reduced format conversions
✔ Future-proof integration

6. Better Customer Experience

Richer data enables clearer payment references, status updates, and confirmations.

Benefit:
✔ Fewer payment queries
✔ Improved trust and satisfaction

7. Reduced Payment Errors

Structured fields minimize free-text errors common in legacy message formats.

Benefit:
✔ Fewer rejects and returns
✔ Lower investigation volumes

8. Supports Real-Time & Instant Payments

ISO 20022 is designed to support instant and real-time payment schemes.

Benefit:
✔ Enables 24x7 processing
✔ Supports faster settlement models

9. Scalability & Future Readiness

The standard supports new use cases without redesigning message structures.

Benefit:
✔ Easy adaptation to future regulations
✔ Long-term sustainability

10. Better Analytics & Insights

Standardized data enables advanced analytics and reporting.

Benefit:
✔ Improved liquidity management
✔ Better business insights
✔ Smarter decision-making

ISO 20022 XML message identifier

s

ISO Message Structure

Payment Initiation messages - pain.001 and pain.002

Overview

In the ISO 20022 ecosystem, pain.001 and pain.002 play a critical role in customer-initiated payments and their status reporting. These messages are primarily used in the Customer-to-Bank (C2B) space but also influence downstream bank-to-bank payment processing under CBPR+.

This section explains:

• What pain.001 and pain.002 are

• Where they fit in the CBPR+ payment lifecycle

• End-to-end payment flows

• Common usage scenarios

• Key differences and terminologies

What is pain.001? (Customer Credit Transfer Initiation)

pain.001 is an ISO 20022 message used by a customer to initiate a payment request to their bank.

pain.001 message structure

Key Characteristics

• Initiates a customer credit transfer

• Does not move funds

• Acts as an instruction, not a settlement message

• Used by corporates, institutions, or individuals

📌 Important:
Funds movement always happens later via pacs messages (e.g., pacs.008).

Who is the “Customer” in pain.001?

In ISO 20022 terminology, a customer can be:

• A large corporate

• A small business

• A financial institution acting as a customer

• An individual (retail customer)

This makes pain.001 highly flexible and widely used across banking models.

pain.001 in the ISO 20022 Landscape

The pain.001 message triggers the payment chain, but the actual settlement happens through interbank messages.

Customer-to-Bank (C2B) Flow Using pain.001

1. Customer prepares payment file

2. pain.001 sent to Debtor Bank

3. Bank validates & enriches data

4. Payment converted to pacs.008

5. Funds move via correspondent banking

Validation Checks Performed by the Bank

• Schema & format validation

• Sanctions screening

• Balance & limit checks

• Duplicate detection

What is pain.002? (Payment Status Report)

pain.002 is a status feedback message sent by the bank in response to pain.001.

Pain.002 Message structure

Purpose of pain.002

• Confirms whether payment was:

  • Accepted

  • Partially accepted

  • Rejected

• Provides detailed rejection reasons

• Enables straight-through processing (STP)

pain.002 Status Flow

The customer uses pain.002 to:

• Reconcile payments

• Fix errors

• Track processing outcomes

Common pain.002 Status Codes

ACTC:Accepted – technical validation passed

ACSP:Accepted – settlement in progress

RJCT:Rejected

PDNG:Pending

Status feedback travels back using:

• pain.002 (Customer side)

• pacs.002 (Interbank side)

Why pain.001 & pain.002 Matter

• Enable automation & STP

• Reduce payment failures

• Improve transparency

• Support regulatory compliance

• Enable structured data exchange

Payment, Clearing and Settlement (pacs) messages - pacs.008

pacs.008 Message Structure

The pacs.008 has two core sets of nested element: Group Header which contain a set of characteristics that relate to all individual transactions Credit Transfer Transaction Information which contains elements providing information specific to the individual credit transfer transaction.

A typical payment message in a many-to-many payment would be considered as a single transaction. The Industry CBPR+ committeee has decided that the pacs.008 will carry a single transaction as a best practice. It is however possible, where bilateral agreed, to include re-occurring Credit Transfer Transaction Information i.e. multiple payments, perhaps more associated with an early leg in the payment lifecycle, where upon these multiple transaction would typically be split into individual payment transactions.

pacs.008 Fi to FI Customer credit transfer

Payment, Clearing and Settlement (pacs) messages - pacs.009 and pacs.009 cover

The pacs.009 has two main use cases: • as a core Financial Institution to Financial Institution Credit Transfer message, and • As a cov where it is used as cover of (to settle) a pacs.008. The pacs.009 therefore contain information of the underlying Customer Credit Transfer (pacs.008) for use in the cover scenario, which is the key attribute to differentiate between these two use cases.

pacs.009 message structure

pacs.009 FI to FI Credit Transfer

The Financial Institution Credit Transfer message is sent by a Debtor Financial Institution to a Creditor Financial Institution, directly or through other agents and/or a payment clearing and settlement system. It is used to move funds from a debtor account to a creditor, where both Debtor and Creditor are Financial Institutions.

pacs.009 cov

Payment, Clearing and Settlement (pacs) messages - pacs.002

The Financial Institution To Financial Institution Payment Status Report message is sent by an instructed agent to the previous party in the payment chain. It is used to inform this party about the positive or negative status of an instruction (either single or file). It is also used to report on a pending instruction

Payment, Clearing and Settlement (pacs) messages - pacs.004

In a similar structure to the pacs.009 (cov) underlying Customer Credit Transfer, the pacs.004 Return Payment message has amongst other elements Original Group Information which captures original information such as the Original UETR and Original Interbank Settlement Amount etc. and an Original Transaction Reference which contain the key elements of the original payment e.g. Debtor, Creditor etc

pacs.004 message structure

Within the pacs.004 Return Payment

• the Original Group Information element is used to refers to original message for which the return relates to. e.g. based upon the above example pacs.008 as the original message would be included in the pacs.004

• the Transaction Information > Original UETR element would include UETR of the message received. i.e. the same UETR is used on the Return Payment. • the Original Transaction Reference element includes detail from the original message. e.g. the Debtor of the original pacs.008.

• the Return Chain element includes the parties in return payment chain, noting the parties reverse (i.e. change role) from the original payment whereby the Debtor of the original payment becomes the Creditor in the Return Chain.

• A reason code is added to the Return message to inform the agent of the reason for the return (e.g. AC04 Account closed)

References:

SWIFT MyStandards: https://www2.swift.com/mystandards/#/c/cbpr/landing

ISO20022 Catalogue: https://www2.swift.com/mystandards/#/ISO20022

CBPR+ Sample messages: https://www2.swift.com/mystandards/#/c/cbpr/samples