SWIFT MX Messages - Focus on CBPR+ Structured Data Elements

Explore how CBPR+ structured data elements organize postal addresses in MX messages, contrasting structured versus unstructured formats and the rise of the hybrid postal address.

Evaluate interoperability challenges of mandating fully structured addresses for CBPR+ data elements amid corporate data gaps, mixed storage formats, and country-specific address norms.

Examine why Swift MX messages adopt a hybrid postal address, balancing fully structured and partial elements to meet FATF recommendation 16, ISO20022 data requirements, and regulatory needs.

Learn about the hybrid postal address in Swift MX messages, combining structured elements with unstructured address line, including mandatory town and country and up to two lines of 70 characters.

Cbpr+ hybrid postal address timeline in payment MX messages shows shift from unstructured to fully structured or hybrid addresses, with coexistence and one-year grace, and hybrid rollout from November 2025.

Explore how hybrid postal address elements affect Swift MX payment messages under CBPR+ structured data, with timelines for full structured, unstructured, and hybrid use from 2025 to 2026.

Understand the new hybrid address concept and the two mapping schemes for cbpr+ structured data, enabling MX to MT and hybrid MX to unstructured MX mappings.

Map hybrid addresses from MX to MT with option F, placing debtor in field 50F and creditor in field 59F; use subfields 1-3 for name, address, and country/town/post code.

Apply scheme 1 to map addresses into subfields 1–3, prioritizing name in 1, address lines in 2, country, town, and post code in 3, with 35-char limits, truncation plus sign.

Scheme 2 maps mx hybrid addresses to mx unstructured within cbpr+, using a priority list that assigns address lines, then country and town name, and post codes, separated by commas.

Explore the hybrid postal address concept, comparing fully structured and unstructured formats, and learn scheme 1 and scheme 2 for hybrid MX addresses.

Explore the structured remittance information in pain.001 and pacs.008, its role in payment reconciliation and enhanced invoice details, and CBPR+ rules for bilateral or multilateral use under BoE CHAPS mandates.

Learn how to structure remittance information using referred document information and amount, including type, number, date, due payable and remitted amounts, with invoice examples.

Examine the extended capabilities of structured remittance information, including line details, referred document amounts, deductions and adjustments, discount and tax details, and garnishment options for multi-invoice payments.

Learn how cbpr+ structured remittance information uses two basic elements, referred document information and referred document amount, for pacs.008 payments, with line details and Bank of England's November 2025 mandate.

Define regulatory reporting and when it applies to payments into or out of countries; populate the regulatory reporting element in pacs.008 and pain.001 by debtor and creditor agents to comply.

Learn the structure of regulatory reporting in pain 001 and pacc 008 messages, including authorities, details elements, and country-specific codes like PURP and P 0101.

Identify challenges in populating regulatory reporting due to nonstandardized rules and missing centralized mapping. Follow best practices by using minimum elements and country-specific regulatory reporting tags to avoid delays.

Explore cbpr+ regulatory reporting on the debit side in cross-border payments, from France to a non-resident country, with pain.001 and pacs.008 messages carrying debit reporting, purpose purp and e01 goods.

Analyze a cross-border payment from Australia to the UAE, highlighting how cbpr+ data elements show credit-side reporting, UAE’s PPL code, and the purpose of payment for non-resident real estate.

Shows how cross-border payments from country x to country y trigger two separate regulatory reporting on both sides, including declaration and purpose code, with country-specific formats.

Explain purpose code in ISO 20022 payments using the ExternalPurpose1Code list to convey the non-regulatory commercial reason end to end in pain.001 and pacs.008, with code preferred over proprietary.

illustrates using the purpose of payment code HLTI to designate health insurance payments in pain.001 and pacs.008 messages, with no regulatory reporting required in Great Britain or Singapore.

This lecture explains using both regulatory reporting and purpose codes in a cross-border payment, detailing pain.001 and pacs.008 messages, ExternalPurposeCode1 as SAVG, and P1301 for family maintenance.

Populate the category purpose in Swift MX messages using the external code list or proprietary form, to signal special processing by chain agents for government, salary, or pension payments.

Demonstrate how the category purpose element in a pacs.008 message classifies a security payment from a debtor in Great Britain to a creditor in Singapore, triggering batch processing.

Explore the similarities and distinct roles of regulatory reporting, purpose, and category purpose in payments, including who uses them and why, with a case study of their combined use.

Explore a case study of a fully structured pacs.008 payment for trade finance, highlighting category purpose, regulatory reporting, remittance details, and codes like TRAD and P0101 for AML and reconciliation.

Learn how the legal entity identifier (LEI), a 20-character alphanumeric code, uniquely identifies counterparties in financial transactions, providing precise entity identification and ownership clarity for MX messages.

Explore how the ISO 17442 LEI code uniquely identifies a single legal entity with a 20-character string, published by GLEIF, to enhance payment party authentication and transparency.

Identify the ultimate debtor, ultimate creditor, and initiating party in MX messages, noting they are separate legal entities and payments are initiated from the debtor’s or creditor’s accounts.

Explore scenarios illustrating ultimate debtors and creditors, including a law firm paying from a trust account and a parent company settling subsidiary invoices, with payroll outsourcing as the initiating party.

Identify ultimate parties to increase transparency in payments and fight financial crime; MX messages carry detailed ultimate party data, and agents must ensure this information is forwarded unaltered.

Learn correct use of ultimate party elements in iso20022 payments and avoid duplicates, department names, or product-name misplacements. Use remittance information for on behalf of transactions to support MT-MX coexistence.