November 2026 Swift CBPR+ Mandate

Structured Addressing Required and MT101-to-pain.001 Migration Deadline

1. Hybrid/fully structured addresses required

Effective November 14, 2026, financial institutions and corporates sending cross-border payments that include addresses over Swift Cross-Border Payments and Reporting Plus (CBPR+) or key Payment Market Infrastructures (PMIs) must use hybrid or fully structured addresses. If using MT messages, senders must include structured Town Name and Country address elements (F-Option). This requirement also impacts domestic payments with a cross-border payment leg. Unstructured postal addresses will be removed after November 14, 2026.

How to prepare for the changes now

Wherever possible, use fully structured addresses; if that is not possible by the November 14 deadline, include structured Town Name and Country elements (at minimum) in your messages. Do not use “NOTPROVIDED” or similar inputs for these data elements.

  • Collect town and country information from payees if not already available.
  • Identify payment flows using addresses to ensure Town Name and Country are in structured data elements.
  • Update all Swift payment instructions and leverage Swift tools for validation of messages containing hybrid/structured addresses.
  • Use hybrid or structured addresses for any future-value-dated payments (i.e., payments with a value date of November 14 or later). If that is not possible before the November go-live, at a minimum, Town and Country should be included in the unstructured address lines.

For more information and implementation support, please review these resources.

2. Migrating from MT101 (FIN) to pain.001 (FINplus)

November 14, 2026, marks the end of coexistence of MT101 over Swift CBPR+ for Financial Institutions. MT101 payment initiation messages sent via FIN will need to migrate to pain.001v9 (MX) delivered via FINplus. Messages must be CBPR+ compliant and correctly formatted, or payments may be delayed or rejected and require resubmission. J.P. Morgan systems are ready to accept and process pain.001 messages globally and can support your migration testing.

Corporate Swift members using SCORE / MA-CUG are not impacted by this deadline and may continue using MT101, however they must update payment messages to meet hybrid address requirements.

How to prepare for the changes now

  • Review and assess your existing payment initiation systems and data formats, and plan and execute migration from MT101 to pain.001 by November 2026. 
  • Leverage Swift tools for validation. 
  • Before sending pain.001 messages, ensure you have exchanged RMA for pain.001. Leverage Swift’s Bootstrap event or manage RMA manually via the Swift RMA Portal.

Contingency option: Swift's In-Flow Translation service

If you are unable to migrate MT101 to pain.001 by November 14, 2026, and need to continue sending MT101 after the deadline, Swift offers a contingency service that will automatically translate single, eligible MT101 messages received after November 2026 into pain.001 before delivering them to the next agent or receiver. (Multiple MT101 messages will not be accepted.) Swift will charge MT senders for this service. 

Address formatting requirements will apply. Swift will not translate MT101 messages that contain unstructured addresses and will allow only hybrid or structured addresses on MX messages. When sending pain.001, populate all relevant address elements. If you continue sending MT101 via FIN, include Town Name and Country in postal address fields when using:

  • F usage flag for tag 50 and 59
  • D usage flag for tags 52, 56, 57 (if populated)

For more information and implementation support, please review these resources.

3. Enquiry and Investigation messages in MX format

Starting November 14, 2026, Swift is mandating all financial institutions be able to receive Enquiry and Investigation (E&I) messages in MX format (Camt.110 and Camt.111). J.P. Morgan will be ready to receive the MX messages.

What ISO 20022 means for our clients

ISO 20022 is a universal financial messaging framework for payments that leverages structured data fields to standardize cross-border payments, enhancing efficiency, reducing errors and facilitating global insights. The payments world is finalizing adoption of the standard globally, with the next critical deadline coming in November 2026 when only hybrid or fully structured addresses will be accepted by Swift, and payments with unstructured addresses will be rejected.

  • Banks and non-bank financial institutions connected to the Swift FINPlus platform must align with Swift’s end of coexistence roadmap and J.P. Morgan’s adoption schedule. Continue to plan and budget for ISO changes, prioritizing interoperability across cross-border payments and PMIs, and stay informed on evolving market practices while following industry guidance.
  • Banks, non-bank financial institutions and corporate Swift members who connect to J.P. Morgan via our proprietary channels must prepare for the removal of unstructured address data and migration to the new standards/requirements. Prepare to adopt the ISO 20022 standard soon and evaluate the benefits of enhanced data and how your business will use it.
  • Corporate Swift members, who connect to J.P. Morgan via Swift SCORE (Swift Standardized Corporate Environment) or a CUG (Closed User Group), may continue using MT101, however they must update payment messages to meet hybrid address requirements. Under Swift Standards Release 2026 (SSR2026), update MT101s to use the F-tag changes tied to the end of unstructured addresses so J.P. Morgan can process and forward payment messages. In 2026, we will begin offering SCORE Plus, including the pain.001 message.

    Example using the MT101 Field 59 (F-option) format for a hybrid postal address:

    :59F:/BE30001216371411

    1/JOHN SMITH

    2/HOOGSTRAAT 6, 18TH FLOOR

    3/BE/BRUSSELS, 1000

    Where: 1/= Name (JOHN SMITH), 2/=Address Line (HOOGSTRAAT 6, 18TH FLOOR), 3/=Country Code (BE), Town Name (BRUSSELS), and Postal Code (1000)

    If agents are identified by name and postal address in MT messages, use the D option. This approach ensures frictionless processing by the Debtor Agent upon receipt, aligning with best practices for address data submission.

    With the implementation of SSR2026, from November 2026 onwards, only Option F in MT101 messages will enable the transmission of properly structured postal addresses—specifically, the line containing the Town Name and Country Code will be mandatory for cross-border payments. Only Option F provides the structure required for these transactions.

    Some local payment methods, such as domestic transfers or SEPA, may still allow the initiation of payments using MT101 fields 50/59 with unstructured data. However, when address details are provided in an unstructured format, the bank processing the transaction will not be able to pass on these details. This limitation could lead to payment delays, rejections, or costly follow-up inquiries, especially for cross-border payments where structured address information is required.
  • FI/NBFI Swift Users, if you use native MX messages, you should no longer have truncation issues. Swift users leveraging contingency translation may still see the impact of truncation. In particular, name and address data may be truncated. Where possible, we’ll provide a “+” symbol as an indication of where truncation has occurred.

    Incoming funds may be paid to your account via MX messages, which may include enhanced information that could be truncated or omitted within existing reporting formats. Adopting the ISO-enabled reporting options will help mitigate these impacts. It’s important to start developing your implementation plan for camt messages. 

What clients should be doing now

  • Refer to the latest information available at the Swift Knowledge Centre, and understand the plans of your payment service providers, like J.P. Morgan, to align your plans accordingly.
  • Prepare to fully transition to ISO MX messages and consider all potential operational and technology impacts. 
  • Develop a plan to add structured address data for your clients where they are debtor party, and work with your clients to start collecting and organizing beneficiary details in a structured format. 
  • Remain aware of market developments and recommendations during the implementation phase, including those related to industry truncation risks. 
  • Check with your compliance team to understand your obligations related to enhanced data received within the MX messages.

Payment messages

Currently, all payment instructions must be exchanged in the ISO 20022 MX format. Instructions sent in the MT format are automatically converted by Swift to the MX format. (If unable to receive native MX payment messages, Swift's In-Flow Translation service, which requires connection to the Swift FINPlus platform, will enable clients to receive an MX message with embedded MT message information. Please contact Swift to arrange this service.)

Commonly used reporting messages are moving from MT (FIN) to MX (FINplus) camt (cash management) formats:

  • Bank to Customer Account Report: MT941/MT942 → camt.052
  • Bank to Customer Statement: MT940/MT950 → camt.053
  • Bank to Customer Debit/Credit Notification: MT900/MT910 → camt.054

We have a camt.53 and camt.054 schema on our Swift MyStandards page, to clarify key formatting features, particularly for elements subject to interpretation. Information on our camt.052/053/054 message formatting is provided within our camt.053 and camt.054 schema. Additionally for Payment Notification camt.054 you can refer to our Formatting Guide.

ISO camt messages require an RMA (Relationship Management Application), which is a bilateral authorization “handshake” that determines which institutions may exchange Swift messages and for which services/message types (see Swift RMA Support). To lessen the operational impact, Swift provided an optional bootstrap event for camt.052/053/054 message types that clients can leverage. 

The Swift community expects the adoption of camt (reporting) messages to take place gradually. So where possible, J.P. Morgan will leverage CBPR+ guidelines to adapt our MT9xx messages for credits by appending useful information from MX payment transactions, such as the following. These features are available for most EMEA account locations.

  • For credit transactions within the MT9xx series messages, we will provide a pacs End2End ID transaction reference as the Related Reference (e.g., MT910 field 21, MT940 Field 61 subfield 7) (except where we already customize this for clients).
  • We will enhance ISO data fields from the MX messages into the MT9xx series messages where there is enough space to do so (MT910 field 72, MT940 field 86), while avoiding impact to existing reference and data mapping features.
  • We will include a "+" at the end of fields where space allows. When data cannot be included due to insufficient space; this may apply to the following MT9xx series message fields: Related Reference, Party and Agent details and Sender to Receiver / Detailed Transaction Information. 

Until Swift’s reporting deadline takes effect in 2028, J.P. Morgan will continue to use enhanced MT9xx statement and advice reporting messages as the default reporting option, with the exception of serial third-party credit advices where we will send pacs.008/009. By late 2026, clients will have the option to receive MX reporting and Cash Management messages.

We also will continue to accept Swift MT210 messages until 2028 in account locations where those messages are accepted today, as well as camt.057 messages in those account locations. Note, we accept only single camt.057 messages; we do not accept multiple advices within the same message.

Beginning November 14, 2026, all cross-border payments must use either fully structured or hybrid structured addresses. Unstructured addressing will be decommissioned by Swift CBPR+ and some national clearing systems across the globe. (This also affects future-value-dated payments.) 

Implementation timing for address requirements is:

  • Fully unstructured: Only allowed until November 2026
  • Fully structured: already allowed today and preferred and recommended option in the future
  • Hybrid address: Allowed as of November 2025 (no end-date)

This guidance does not replace local legal or regulatory requirements; please continue to follow all current local laws and regulations for payment and beneficiary address information as required. Note: Financial Transactions and Reports Analysis Centre of Canada (FINTRAC ) requires full complete address that includes street number, street name, city, province or state, postal code or zip code, and country code.

The hybrid postal address format was introduced to the Swift FINPlus network in November 2025, allowing simultaneous use of structured and unstructured elements within the Postal Address and the 'Address Line' elements. In a hybrid address, Town Name and Country are mandatory, separate components within the Postal Address, similar to a fully structured address.

The Address Line element in the postal address can consist of up to 2 lines, each containing up to 70 characters (2*70) in the Hybrid format. It is important that the structured address information provided in the respective structured elements is not duplicated in the Address Line elements. 

See the Payments Market Practice Group (PMPG) Hybrid Postal Address guidelines (download) and their Hybrid Postal Address – Grace Period Guide for Banks for more information. Corporate clients may also refer to our What ISO 20022 means for Channels users section for information on our approach for Hybrid Address in bank electronic channels.

To aid reconciliation and onward processing for returned payments, J.P. Morgan will provide return reason information and certain relevant reference information (i.e., their original debit or credit references) where possible. (See ISO External Code Sets for industry guidelines on return messages.)

  • We send returns using the ISO 20022 pacs.004 Return message (instead of pacs.008 / pacs.009 with a return code). To receive these messages in MT format, use the Swift in-flow translation service. 
  • To initiate return messages via J.P. Morgan, clients may use pacs.004 messages, continue using MT with /RETN/ codewords, or send the return as a new payment.

For CBPR+ transaction legs, J.P. Morgan currently issues recalls and rejections and responds to incoming requests, including incoming camt.056 FI to FI Cancellation messages, using existing MT message types and practices. As industry adoption increases, we will begin sending the camt.056 and camt.029 (Resolution of Enquiry) messages. Similarly, we will continue to use MT199 in most instances to reject payment requests for CBPR+ transaction legs. We have begun implementation of the pacs.002 negative Customer Status Report regionally in 2026 and will complete global rollout by the end of 2027. (We do not plan to send or receive optional pacs.002 positive or pending status reports in the future.)

Swift has postponed its mandate to exchange all payment cancellation messages via the Stop and Recall Process (SRP) to November 2027. As a result, all payment cancellation messages, including Customer Credit Transfer (CCT), can continue to be exchanged bilaterally in both MT and ISO 20022 formats until November 2027. Stop and Recall will continue to be available to Case Management and GPI participants.

J.P. Morgan began receiving CBPR+ pain.001 v9 bank-to-bank messages in November 2025. We plan to implement sending these messages beginning in Q4 2026. Implementation of relay messages remains in planning. We will not require a specific pain.001 bilateral agreement.

J.P. Morgan will initiate charge claims via MT191 andcamt.106; we accept incoming camt.106. and MT191 charge claims. 

J.P. Morgan's Gateway service enables us to capture Fedwire- or CHIPS-initiated transactions and complement those transactions with value-added services and products.

As the Federal Reserve Bank adopted the ISO 20022 message format for the Fedwire Funds Service, clients should adhere to the Federal Reserve's formatting guidance to participate in the Fedwire service.

J.P. Morgan’s Gateway service is fully capable of supporting the ISO 20022 message format with no special or additional formatting requirements to maintain its current functionality.

For more information and implementation support, please review these resources.

What ISO 20022 means for market utilities

Certain impacts are unique for CLS USD Nostro, CLS Third Party, and Clearinghouse Settlement Service users; these are covered in this section. Refer to Payment messages, MX messages for reporting and Reporting roadmap for general information on other message types.

  • CLS USD Nostro Services: J.P. Morgan accepts CLS USD Nostro Pay-ins via pacs.009 (using the CLSTIME element - <SttlmTmReq> <CLSTm>) or Instructions for Next Agent containing the CLS codeword and time.
  • CLS Third Party Service: We send drawdowns for the CLS Third Party Service.
  • CLSNow and CLSCCP: We will accept payments via pacs.009; please use existing codewords in Instructions for Next Agent.

J.P. Morgan will liaise with each clearinghouse to discuss individual clearinghouse migration plans. We send drawdowns via pacs.010 messages and payments via pacs.009.

 

J.P. Morgan will liaise directly with SwapAgent to discuss migration plans.

For more information and implementation support, please review these resources.

What ISO 20022 means for Channels users

The November 2026 deadline to implement fully structured or hybrid address-format requirements affect any channel or solution used to submit cross-border payments over the SWIFT network, as well as payments routed through clearing systems that mandate hybrid or fully structured addresses (including, where applicable, Fedwire, CHIPS, SEPA, Swiss Interbank Clearing (SIC), CHAPS-UK, Target2-Euro, and South Africa’s SAMOS). Payments that do not meet the updated address standards may be rejected or delayed, which can impact end-to-end processing timelines.

This guidance does not replace local legal or regulatory requirements, which may vary by market and payment type and may impose additional address fields. Please review channel-specific guidance as applies to your situation and ensure compliance. For support, review the Market and Impact Overview and our Channels Resource/Support page, or contact your relationship team.

J.P. Morgan’s adoption schedule

In March 2023, CBPR+ went live, requiring all FIs and NBFIs to receive ISO 20022 MX payment instructions messages or Swift’s multi-format payment messages. Beginning in November 2025, ISO 20022 became the exclusive standard for cross-border payments and reporting, replacing legacy MT formats. Market Infrastructures (MIs), including TARGET2/EURO1, have also fully adopted the ISO 20022 standards, aligning with global efforts to standardize and enrich payment messaging.

For a detailed view of our adoption schedule, please see our ISO Migration Roadmap, which applies to Swift users using Swift FINPlus. 

Testing

To help client with testing their payment initiation messages, we provide a testing guide that includes a useful reference point for CBPR+ readiness and expands on lessons learned in ISO 20022 adoption. You also can reference:

  • Swift’s MyStandards schemas and the CBPR+ sample message library on Swift.com
  • J.P. Morgan’s Swift MyStandards schemas on Swift.com (currently available for pacs.008, pacs.009, and camt.054 and camt.053) which identifies how to populate bilaterally agreed codewords and indicators in the new schemas. (You will need to request access to this user group on Swift.com.
  • Swift’s Sparring Partner tool, which may reduce the need for bilateral testing between Swift members. (For more information on this tool, please contact Swift.)

Resources

Frequently asked questions

Updated February 2026

Our Frequently Asked Questions (FAQ) answers questions for all J.P. Morgan clients however, most are intended for Financial Institutions (FIs) and Non-Bank Financial Institutions that are Swift members. For non-Swift clients and Swift Corporate members, please refer to the What ISO 20022 means for Channels users section of this page.

Market infrastructures

J.P. Morgan is compliant with market infrastructures that have migrated to ISO 20022 and will be compliant for the upcoming ISO 20022 migrations in line with clearing market infrastructures timelines.

CHIPS migrated to ISO 20022 in 2024 and has made provisions to allow ISO-enabled data from CBPR+ messages to be passed between clearing participants from March 20, 2023.

FED migrated to ISO 20022 on July 14th, 2025.

  1. FED cut-off times: The FED is strictly enforcing their cutoff time for third-party payments at 6:45 p.m. EST. Payments received after the cut-off time will be held for processing on the next business day.
  2. FED IRS formatting guidelines: IRS Tax Payments must be formatted according to their specific guidelines, including the name and address. Please refer to IRS Tax payments section of the FED guidelines or this FED communication.
  3. Changes to Postal Address Data Validation: In their November 2025 newsletter, the Federal Reserve confirmed its intention to remove fully unstructured Postal addresses in favor of a single, hybrid postal address for all parties and agents across all message types. See the Federal Reserve’s On the Wire Newsletter series for more information.

TARGET2 and EURO1 migrated to the new standard on March 20, 2023. ECB announced earlier start times for TARGET2 and EURO1 settlement processing. As of March 20, 2023, both TARGET2 and EURO1 began settlement processing at 02:30 CET, instead of 07:00 CET for TARGET2 and 07:30 CET for EURO1. This means clients may receive inbound clearing credits from 02:30 CET onwards.

TARGET2 will no longer accept unpublished 11-digit BICs within payment messages. This includes 11-digit BICs of valid 8-digit BICs.

  • To ensure payment messages sent to J.P Morgan containing unpublished 11-digit BICs can still be settled through TARGET2, where we’re able to identify such instructions, the associated outbound payment message will be sent using the corresponding 8-digit BIC.
  • Clients who want to continue using unpublished 11-digit BICs within payments settled via TARGET2 should take steps to publish the BICs with Swift.

Effective May 1, 2025, the Bank of England (BoE) has mandated the use of enhanced data fields in CHAPS payment messages:

  • Legal Entity Identifier (LEI) for CHAPS payments between financial institutions
  • Purpose Code (PoP) for CHAPS payments between financial institutions; only relating to property transactions

J.P. Morgan has updated technology, processes and procedures to meet the requirements of this mandate. We encourage clients using the ISO 20022 message format to incorporate these elements more broadly in their UK payment instructions. Although payments lacking LEI or PoP will not be immediately rejected, BoE reserves the right to change its policy in the future.

BoE communicated plans to mandate Purpose Code (PoP) for ALL CHAPS payments instructed via JPM access channels (i.e. excluding Swift) from the second half of 2027.

BoE has announced earlier start times for CHAPS settlement processing, targeted for September 2027. Settlement will be enabled from 01:30 GMT, under an optional participation model. This means clients may receive inbound clearing credits from 01:30 GMT onwards.

The Philippine Payment and Settlement System (PhilPaSS) migrated to the new standard in July 2021.

The MAS Electronic Payment System (MEPS+) migrated to Like for Like (L4L) ISO messages in August 2022.

The Bank of Thailand Automated High-value Transfer Network (BAHTNET) migrated to the new standard in August 2022.

The Real Time Electronic Transfer of Funds and Securities (RENTAS) system migrated to the new standard in September 2022.

SAMOS migrated to the new standard in September 2022.

The High Value Clearing System (HVCS) migrated to the new standard in March 2023.

The New Zealand High Value Clearing System migrated to the new standard in March 2023.

The Japan Foreign Exchange Yen Clearing System (FXYCS) ISO 20022 messages updated its standards to Version 8 in November 2025, compatible with CBPR+.

The Hong-Kong Dollar Clearing House Automated Transfer System (CHATS) migrated to the new standard in April 2024.

The Taiwan Financial Information Service Co., Ltd migrated to the new standard in August 2025.

Lynx, Canada’s high-value payment system introduced ISO 20022 in 2023 with full transition effective November 2025.

Under Canada's Proceeds of Crime (Money Laundering) and Terrorist Financing Act and related regulations, all Canadian financial institutions including J.P. Morgan must collect complete remitter and beneficiary information for wires sent in SWIFT MT101, pacs.008 and pain .001 formats.

To comply, J.P. Morgan requires complete remitter and beneficiary information on all wire payments sent or received through your accounts with us in Canada, including, full account name, full account number, beneficiary bank’s SWIFT BIC (or the bank’s full name and address), and the beneficiary’s full physical address. The beneficiary’s full physical address includes street number or building name, street name, city or town, state or province (mandatory where applicable, e.g., Canada, USA, Australia) and country, preferably in the two-character ISO format. Note: A P.O. Box is not acceptable without a full physical address.

Some Canadian banks may require the Canadian Clearing code to avoid processing delays, and some may require that the beneficiary account number be prefixed by a transit code. Check your payees’ standard settlement instructions to confirm requirements.

Financial institutions may reject or delay your wires if the required information is not provided or if the address information does not include a full physical address. J.P. Morgan will reject wire payments with incomplete remitter or beneficiary information.

Disclaimer

© 2026 J.P. Morgan Chase & Co. All rights reserved. JPMorgan Chase Bank, N.A. Member FDIC. Deposits held in non-U.S. branches are not FDIC insured. Non-deposit products are not FDIC insured. The statements herein are confidential and proprietary and not intended to be legally binding. Not all products and services are available in all geographical areas. Visit jpmorgan.com/paymentsdisclosure for further disclosures and disclaimers related to this content.