Making the most of ISO 20022

The worldwide payments industry is adopting ISO 20022 messaging standards. It enables more consistent, data-rich information to transact with greater speed, efficiency and accuracy.

SVB is migrating our payment solutions to ISO 20022. As part of our commitment to helping innovation economy businesses succeed, in addition to this guide, we are also providing personalized support for clients affected by changes.

The global evolution of ISO 20022

The International Organization of Standardization (ISO) is a non-government organization with experts from many countries who collaborate to define standards for multiple industries. 

ISO 20022 standards for payments were first introduced in 2004 and have evolved over time. Jurisdictions around the world have been working to adopt the standard for payment messages on their own schedules, all in support of increasing global adoption. SWIFT is part of this adoption, with some of the main transition completing by the end of 2025.

ISO 20022 standards use XML-based messaging formats, file types and data elements to provide a worldwide common language for payment messages.

SVB migration & client support for ISO 20022

Multi-year effort

Payment networks worldwide are migrating their payment message types to meet the ISO 20022 standard before the November 2025 deadline mandated by Swift. 
Since March 2023, SVB has supported both ISO 20022 MX (XML-based) and legacy message formats. We are implementing changes in compliance with industry migration deadlines.

Dedicated client support

For clients affected by the changes, SVB specialists will support you through the transition. You’ll receive timely communications to help you prepare for updates, and we’ll work closely with you to meet ISO 20022 standards and reap the potential benefits.

As ISO 20022 is adopted globally, companies will be able to realize valuable benefits.

Faster payments

• Enhance cashflow and vendor relationships with more efficient, straight-through processing.

• Increase visibility into liquidity for managing growth.

• Improve compliance by rapidly identifying sanctioned transactions.

Data-rich insights

• Automate compliance reporting using enhanced data and know-your-customer (KYC) protocols.

• Improve fraud detection with rich real-time data for verification and analysis.

• Make data-driven decisions for cash management, CRM, marketing and more.

Flexible and resilient

• Keep pace with change with standards that can adapt to economic changes and emerging technologies.

• Minimize the impact of outages in payment systems with efficient re-routing of messages.

Key benefits for teams in your organization

Finance

• Reduce costs with more efficient payment processes.

• Enhance cash management and forecasting with data-rich, real-time reporting.

• Streamline origination and reporting with standardized formats and data.

• Close monthly books faster with enhanced reporting.

Compliance

• Minimize risk by more easily detecting fraud and identifying potential financial crime.

• Simplify compliance with a standard used across multiple payment types.

SVB solutions enhanced for ISO 20022

You can continue to access the SVB payment channels you use today and may see changes as we migrate to ISO 20022 standards. Our payment channels are evolving to add new data fields and provide enhanced information reporting to help you get the most out of the new standards.

If you use any of the services below, we’ll notify you about updating to ISO 20022 with ample time to support you through changes and will help you get the most benefit.

SVB Go

SVB Go payments are being upgraded to ISO 20022 but you will not see changes in how you send and receive payments. You will also be able to access new features such as a simplified ISO-compliant tax payment experience and other benefits like end-to-end ID field to improve tracking. 

Swift for Corporates


SVB will be ready to support new MX message formats while continuing to support legacy MT formats. If you use Swift for Corporates and elect to update from MT formats to ISO 20022 standards, we will proactively notify you with technical specs and provide support for required changes.

Transact Gateway

Current clients using Transact Gateway (TAG) with embedded payment solutions have already migrated to ISO compliant formats. 



If you use non-embedded payment solutions, we will contact you to help you prepare, although required changes aren’t due until late 2026.

API Banking

SVB API Banking has wire APIs that are ISO 20022 compliant.

Fedwire® and domestic wires will enable richer reporting by adding new data fields, including: Purpose Code, Related Remittance, Ultimate Debtor (for OBO) and End-to-end ID.

Use cases that show ISO 20022 benefits

Improve cash management

A growing corporate in the life sciences sector wants to automate delivery of account balance and transaction data for greater visibility into their cash position and to help automate and streamline their payables/receivables processes. Because ISO 20022 is rapidly becoming the go-to universal standard, they can realize new efficiencies while increasing productivity and avoiding the pitfalls of truncated data associated with prior formats. These benefits can be realized using either SVB’s Transact Gateway (TAG) or Swift for Corporates.

Enhance fraud detection

A fintech firm that offers a payments platform needs more streamlined fraud detection to better serve its customers and to stay competitive. With ISO 20022 granular real-time data, they can avoid false positives that may inhibit straight-through processing that keeps payments flowing smoothly. They are also better equipped to stop fraud in its tracks, avoiding potentially costly resolution efforts, saving time and money.

To ensure a smooth transition to ISO 20022, we’re working closely with clients and will share details in advance of any changes. Milestones for industry and SVB-specific migration dates:

ISO 20022 MX file types and structured data enable more consistent, detailed messaging for payments compared to legacy formats.

Commonly used MX message types:

• Pain: Payment initiation message from a company (debtor or creditor) to a financial institution. For example, pain.001 initiates customer credit, pain.008 initiates customer debit.

• Pacs: Payment clearing and settlement messages between banks. For example, pacs.008 is a customer credit transfer instruction.

• Camt: Cash management message. For example, camt.053 is a statement from the creditor’s bank to their customer confirming a credit to their account.

Greater detail to simplify compliance and reconciliation

• Secure payment tracking: Tracking for all payments, from initiation and clearing, to information reporting, cannot be changed or removed by any party in the payment chain. 

• Dedicated purpose code: Specify the reason for the payment from a pre-defined list. 

• Dedicated tags for Ultimate Debtor: Increase transparency for payments made on-behalf-of others, e.g., factoring or money servicing businesses. 

• More data for payer and address information: Can be used throughout the message structure (street name, building number, post code, town name, country, LEI [Legal Entity Identifier]).

Easier to identify sanctioned payments

• Well-organized data: Structured format clearly displays payer data such as name, address, LEI and more to better meet evolving BSA and AML requirements.

• Refined screening: Richer, more consistent data can reduce false positives in sanctions checks.

• Improved compliance: More accurate, data-rich sanctions screening enable companies to comply with regulations more effectively.

Message types and parties in a payment message chain: Fedwire Transfer Process Example

In example below, Company B sends invoice to Company A, which initiates the payment process.

• Account owner: Person or entity that legally owns an account and is responsible for transactions in and out of that account.

• Creditor: Person or entity (e.g., vendor, property seller, contractor) that will receive payment for money owed, either via credit transfer initiated by a Debtor, or the Creditor initiates a direct debit payment from the Debtor’s account.

• Debtor: Person or entity that is responsible for making a payment (universal term to refer to payers, buyers, ordering parties, etc.). The Debtor may initiate payment, or the Creditor may initiate a direct debit from the Debtor’s account.

• Initiating party: Debtor or Creditor that initiates a payment, or a party that initiates payment on their behalf.

• Instructed agent: Financial institution that receives payment instructions from the Initiating Party and facilitates money transfer to the end recipient or next agent in the chain. Called an Intermediary Agent in ISO 20022, this entity is used when there’s no direct relationship between the sender’s and receiver’s bank. (In MT files, this was the Message Receiver.)

• Instructing agent: Financial institution that instructs the next party in the payment chain (e.g., Intermediary Agent / Instructed agent) to carry out the payment. (In MT files, this was the Message Sender.)

• Intermediary agent: Financial institution that helps facilitate payment by passing instructions from the Initiating Party to the recipient or next agent in the chain.

• Ultimate Debtor: Person or entity that owes money and is responsible for payment.

Talk with your Relationship Manager about how SVB solutions can help your business.

• Cash management & payment efficiencies

• How-to guide for SVB tax module

• Data-rich business insights

• SVB partner solutions compatibility (e.g. Plaid, Modern Treasury)

• API Banking enhancements

• Data rich business insights

• Risk mitigation

• How-to guide for SVB Go tax module

• And more

If you have questions

Please see contact info at the bottom of this page.

Migration of commonly used message types

Below are anticipated SVB migration timeframes. Information is subject to change. ISO 20022 MX message types not noted below are used less frequently by SVB. If you have questions, please email us at ISOSwiftPaymentQueries@svb.com.

Swift for Corporates – Credit transfer example


In the example below, the Debtor pays the Creditor using Swift for Corporates via Intermediary Agents. Intermediary Agents act as a bridge to facilitate payments between banks in different countries that don’t have a direct relationship.

New terminology for MX messages

MT data compared with more highly structured MX data

You can see more examples of the MX message structure below on this page.

Select MX message types

These are the most commonly used message types for SVB. This is not a complete list.

The four elements of an ISO 20022 message

• Category indicates the core message type

• Type refers to the purpose of the message (e.g., interbank payment instruction)

• Variant and Version indicate updates to the message, such as a status update.

MX message structure overview

Although messages vary in detail, they all follow the same basic format. The list below is an informal categorization of the components of a simple MX message.

MX message structure details

Unique IDs

• ID is in field 20 in MT, and supports only one identifier. In MX, structured data allows differentiation between different IDs, such as separating UETR from the new End-to-End ID field.

• An end-to-end ID is a unique identifier assigned to a payment transaction that makes tracking and reconciliation easier because the ID number remains unchanged across the entire payment process, from initiation to settlement. In contrast, a more general ID number may refer to any identifier used in a specific part of the payment chain and may change during processing, depending on the system involved.

• UETR has 36 characters and is unique to the payment transaction file. It can be traced over the Swift network and used by Swift to provide real time payment status.

Settlement

• Amount of money to be moved between the debtor and creditor, before deduction of charges, expressed in the currency as ordered by the initiating party.

• Charge Bearer is the party responsible for covering the costs associated with the processing of this transaction.

Ultimate Debtor/Ultimate Creditor

• The Ultimate Debtor is the party that ultimately owes the money to the creditor, even if another party is initiating the payment on their behalf. This data field is new for ISO 20022.

• The Debtor field has a similar structure. Debtor is the party whose account is debited in this step of the payment flow only.

• The Ultimate Creditor is the ultimate party to which an amount is due.

General inquiries

Current SVB clients and partners, please contact your Relationship Manager or your SVB Support Team.

If you do not have a relationship with SVB, you can get started with SVB.

Swift services


Current SVB clients and partners, please reach out to your SVB support team and ask about solution sales.

If you use another partner’s third-party service (e.g., fund administrator) to connect to Swift, please work with that partner directly.

If you do not have a contact at SVB, please email us at ISOSwiftPaymentQueries@svb.com