CBPR+

ISO 20022 defines a global data model with hundreds of optional fields, multiple valid code sets, and significant flexibility in how parties structure their messages. That flexibility is useful for domestic implementations that can define their own rules, but it creates interoperability problems on a network where thousands of banks must exchange messages reliably. CBPR+ is SWIFT’s solution: a community-agreed usage guideline layer that sits on top of the ISO 20022 standard and tells SWIFT member banks exactly how to use each field.

What CBPR+ Restricts

CBPR+ does not extend ISO 20022 — it constrains it. Key restriction categories:

Field-length caps. ISO 20022 may allow a text field up to 140 characters; CBPR+ may cap it at 35 or 70 characters for a specific element. If your system populates fields to the ISO 20022 maximum and those fields pass through a CBPR+ hop, data can be truncated at the sending bank before the message leaves the SWIFT network.

Mandatory vs optional elements. CBPR+ promotes certain ISO 20022 optional elements to required status. The UETR is the clearest example — optional in raw ISO 20022 pacs.008, but mandatory under CBPR+ for GPI payments. Structured creditor addresses, agent BICs, and purpose codes each have CBPR+-specific rules.

Code set restrictions. CBPR+ specifies which ISO 20022 code sets are acceptable for a given field. Using a code that is valid under ISO 20022 but not in the CBPR+ approved list will fail SWIFT network validation.

Prohibited elements. Some ISO 20022 fields are not permitted in CBPR+ messages — either because they have no cross-border applicability or because they create ambiguity in the correspondent chain context.

The Migration Timeline

SWIFT ran a coexistence period from November 2022 to 22 November 2025 during which both MT and ISO 20022 (CBPR+) messages were supported on the SWIFT network for cross-border payments and cash management. During coexistence, SWIFT’s translation service converted between MT and MX at the network layer. That service ended on 22 November 2025 — the SWIFT network no longer accepts MT103, MT202, MT940/950, or equivalent cash management MTs for cross-border flows. CBPR+ MX messages are the only option.

For operators, the visible effect of this cutover was primarily at the corporate-to-bank API layer: banks that previously accepted MT101 payment files or offered MT940 statement feeds updated their APIs and file formats. If your treasury or ERP system still uses an MT-based bank connectivity format, your bank will have migrated or replaced that interface.

Why Operators Care About CBPR+ Specifically

“ISO 20022 compliance” is not a precise claim. A bank could implement ISO 20022 pacs.008 for its domestic scheme using completely different field constraints from CBPR+. When you are dealing with cross-border SWIFT payments, the relevant question is always whether the implementation follows CBPR+ — because that is what determines which data survives a hop.

The practical examples:

• Remittance data truncation. If your bank statement field mapping, ERP data model, or reconciliation logic was designed around MT103 field lengths, the CBPR+ pacs.008 equivalents may carry more data — or differently structured data — than the old MT fields.
• Field mapping from MT103 to pacs.008. The MT103-to-pacs.008 field mapping reference documents the CBPR+ field-by-field translation. Use it to understand what happened to each MT103 field in the migration and which CBPR+ restrictions apply.
• Investigation message changes. Investigations that previously used free-text MT gpi messages now use camt.028 (status request) and camt.056 (recall request). The camt messages are also governed by CBPR+ usage guidelines — field constraints apply there too.

CBPR+ guidelines are published on SWIFT MyStandards, which requires a SWIFT portal account. Banks and technology vendors participating in the SWIFT network can access the full specification; the guidelines themselves are not publicly available without registration.