Yes. Since its inception, we have been an active participant in the CBPR+ ISO 20022 migration project.

Following the end of co-existence period, from November 2025 Swift Supervised Financial Institution and Swift Non-Supervised Entities have migrated to FINPlus ISO 20022 MX messages. At this time, Swift Closed User Groups (CUGs) and Swift Corporate members are not scheduled to migrate by Swift. If you are unsure of your Swift user category or wish to further discuss Swift’s migration plans, please contact Swift directly.

Following the end of the co-existence period, J.P. Morgan will only accept MX payment messages from our clients with our outbound payment messages remaining in MX format (pacs.008/009), including serial third party credit advices.

Institutions that are not MX-enabled by default benefit from Swift’s in-flow translation service, as long as they have completed the mandatory connection to the Swift FINPlus platform in March 2023.

J.P. Morgan ’s MT9xx statement and advice reporting messages will remain on MT until clients opt-in to move to MX equivalent (camt) in late 2026.

As per current Swift communication the end-of-coexistence period for statements and reporting message is November 2028. Details on Swift Support Page.

For the latest Swift updates please refer to ISO 20022 for Financial Institutions – Support Page.

We have provided enhanced information within MT9xx messages since March 2023 and will continue to provide until mutually agreed migration to MX equivalents. The planned rollout for MX reporting is currently later in 2026.

Given that the adoption of camt messages is expected to take place at a later date, where possible, we are adapting our MT9xx messages for credits to append useful information from MX payment transactions; leveraging CBPR+ guidelines (access to Swift resources only for registered users).

• Providing pacs End2End ID Transaction reference as the "Related Reference" (e.g., MT910 field 21, MT940 Field 61 subfield 7) for credit transactions within the MT9xx series messages where provided (excluding business scenarios where we already customize this reference for clients)
  
• Mapping enhanced 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) whilst avoiding impact to existing reference and data mapping features.
• Including "+" at the end of fields where possible, in case data cannot be included in the message due to insufficient space; this may apply to Related Reference, Party and Agent details and Sender to Receiver / Detailed Transaction Information fields (for example, Beneficiary details (T58/T59) within the MT9xx series messages).

These additional features are available for most account locations from 2023.

For returned payments, we are planning to provide return reason information as well as the most relevant reference information to clients(i.e., their original debit or credit references) to aid reconciliation and onward processing. This applies to:

1. Incoming camt type of returns
2. MT return instructions – clients will observe a change in statements and advices generated for their return instructions after this feature is turned on

For more specific information on this, see the Returns Processing section on our Client Resource page.

J.P. Morgan is planning to align to each financial Market Infrastructure (MI) it directly participates, to send the appropriate message type for that MI. (See the Market infrastructures section on Client Resource Center.)

Since CBPR+ go-live in March 2023 there are limited numbers of issues with payments caused by:

• Agents connectivity aborts with Swift FINPlus network
• Agents using translated MT issues
• Poorly formatted MT message without sufficient data to create MX message

Please direct questions to your client service account manager. We are here to support you as you navigate through these changes.

Since go-live date of March 20,2023 we support pacs.008/009 messages in line with CBPR+ and MI requirements.

Since go-live date of March 20, 2023, we are sending pacs.008/009 messages, including serial third party credit advices.

The end of coexistence for MT101 messages over Swift Fin network for banks and NBFI is due by 14^th of November 2026, with all client migrations to be completed ahead of this date. As per Swift changes all Swift members involved in CBPR+ migration are required to be ready to receive the pain.001 v9 bank to bank messages since November 2025 (SR2025).

J.P. Morgan adopted the CBPR+ pain.001 v9 bank to bank message and is able to receive from November 2025, on a send basis Q4 2026, and a relay date to be confirmed.

In addition to this, using a risk based approach, J.P. Morgan has decided it will not require a specific pain.001 bilateral agreement.

Starting in March 20, 2023, J.P. Morgan sends ISO 20022 pacs.004 return messages.

From March 20, 2023, for required MI-related messages and CBPR+-related messages.

From March 20, 2023, for CBPR+ transaction legs, J.P. Morgan will initially issue recalls and rejections and respond to incoming requests (including incoming camt.056 FI to FI Cancellation message) using existing MT message types and practices. We will start sending the camt.056 and camt.029 (Resolution of Enquiry) messages as industry adoption increases.

Similarly, J.P. Morgan will continue to use the MT199 in most instances to reject payment requests for CBPR+ transaction legs and will start sending the pacs.002 negative Customer Status Report as industry adoption increases.

We do not plan to send (or receive) any optional pacs.002 positive or pending status reports from March 2023 or in the future.

As part of the Swift Pilot on Enquiry & Investigation, J.P. Morgan will be able to receive camt.110 and camt.111 in line with November 2026 mandate. 

J.P. Morgan used to send MT199/MT299 with details of truncated data as described in our eBook “ISO 20022: First 120 days live.” However, as Swift Transaction Manager is fully enabled now, J.P. Morgan has stopped sending additional messages in line with market practice guidelines found here.

Please note that our eBook “ISO 20022: First 120 days live” contains comments current at the time of writing (circa June 2023). This FAQ document is updated on an ongoing basis.

Yes. While J.P. Morgan support the effort to evolve inquiry processing to structured messaging via Swift’s centralized service capability; we anticipate it will take significant time to evolve away from the MTn99 series.

The MT n99 series has been used for many different purposes over the years, and this will complicate the evolution toward defined, structured messaging for all flows. Although specific MT messages (MT195, MT196) existed for inquiries, most of the Industry still today relies on n99 messages.

As we move through the ISO implementation these messages are designated to be replaced, particularly for Inquiry processing, where the camt.110 Inquiry and camt.111 Inquiry Response are intended to provide a significant efficiency gain for routing and resolving inquiries. Immediate benefits will include the identification of inquiries distinct from myriad other uses of MTn99 messages, and the ability to straight through process, and engage with Swift’s Transaction Manager for potential automated resolutions.

For other uses of the MTn99 series, Swift will introduce the admi.024 message.

The J.P. Morgan perspective on the evolution of these messages is that timing and sequence of implementation is key to success.

J.P. Morgan suggest Swift users focus on their implementation from the perspective of Payment Execution first, followed by the implementation of Advices and Statements. This will ensure maximum efficiency in the processing of payments and in their reconciliation. After we gain proficiency in exchanging the new MX messages for execution and reconciliation, the next logical step is to improve our exception management, and invest in camt 110 camt 111 and examine Swift’s gCase service.

As of June 2024, Swift suggest that MTn99 messages are ‘deprecated but supported’ after November 2025.

J.P. Morgan suggest that after the Industry is fluent in the exchange of pacs, pain and camt Statements and Advices, the benefit of structured inquiries will become more obvious, and the use of the MTn99s will deliver a diminishing result.

Until then, we plan on continuing to support our clients with the n99 series.

There is a practice across the industry where an FI may send an MT199 message with Debit Authorisation within the narrative of the MT199, advising a Return of Funds. It is strongly encouraged that a pacs.004 is used for a Return of Funds, and the usage of MT199 for this practice should not be continued.

It is not permitted to initiate a return with a pacs.002. Behaviour has been identified within the industry where a pacs.002

is sent for a settle payment with free text narrative instructing the receiving Bank to perform a return of funds and providing debit authority within the pacs.002 message.

A pacs.004 must be used to instruct the return of funds so that debit authority is not required for the Agent receiving the instruction to debit the account and complete the return of funds instructed.

The pacs.004 will allow automation and not require manual handling; the receipt of a pacs.002 will be time-consuming and open an investigation ticket at the receiving end, which is costly.

Note that a pacs.004 is a movement of funds, whereas the pacs.002 is a rejection message and does not create a funds movement.

From Q4 2024, we are able to accept ISO 20022 reporting messages (camt.052, camt.053,camt.054) from FI/ NBFI to FI/ NBFI on Swift after bilateral agreement and after parallel run or sample testing with our counterparties. Multibank Reporting will be available at a later date (to be defined).

Following the recent announcement from Swift changing the deadline for MT reporting to November 2028 ,J.P. Morgan is working on implementation MX reporting in 2026  and continue to send enhanced MT9xx statement and advice reporting messages as default. We will transition clients to the MX equivalent(camt.052/053/054) messages using a risk managed approach and on an opt-in basis planned to start late 2026.

J.P. Morgan will continue to accept Swift MT210 messages until 2028 (in line with the Swift roadmap) in account locations where those messages are accepted today. Since March 2023, J.P. Morgan has been accepting camt.057 messages instead of MT210 messages in those account locations; however, note only single camt.057 messages is accepted and not multiple advices within the same message.

Whilst the camt.058 - Notification to Receive Cancellation Advice, replacing the MT292 was introduced by CBPR+ in the November 2023 release JP Morgan started support from November 2024, for EMEA. This has not been enabled for APAC and it is not applicable for WHEM. For any of the geographies that are not supported yet, we ask that clients continue to send the MT292 when wanting to cancel an ATR / Notice to Receive (MT210 / camt.057).

The Swift “Cross-Border Payments and Reporting” (CBPR+) program runs from March 20, 2023 through November 2029, during which time Swift will migrate from MT messages to ISO 20022 MX messages.

Swift Closed User Groups (CUG) and Swift Corporate members are not required by Swift to migrate to ISO 20022. If you are a Swift user and unsure of your Swift membership type or wish to further discuss Swift’s migration plans, please contact Swift directly.

The CBPR+ initiative provides financial institutions a globally consistent data model that delivers enriched reporting, compliance, and reconciliation data.

A cross-border settlement is a payment from an account in one country to an account in another country, i.e., the payment crosses borders.

No. Although CBPR+ is a Swift cross-border event, many local market practices are also adopting ISO 20022. (See section 1 for more details.)

Although CBPR+ only affects how financial institutions exchange messages, the ISO data model results in additional data being present in a payment instruction.

Even though corporates are not required to adopt ISO 20022 at this time, benefits include efficient reconciliation, enhanced invoice information at scale, and fewer manual processes. Due to the increased data that ISO 20022 will provide, there may be cases where a cross-border settlement provides more information that can be reported in a corporate’s current banking interface.

Corporates should discuss their reporting and reconciliation needs with their financial partners, to explore how adopting the ISO data model may streamline their processes.

Where possible, J.P. Morgan is adding the ‘+’ symbol as the last character of a field where data has been truncated.

Yes, corporates do not need to migrate from their existing payments or reporting formats.

• Swift members registered as an FI/NBFI (general/generic members) can use either Swift FIN MT or Swift FINPlus MX messages
• Swift members registered as a corporate (SCORE member) can use either Swift FIN MT or Swift FileAct.
• Corporate SCORE members cannot use Swift FINPlus

• Swift members registered as an FI/NBFI (general/generic members) will no longer be allowed to use FIN MT Category 1/2/9 and must use Swift FINPlus MX. Note nonpayment service providers should seek guidance from Swift as to what message types to use to initiate payments (i.e., pain instead of pacs messages).
• Options for Corporate (SCORE) Swift members post March 2023 have not been clarified at this time. We will aim to keep our clients informed as industry plans for this are developed. We would also recommend clients also engage directly with their Swift relationship contacts on this topic.

Swift has published the type of membership on their website, Swift.com (e.g. whether BIC (Bank Identification Code) is registered as a financial institution or as a corporate). Any individual can go onto their web page, search for the BIC of the institution they are interested in and will be able to see the type of membership that institution holds (either Financial or Non-Financial).

Yes, corporate SCORE Swift members can use MT messages, but please note:

• Due to field length limits, data may be truncated in an MT message if the settlement was received as an MX message.
• Local-language (UTF-8) may become permissible after 2025 or may be required by local market-practices. MT messages are limited to the X-Character set.
• When MX data is truncated in an MT message, the industry convention is to add a “+” as the last character at the end of the MT field, conveying that data was dropped.
• As ISO is adopted by local market practices, local regulations may require the use of structured counterparty name and address, which may not be possible to construct in an MT101 using the 50F/59F option.

Swift will only continue to support existing messages for corporate clients only.  As a result of the ISO migration there is an indirect impact to all clients regardless of what channel is used to initiate payments, it has been mandated at an industry level that since November 2026 if an address is provided for any party in the payment instruction, it must be provided in a structured or hybrid manner. The minimum information that must be provided is Town name and Country.

Payments in scope of this requirement are all CBPR+ (cross-border) payments and urgent domestic transactions (RTGS). ACH payments are out of scope.

After November 2026 , the minimum mandatory information that must be provided is Town name and Country. If either element is missing, the transaction will be rejected. Whilst J.P. Morgan may not be able to verify the quality of additional  information provided upfront, standard business validations, in accordance with local laws and regulations that exist today, will continue to be applied in future. J.P. Morgan cannot guarantee that payments will be executed successfully if the information provided is insufficient or incorrect.

The deadline to be fully compliant is November 2026. Any payments in scope for this requirement, that do not meet the formatting specifications after November 2026, will be rejected.

Corporate clients can take the following steps to begin preparing for ISO 20022 adoption:

• Contact your current Enterprise Resource Planning/Transport Management System (ERP/TMS) provider to discuss if any system changes are required to support the richer ISO 20022 data.
• Analyse whether moving to ISO 20022 makes sense for your organization if you are currently making payments and receiving statements in non-XML format.
• Migrate to ISO 20022 (either pain.001 V3 or pain.001 V9) as soon as possible if you are currently making payments in a non-XML format via H2H
• Improve your own static data – at a minimum, obtain and complete beneficiary details with their full addresses.
• Speak to your J.P. Morgan representative to find out how we can support you.

There are a range of new XML tags in pain.001 v9 such as dedicated fields for UETR, and identification of legal entities by the Legal Entity Identifier (LEI). There are also new XML tags for additional structured remittance as well as more detailed address information.

There is no obligation to migrate to pain.001 v9. J.P. Morgan will continue to accept the currently supported 2009 version of ISO 20022 format. Whilst there is no immediate need to migrate, clients may wish to consider migration at a later stage once ISO 20022 is adopted worldwide to take advantage of the benefits it offers.

Swift has also published a variety of resources to help navigate the transition to ISO 20022. These can be accessed through Swift.com, your MySwift homepage, and on the Swift Knowledge Centre.

This is the service created by Swift for sending ISO 20022 messages, using InterAct. It is comparable to their FIN service. All financial institution and non-bank financial institution clients that receive Swift payment messages today MUST be connected to this by March 20, 2023.

This is the service provided by Swift, enabling receivers of Swift payment messages to receive an embedded MT version of a payment message, in addition to the original ISO MX message. This resource is an important industry service that enables sending institutions to freely choose when to send ISO messages. (See Swift’s webpage for details.)

To help mitigate issues with processing translated MT messages, clients may wish to consider adoption MX messages at the earliest opportunity.

TM is Swift’s new platform deployed in May 30 and Sep,30 2023. It is a part of Swift’s transaction processing for payments that are initiated in MX (pacs) format. TM will enhance data integrity for cross border payments, preserving data quality based on rules defined by the Swift user community.

All payment messages exchanged over Swift contain a unique end-to-end transaction reference (UETR) that is generated by the first customer in the transaction chain when initiating a transaction and all FIN and FINPlus customers must use the same UETR in subsequent messages that are part of the same transaction. Recycling of a previous UETR for a different transaction disables tracking and introduces the risk that the UETR could be reconciled with the wrong transaction.

This may lead to the application of data integrity rules to messages not linked to the original transaction which first carried the UETR that has subsequently been recycled This may potentially negatively impact all actors in the transaction chain, including underlying customers.

Please contact your Swift representative or Swift National or Community group lead. Swift.com also has more information you may find helpful. Please also refer to the latest information available at the Swift Knowledge Centre, including Operations Guide, Service Description, Business Processing Rules and FAQ documents.

You can also contact your J.P. Morgan representative for a more detailed discussion about what these changes could mean for your institution.

Please refer to J.P. Morgan CBPR+ Client Testing Guide for a useful reference point for CBPR+ readiness.

Some detailed information about MX message formatting is also available later in this FAQ document.

For sample messages, please reference the CBPR+ Sample Library in the Swift Portal (for Swift registered users only). J.P. Morgan will be following CBPR+ standards, for messages sent from us to our clients.

J.P. Morgan MyStandards on Swift.com can be referenced for pain.001. If you do not have access via Swift.com, you can submit a request through Swift MyStandards for access to “MyStandards Community by J.P. Morgan.” You can also contact your client service account manager with the email addresses of users who should be added.

Please refer to CBPR+ schema published by Swift.

Please reach out to your Swift account representative.

For general testing of MX messages, Swift Test Sparring Partner (TSP) is an automated testing facility that will support the community in readiness testing of CBPR+ messages and flows. TSP allows users to simulate flows as a debtor, creditor, or intermediary agent for a set of pre- defined test scenarios.

J.P. Morgan Readiness Portal on Swift MyStandards can be referenced for testing pacs.008 and pacs.009.

General Swift Translation Portal can be useful to clarify doubts about the mapping of current MT messages to their new MX equivalents.

We will accept all bilaterally agreed codewords that we accept today.

High-level, we will accept codewords in the following data elements:

• Service Level – Proprietary e.g. "CODEWORD"
• Instruction For Next Agent – Instruction Information e.g. "/CODEWORD/"

Please refer to our pacs.008 and pacs.009 schema for detailed information on where and how they can be captured. Search by the term “JPMC” to see where we have added comments.

There are three distinct methods for instructing J.P. Morgan to process priority payments, and only one option can be used at a time:  

1. <Settlement Priority>: This element can be used to indicate to J.P. Morgan that a payment should be treated as a priority. The values "URGT" or "HIGH" will both be recognized and processed with the same level of priority.
2. <Service Level> <Proprietary>: This method involves using the codeword "PRIORITY" as an alternative approach. Please note that the codeword here must be used without slashes ('/').
3. <Instruction for the Next Agent>: This method uses the codeword "/PRIORITY/" (with slashes) to indicate that the payment should be prioritized. However, this option is the least recommended, as Swift is considering eliminating the use of free format elements in favour of specifically designed elements in MX messages.

Please ensure that only one of these methods is used for each transaction to prevent any processing conflicts.

In a scenario where Clearing Member ID (example ABA ID) is provided without name & address or BIC, Swift will still accept the message. It would work even if just the BIC is provided in the BICFI data element without Clearing Member ID. The CBPR+ schema published have details of all the rules.

The below provided examples will work fine

<CdtrAgt>

           <FinInstnId>

                   <ClrSysMmbId>

                                     <ClrSysId>                                                  

                                                   <Cd>USABA</Cd>

                                  </ClrSysId>

                                 <MmbId>021000021</MmbId>

                  </ClrSysMmbId>

                 <Nm>JP MORGAN CHASE BANK</Nm>

                 <PstlAdr>

                                 <AdrLine>ABC, CDE, EFG</AdrLine>

               </PstlAdr>

            </FinInstnId>

</CdtrAgt>

OR

<CdtrAgt>

         <FinInstnId>

                         <BICFI>CHASUS33</BICFI>

        </FinInstnId>

</CdtrAgt>

The above example is for creditor agent but format is the same for any agent where this is being supplied.

The Clearing Member ID should be provided without using double slash (//) as double slash was used for MT formatting. Similarly, BIC should never be preceded with double slash.

Yes, currently there is no change to this existing service. 

Currently, there are no changes required to existing codes in use. 

The current mode of communication will remain unchanged. We will continue to contact clients through existing channels, such as email or MT199.

From the perspective of client initiating payment instructions to J.P. Morgan via Swift FIN, between the local MI go-live dates and March 2023, we will continue to accept MT format from clients until March 2023 when we will be able to accept either MT or MX.

In Australia, 15 (or more) digits are used to identify individual accounts. The first six digits is the bank code, which is used to identify both the bank and the individual branch. The remaining digits make up the account number and are used to identify your individual account. Account numbers can be 9 to 12 digits and vary from one bank to another. The two numbers give banks the information needed to transfer your funds correctly.

Yes, BSB (Bank State Branch) continues to be mandatory in domestic MX instructions. They are used as identifiers in the population of financial institution elements and debtor and creditor elements in MX messaging for routing and clearing payments.

There will be no additional data requirements on top of the current MT messaging standards for New Zealand. As industry updates become available for the subsequent phase, we will provide further information at the earliest opportunity.

New Zealand has established a co-existence approach where J.P. Morgan will still be able to exchange MT messages with clients until 2024. Given the benefits of ISO, we encourage clients to consider migrating soon. In markets where MIs will be adopting the new ISO standards instantly, J.P. Morgan will leverage the MX format to process clients’ transactions.

• Clients initiating payments in Philippine Peso (PHP) to a beneficiary in the Philippines from offshore are required to comply with a AML regulatory requirement (for Corporates) and include the Date of Incorporation of the remitting client.
• The purpose of payment is required to be reported for all incoming and outgoing cross-border wire payments to and from the JPMorgan Chase Bank N.A. Manila branch. Provide a purpose for payment formatted as “/ACC/PURPOSE/9999999999” or “/REG/9999999999” where “9999999999” is the 10-digit purpose code. Payments received without a specific purpose code will be placed on hold for 5 banking days and if not provided by this time, will be cancelled and returned to the remitter. The purpose of payments is required to classify foreign currency transactions and facilitate the requirement of Bangko Sentral ng Pilipinas (BSP) for all Authorized Agent Banks to submit the Consolidated Report on Foreign Exchange Assets and Liabilities (required schedules and timeline clarified within Section 101 of the Manual of Regulations for Foreign Exchange Transactions (MORFX)

Canada AML regulator FINTRAC mandates name, account, and complete beneficiary address information, along with complete remitter details including address information in all wire payments. Per Payments Canada, the best practice is to utilize the structured address components where it will be mandatory to provide address information in the structured address fields for country, town name and street name. No P.O. Boxes are allowed. Beneficiary banks may reject wires where beneficiary name, account, and address do not match their records. 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.

Following migration to ISO 20022, the TARGET2 system is no longer accepting the use of 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 J.P. Morgan is able to identify such instructions, the associated outbound payment message will be sent to TARGET2 using the corresponding valid 8- digit BIC.

Clients who wish to continue to use unpublished 11-digit BICs within payments settled via TARGET2 should take the necessary steps to publish the BICs with SWIFT.

Effective May 1, 2025, CHAPS payments must include the Legal Entity Identifier (LEI) for payments between financial institutions and the Purpose Code (PoP) for property-related transactions. The mandate is limited to payments instructed via channels in control of the direct participant (e.g. H2H, API J.P. MORGAN Access Online, EBICS). While Swift initiated payment instructions are not currently in scope given the intent of the mandate is to drive adoption of enhanced ISO 20022 data, clients using the ISO 20022 message format are encouraged to provide these elements more broadly in payment instructions.

No, payments will not be immediately rejected if they lack LEI or PoP as of May 1, 2025. However, the Bank of England is expected to tighten its policy in the future (not before November 2027), requiring these elements in all CHAPS payment messages. Clients are encouraged to include these fields as soon as possible to prepare for this change.

Clients should begin incorporating LEI and PoP in their payment instructions to align with the anticipated broader mandate. This proactive approach will ensure smooth payment processing and compliance with future policy changes as the adoption of ISO 20022 messaging standards progresses.

Property Purpose Codes

• HLRP: Property Loan Repayment 
• HLST: Property Loan Settlement 
• PLDS: Property Loan Disbursement 
• PDEP: Property Deposit 
• PCOM: Property Completion Payment 
• PLRF: Property Loan Refinancing