ISO 20022 Migration

• ISO 20022 Payments Migration and Interoperability Considerations (published November 2022)
• Best Practice Guidelines for the Payment Industry Migration to ISO20022 (published January 2022) (launches download)
  REMINDER: The PMPG’s industry guidance recommended avoiding origination of the following rich data elements until at least November 2023 ("Target Date"). According to the guidance, not all banks have upgraded their initiation channels to enable use of rich ISO 20022 data. Banks that have done so are encouraged to request that their clients refrain from populating these elements until sometime after the Target Date, as it could trigger truncation or dropped data, and could result in payment delays or reconciliation issues.
  
  • Ultimate Debtor
  • Ultimate Creditor
  • Category Purpose
  • Structured remittance data
  • Related remittance info
• CBPR+ Data Integrity Market Practice Guidance (Swift user ID and Password required)

These guidelines for banks have been developed by CBPR+ to manage potential risks where enhanced data elements are truncated or dropped altogether at some point in the payment chain.

Truncation during Market Infrastructure transaction legs:

The industry guidance may also be applied to a transaction leg settled across a local Market Infrastructure (i.e., currency clearing systems) that has not yet adopted the ISO 20022 standard.

CHIPS migrated to ISO 20022 on April 6, 2024 and made provisions to allow ISO-enabled data from CBPR+ messages to be passed between clearing participants from March 20, 2023. As announced in June 2022, Fedwire Funds Service was to migrating to ISO 20022 no earlier than March 2025.

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.

Also, 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.

CHAPS migrated to the new standard on 19 June 2023. Planned for this Spring 2024 Transition State 3 has been delayed to late Summer 2024.

Based on the published market practice guidelines, we recommend not using enhanced data before the Target Date (November 2023) for all currencies, including GBP.

If enhanced data is used for GBP payments before the Target Date, it may result in truncated data. Where this occurs, it may be indicated by a "+" symbol in the payment message. 

More information is available on the Bank of England website. We encourage you to review the Memorandum of Understanding (MOU), Whitelabel Communications, and Technical Guidance documents, which directly references the published market practice guidance (CBPR+ Data Integrity Market Practice Guidance).

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.

MYR 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 on March 20, 2023.

The NZ High Value Clearing System migrated to the new standard on March 20, 2023.

FXYCS adopted ISO 20022 in 2013, using the ISO 20022 version available at the time. The following two-phase approach was agreed to for CBPR+ messages (MX):

1. During the co-existence period through November 2025, an agreed mapping of incoming MX into the current FXYCS ISO 20022 format will be implemented by clearing participants. No changes are expected in the existing FXYCS messages.
2. The Japanese community and the operator of FXYCS will agree on a future date to upgrade the current FXYCS format to a format that is interoperable with the current HVPS+ format.

Lynx migrated to the new standard in March 2023, in alignment with Swift’s implementation.

Hong-Kong CHATS is migrating to ISO 20022 in April 2024.

1. Refer to the latest information available at the Swift Knowledge Centre, including Operations Guide, Service Description, Business Processing Rules and FAQ documents.
2. Understand the plans of your payment service providers like J.P. Morgan to align your plans accordingly.
3. Have an implementation plan for fully transitioning to ISO MX messages and consider all potential operational and technology impacts.
4. 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 structured format.
5. Be aware of market developments and recommendations during the implementation phase, including those related to industry truncation risks.

• Clients can choose to send us MT or MX messages during the co-existence period established by Swift (now through Nov. 2025).
• J.P. Morgan sends MX (pacs) messages to clients and counterparties, including for serial third party (pacs.008/009) credit advice messages, even where we receive the incoming message in a legacy MT format. MX (pacs) messages provide for enhanced data transparency and formatting, and we are committed to delivering these benefits at the earliest opportunity.
  • As an exception, we will continue to provide the forced MT103/202 service to clients that use that service today in lieu of MT910. If you are not subscribed for this service, you will receive pacs.008/009 for serial third party credit advice messages.
  • Please be aware that after Transaction Manager (TM) enablement back on May 29, 2023 where a payment is MX originated even when J.P. Morgan sends a Forced MT103, this may be intercepted by TM and sent to the recipient as a multiformat message, pacs.008 with the Forced MT103 embedded.
• Connection to the Swift FINPlus platform will enable Swift's In-Flow Translation service, which will allow you to receive the MX message with embedded MT message, if you are not ready to receive native MX payment messages.
• Check with your compliance team to understand your obligations related to enhanced data received within the MX messages.

MT9xx remains the default reporting option sent by J.P. Morgan:

• J.P. Morgan will continue to send MT9xx as the default option (note: this does not apply for serial third party credit advices where we will send pacs.008/009).
• During H2 2024, you will be able to opt in to receive Cash Management messages (camt .052, .053 and .054) by contacting your J.P. Morgan representative; note that these messages will include information for transactions received via MX or MT messages.
• 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.

Providing enhanced information within MT9xx messages between now and Nov. 2025:

• Since the adoption of camt. messages is expected to take place gradually, 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 (excluding scenarios where we already customize this 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) while avoiding impact to existing reference and data mapping features.
  • Including "+" at the end of fields where possible, when data cannot be included due to insufficient space; this may apply to Related Reference, Party and Agent details and Sender to Receiver / Detailed Transaction Information fields within MT9xx series messages.
  • These features have been available for most EMEA account locations since 2023, with other account locations later in 2024.
• Clients using the forced MT103 service (including forced MT202 where provided) in lieu of receiving MT910, can migrate to camt.054. We recognize this requires time to implement, so we plan to use MT messages until the end of the co-existence period. To help clients receive helpful information during the interim period, we will attempt to map enhanced data from inbound pacs messages into these messages, leveraging CBPR+ prioritization and including "+" when data cannot be included due to insufficient space. Where a client uses the forced MT to satisfy other functions such as controls, sanctions, reconciliations and fraud because the forced MT contains relevant party information not currently available in the MT910 this will be replaced and satisfied by the camt.054 as the new ISO 20022 message is data rich and naturally contains all party information from the instruction being advised in addition to the amount and references.

J.P. Morgan will continue to accept Swift MT210 messages in account locations where those messages are accepted today. J.P. Morgan will accept camt.057 messages instead of MT210 messages in those account locations; however, note only single camt.057 messages will be accepted and not multiple advices within the same message.

For returned payments, where possible, we will 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.

Information on our camt. 052/3/4 message formatting is provided within our camt.(053) and camt. (054) schema, on our Swift MyStandards page.

Updates available for EMEA accounts MT9xx reporting:

• Where possible, J.P. Morgan will identify a return transaction, either through receipt of a pacs.004 or through receipt of an MT103/202 with /RETN/ code at the start of field 72.
  
• For both inbound (credit) and outbound (debit) transactions identified as returns, the following information will be included in the Sender to Receiver / Information for Account Owner fields, where available:
  • /RTN/ key word
  • End2EndID of Payment being returned (if not available, a space will be added)
  • Return Code and Code Name (where provided)
  • Returned Amount (e.g., “USD100,1” or “EUR100”,)
  • Originator Details
  • Original Instruction ID
  • Details will be delimited by a “/” and if any details are not available e.g., End2EndID or Originator Details, it will be indicated by a “ “ (space).
    
• J.P. Morgan will also attempt to provide the most relevant reference in field 21 of the MT900/910 and subfield 7 of the MT940:
  • For inbound (credit) return entries – we will aim to provide a client’s original Instruction ID (MX) or original Tag 20 (MT) reference from the original payment being returned
• For outbound (debit) return entries – we will aim to provide the Original Instruction ID provided by the client (if return message is sent as pacs.004) or a client’s Tag 20 (if return message is sent as MT).
  
  Example:
  
  72:/RTN/ /MS01 /USD999,/ / P333333333333 (sender’s Tag 20 Reference or equiv.)
  
  72:/RTN/ /BE02 /TEXT/BENEFICIARY CODE
  
  UNKNOWN/GBP8888,/ / 000001645022 (client’s original debit Tag 20 Reference or equiv.)
  
• We’ll confirm when these features are available for other locations. Where possible, we are also planning to enhance transparency of return payments within clients' billing invoices, where this doesn’t occur today (planned 2024).

Other details: J.P. Morgan is now sending pacs.004 for returning settled payments. Clients wishing to receive these messages in MT format can do so by using the Swift in-flow translation service.

Clients can use pacs.004 message to initiate return messages via J.P. Morgan although it is also acceptable to continue using MT with /RETN/ codewords, or even initiate the return as a new payment.

Please reference the ISO codes for returns messages, as per industry guidelines.

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 0.29 (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 in the future.

Please refer to the published market practice guidelines on use of enhanced ISO data elements. This guidance was expected to limit the use of enhanced ISO data elements until November 2023.

We're working hard to ensure the services driven by bilaterally agreed codewords for data patterns continue working seamlessly for clients moving to MX messages. If this applies to you and you would like more information, please refer to our Frequently Asked Questions. For more information on formatting bilaterally agreed codewords within the pacs.008 and 009 schemas, please refer to J.P. Morgan's Swift MyStandards schemas on Swift‍.‍com. If you require further clarification or need access to J.P. MyStandards, please contact your J.P. Morgan representative.

Transitioning existing RMAs to MX messages:

• RMAs allow the exchange of Swift messages over the Swift network
• To smooth the transition between FIN and FIN+, Swift "bootstrapped" (copy/pasted) all participants’ FIN RMAs into their equivalent ISO RMAs. Swift already performed a few sessions to bootstrap RMAs for different ISO 20022 standard releases in 2022 and 2023.
• Next bootstrap is planned for September  2024 just before November 2024 Standard Release, for current status please check Swift updates on Swift RMA Support Page
• The current MT9xx category of Swift FIN message types does not require an RMA, but the equivalent ISO camt message types does require an RMA. To lessen the operational impact, Swift provided an optional bootstrap event for camt.052/053/054 message types in 2022 and 2023. The next bootstrap before November 2024 Standard Release will also have optional bootstrap for camt messages, Opt-in Bootstrap Form is open until 31st July: RMA Opt-in bootstrap (in order to access the form you must have admission to Swift’s Ordering Module)

We strongly encourage our clients to opt-in - taking part in the bootstrap events, will save you time and the manual effort of bilateral RMA exchanges at the point of migration.

We know some clients are eager to test ISO 20022 messages. Here’s our recommendation:

• Check our testing guide, it aims to provide our clients with a useful reference point for their CBPR+ readiness, expanding on J.P. Morgan’s lessons learned as an industry leader in ISO 20022 adoption.
• Reference the Swift MyStandards schemas and the CBPR+ sample message library on Swift.com
• Access J.P. Morgan's Swift MyStandards schemas on Swift.com (currently available for pacs.008, pacs.009, and camt.054) 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.)
• Use Swift’s Sparring Partner tool, which may reduce the need for bilateral testing between Swift members. (For more information on this tool, please contact your Swift representative.)
• To check possibility of bi-lateral testing with us in a UAT environment and to get access to J.P Morgan readiness Portal on Swift MyStandard, please contact your J.P. Morgan representative.

J.P. Morgan is planning to support receipt of the CBPR+ pain.001 v9 bank-to-bank relay message from Q2 2025. We will continue to send relay messages in the existing MT format. We are also not expecting to receive these messages before Q2 2025 and any usage of the CBPR+ pain.001 v9 message would need to be agreed bilaterally.

J.P. Morgan will continue to initiate charge claims via MT191 until approximately Q1-2025.

As of November 2024. J.P. Morgan will be able to accept and process incoming camt.106

• CLS USD Nostro Services
  • CLS USD Nostro Service clients can continue to use MT202 messages with current formatting to instruct their CLS USD Nostro Pay-ins.
  • Alternatively, J.P. Morgan will accept 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.
  • If you want to use pacs.009, please contact your J.P. Morgan representative so we can coordinate accordingly.
  • Impacts to other payment and reporting message types are covered in the general sections of this website.
    
    
• CLS Third Party Service
  • Drawdowns used for the CLS Third Party Service will continue to be sent in MT format until further notice.
  • Impacts to other payment and reporting message types are covered in the general sections of this website.
    
    
• CLSNow
  • Clients can continue to use MT202 messages with current formatting to instruct CLSNow Pay-ins.
  • Alternatively, J.P. Morgan will accept payments via pacs.009; please use existing codewords in Instructions for Next Agent.
  • If you want to use pacs.009, please contact your J.P. Morgan representative so we can coordinate accordingly.
  • Impacts to other payment and reporting message types are covered in the general sections of this website.
    
    
• CLSCCP
  • Clients can continue to use MT202 messages with current formatting to instruct CLSCCP Pay-ins.
  • Alternatively, J.P. Morgan will accept payments via pacs.009; please use existing codewords in Instructions for Next Agent.
  • If you want to use pacs.009, please contact your J.P. Morgan representative so we can coordinate accordingly.
  • Impacts to other payment and reporting message types are covered in the general sections of this website.

• J.P. Morgan will liaise with each clearinghouse to discuss individual clearinghouse migration plans.
• Impacts to other payment and reporting message types are covered in the general sections of this website.

• J.P. Morgan will liaise directly with SwapAgent to discuss migration plans.
• Impacts to other payment and reporting message types are covered in the general sections of this website.

Adoption of the ISO 20022 (2019 publication) standard for high-value and cross-border and SEPA payment initiation is optional at this time and clients can continue using existing methods. However, we are preparing to support you if you decide to adopt ISO 20002 pain.001.001.09 via a Host-to-Host connection or SwiftNet FileAct. We expect to begin a pilot test in Q4 2024 with general availability in Q1 2025.

• Clients connecting to J.P. Morgan via Host-to-Host, FileAct, or EBICs can consider adopting the pain.001.001.09 standard (which will enable clients to pass end-to-end enhanced elements such as Ultimate parties and Structured Remittance) and adhering to J.P. Morgan's formatting guidelines.
• Starting in March 2024, clients will be able to initiate pain.001.001.09 (2019 standard) SEPA payments in a SEPA-only payment file.
• Starting in Q2 2025, clients will be able to initiate pain.001.001.09 (2019 standard) payments using Host to Host.
• Note that J.P. Morgan plans to align with the published industry guidance regarding enhanced data elements.
• Corporate CUG clients (Swift Standardized Corporate Environment -- SCORE) connecting to us via Swift: be aware plans to migrate MT101 messages to the ISO 20022 format have not yet been finalized by the industry.

To learn more about ISO 20022 payment initiation options, including account locations where this is available, please contact your J.P. Morgan representative.

ISO 20022 increases the limit of characters that can be presented in Payment Clearing and Settlement messages. Clients may see a "+" symbol at the end of a field when data from an incoming ISO message exceeds the size limit of the current reporting format.

J.P. Morgan will offer a new version of Host-to-Host ISO 20022 camt.05x.001.02 reporting format (Cash Management messages), which will support the increased character limits and additional ISO 20022 data elements present in a Payments Clearing and Settlement messages.

As a new industry message type will be available for returned payments, where possible, we will enhance transparency of return payments within clients' billing invoices, where this doesn’t occur today.

J.P. Morgan Access users can view and print MX-formatted outgoing payment instructions in the Broaden Search section. The MX-formatted payment instructions can be used as proof of payment.

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

During the co-existence period, from March 20, 2023 through November 2025, Swift Supervised Financial Institution and Swift Non-Supervised Entities started the migration 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.

During this co-existence period, J.P. Morgan accepts MT or MX payment messages from our clients whilst our outbound payment messages are in MX format (pacs.008/009), including serial third party credit advices (today set as MT103/202) even where we receive the incoming message in a legacy/MT format.

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) from Q4 2024, or until the co-existence period ends. We recommend our clients to start planning to adopt CAMT during 2024.

Managing truncation risks remains a key focus for the industry, where there is particular focus on the period between the CBPR+ go-live date of March 20, 2023 and the ramp-up in use of Swift’s Transaction Manager Platform from May 2023 to September 2023. A useful 15-minute introductory video on Transaction Manager can be watched on SwiftSmart (for registered users only).

As a reminder, please continue to refer to published industry guidance on implementing ISO 20022 for cross-border payments. This includes the following:

1. ISO 20022 Payments Migration and Interoperability Considerations for the global Community
   • Ultimate Debtor
   • Ultimate Creditor
   • Category Purpose
   • Structured remittance data
   • Related remittance info
   • Ultimate Debtor

Guidance was developed by the Swift Payments Market Practice Group (PMPG) in November 2022 for stakeholders impacted by the ISO 20022 CBPR+ implementation scheduled for March 2023.

This guidance complements the PMPG’s Best Practice Guidelines for the Payment Industry Migration to ISO20022 developed by the PMPG in January 2022 (launches download).

The PMPG’s industry guidance recommends avoiding origination of the following rich data elements for cross-border payments, until at least November 2023 (the “Target Date”):

• Ultimate Debtor
• Ultimate Creditor
• Category Purpose
• Structured remittance data
• Related remittance info

According to the guidance provided, only a few banks have upgraded their initiation channels to enable use of rich ISO 20022 data and those banks that have done so are encouraged to request that their clients refrain from populating these elements until sometime after the Target Date. Populating these data elements before the Target Date could trigger data being truncated or dropped and could result in payment delays or reconciliation issues for the creditor.

1. CBPR+ Data Integrity Market Practice Guidance

Where enhanced ISO 20022 data elements are introduced by a payment originator despite the above guidance, new market practice guidelines for banks have been developed by CBPR+ t


More information is available at: CBPR+ Data Integrity Market Practice Guidance (Swift user ID and Password required)

2. Truncation during Market Infrastructure transaction legs:

Collectively, the published industry guidance may also be applied to a transaction leg settled across a local Market Infrastructure (i.e., currency clearing systems) that has not yet adopted the ISO 20022 standard.

For example, the latest published market guidance now applies for transaction legs settled through the CHAPS Market Infrastructure prior to it adopting ISO 20022, complementing the previously agreed guidance for those payments. As a result, enhanced ISO elements should not be used for GBP cross-border payments until the Target Date.

We are providing enhanced information within MT9xx messages during the Mar. 2023 – Nov. 2025 co-existence period:

Given that the adoption of camt messages is expected to take place later, 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 will be available for most account locations from 2023.

Clients using the Forced MT103 service (including forced MT202 where provided) in lieu of receiving MT910, can migrate to camt.054. We recognize this will require time to implement, therefore we plan to retain this service (as MT message) until the end of the co-existence period. To help clients receive helpful information during the interim period, where possible, we will attempt to map enhanced data from inbound pacs messages into these messages, leveraging CBPR+ prioritization and including "+" when data cannot be included due to insufficient space. Please be aware after Transaction Manager (TM) enablement back in May 29, 2023 where a payment is MX originated even when J.P. Morgan send a Forced MT103 this may be intercepted by TM and sent to the recipient as a multiformat message, pacs.008 with the Forced MT103 embedded.

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 pacs.004 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 of this 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 Additional Information section at the bottom of our What’s New tab.)

Since CBPR+ go-live in March there is 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 visit J.P. Morgan Client Resource Center and view the J.P. Morgan adoption schedule of ISO 20022 messaging.

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. We are not expecting to receive CBPR+ pain.001 v9 bank to bank relay messages before Q2 2025 and any usage of these messages would need to be agreed bilaterally.

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

At this stage, J.P. Morgan has no timeline for adopting the CBPR+ pain.001 v9 bank to bank relay message on a send basis. We will continue to send relay messages in the existing MT format.

Yes, we have been ready since go-live date of March 20, 2023.

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

Please engage Swift to discuss the impact to your institution if remaining on MT. Financial institution and non-bank financial institution clients using Swift must be ready to receive incoming pacs.008 and pacs.009 (Core, COV and ADV) payment messages via FINPlus starting in March 2023, even if they plan to leverage MT messages for their core payment processing applications.

We are not expecting to receive CBPR+ pain.001 v9 bank to bank relay messages before Q2 2025 mid-2024 and any usage of these messages would need to be agreed bilaterally.

We are planning to gradually start sending pain.001 v9 bank to bank relay messages from Q2 2025. Sending of the pain.001 v9 bank to bank relay messages is to be confirmed.

For current status of message adoption please refer to our adoption schedule here.

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.

J.P. Morgan will continue to send enquiry and investigation MT1xx and MT2xx messages over Swift FIN until an appropriate MX message is agreed and implemented.

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.

From March 2023, we will gradually be able to accept ISO 20022 reporting messages (camt.052, camt.053,camt.054) reporting after bilateral agreement and after parallel run or sample testing with our counterparties.

In line with the co-existence period, J.P. Morgan will continue to send 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 in Q4 2024.

Yes. Please note we are planning to risk manage the introduction of sending camt messages:

• With availability for a small number of clients to participate in a pilot launch Q4 2024.
• With a broader launch for other early adopter clients after pilot in 2025.

We already have a camt.054 and camt.053 schema on our Swift MyStandards page, to clarify the key formatting features, particularly for elements that are subject to interpretation.

J.P. Morgan will continue to accept Swift MT210 messages in account locations where those messages are accepted today. From March 2023, J.P. Morgan will also accept camt.057 messages instead of MT210 messages in those account locations; however, note only single camt.057 messages will be accepted and not multiple advices within the same message.

Whilst the camt.058 - Notification to Receive Cancellation Advice, replacing the MT292 is being introduced by CBPR+ in the November 2023 release J.P Morgan will only start support from November2024. Until such time we ask that clients continue to send the MT292 when wanting to cancel an ATR / Notice to Receive ( MT210 / camt.057). We will continue to provide updates to confirm when support of the camt.058 will start.

Yes. Clients can choose the type of reporting they want. The default will continue to be MT9xx series until clients make the change to MX. Deadline for clients to switch to MX is November 2025. We are encouraging clients to start this switch in 2024 and not waiting until 2025.

The Swift “Cross-Border Payments and Reporting” (CBPR+) program runs from March 2023 through November 2025, 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. This may occur infrequently prior to November 2023 due to published market practice guidelines recommending that banks don’t enable the use of enhanced ISO data elements prior to November 2023.

Please note that J.P. Morgan is aligned with the published industry guidance and has not enabled enhanced data elements before November 2023.

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.

J.P. Morgan will support the pain.001.001.09 messages to align with CBPR+ and MI requirements. However, we plan to align with the published industry guidance. Clients can continue to send their existing file formats for the foreseeable future.

Yes. During the CBPR+ co-existence period (March 2023 – November 2025), J.P. Morgan will continue to accept SwiftNet FIN MT messages. We will work with our counterparties and Swift to ensure a successful transition to the ISO data model before the end of the co-existence period.

• 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 non-payment 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.

Only a member institution and Swift will know the type of membership (e.g. whether BIC (Bank Identification Code) is registered as a financial institution or as a corporate). Swift does not provide an indicator to counterparties on the type of membership assigned.

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.

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.)

• During co-existence it is possible a payment can go through multiple translations between MT and MX, MX and MT
  • The more free-format nature of certain party options in MT means that translation is not always clean.
  • Where unpublished BICs can be used in the free format options of MT without issue, this is no longer possible in MX so data elements other than BIC have to be used.
• J.P. Morgan will output MX to prevent the potential inconsistencies of translation and truncation

• To prevent the issues with processing translated MT messages we would encourage clients to adopt MX 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; 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 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. This could 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 pacs.008 and pacs.009. 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 MyStandard 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.

During the Swift co-existence period (from Mar. 2023 to Nov. 2025), some of our clients are leveraging Swift’s Inflow Translation service, which provides a multiformat message with the original MX sent by J.P. Morgan and an embedded MT (translated by Swift). Our clients will most likely be using Swift’s products, such as AMH or SAA, which have features to extract the embedded MT and can then pass that message on to a client’s back office payments systems.

As our clients being their journey to adopt native ISO 20022 messages, the multiformat message received in production can be a powerful asset for testing their readiness.

• What is a multiformat message? Put simply, it’s a file that starts with the MX message body, enclosed in <Document </Document>  tags, which represent the original MX payment. The translated MT is embedded at the end.

In this example we’ve removed the tags / elements from the message body.

MXBody : <Document xmlns="urn:iso:std:iso:20022:tech:xsd:pacs.008.001.08">
   <FIToFICstmrCdtTrf>
      <GrpHdr>
.
.
.
.
</Document><!-- {Translated MT starts here……etc}} --><!-- TranslationResult=TROK --><!-- TranslationInfo version 1.0.0.1 -->

• How can our clients leverage this? By “copying and pasting” the MX body into a new txt file our clients can create representative and production-like payments which can be used for injecting into their test environments (keeping in mind the need to update any required reference/static data to align with a client’s own test environment set up).

Used in conjunction with industry tools such as MyStandards and Swift Sparring Partner, this approach can support ISO 20022 readiness.

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
• Instruction For Next Agent – Instruction Information

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.

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.

Where an account provided in tag 53 of the MT (103 or 202) message is the account maintained at JPM, telling us which account we should settle the payment over. In MX (pacs.008 or pacs.009) this is now the Settlement Account.

                    <pacs:SttlmAcct>

                        <pacs:Id>

                            <pacs:Othr>

                                <pacs:Id>GB22XXXX88888888888888</pacs:Id>

                            </pacs:Othr>

                        </pacs:Id>

                    </pacs:SttlmAcct>

Source: Swift Translation Portal

Always refer to the Swift RMA Support Page for the most up-to-date information.

Currently RMA is only applicable to CBPR+ and the Swift FINplus (FIN+) service. Financial Market Infrastructure services, for example CHAPS, ESMIG, HK CHATS etc. are not utilizing RMA.

There are 5 main changes or events happening to the RMA service during the ISO 20022 coexistence period.

1. Bootstrap
2. RMA Consistency Check
3. RMA for all ISO message types (including the MT9 series equivalent)
4. Swift RMA Central Management Portal
5. Business Profiles

To prevent all institutions that will be receiving FIN+ message types needing to create FIN+ RMAs with their counterparties during the ISO 20022 migration period. Swift already performed two bootstraps in 2022/23 and planning more in 2025.

Bootstrap is the creation of FIN+ RMAs within the Swift Central RMA database, based on existing FIN RMAs. The Bootstrap process will ensure that the FIN+ authorizations will be “enriched” with the additional message types.

Please contact your Swift representative to find out more information on the Bootstrapping process and timeframes. Once the Bootstrap is completed, each participant should validate that both FIN and FIN+ RMA records are correct before importing the new RMA records into their local RMA database ahead of the March CBPR+ go-live.

• July 30 2022 Message Type mapping: 
  

• Sept 2023 Message Type mapping: 
  

• July 30th 2022 and Sep 2023 Optional Bootstrap Message Type mapping (see below for more detail):
  

Following the Bootstrap event in July 2022, Swift will enforce synchronicity between FIN and FIN+ RMAs for some message types.

Should a FIN RMA be issued with MT103 and/or MT202 permissions, the issuing institution must also issue a FIN+ RMA for the pacs equivalent message types (see table) within 15^* minutes.

If the FIN and FIN+ RMAs are not issued in the time limit, Swift will abort the RMA request back to the issuer.

^* 15 minutes is the current timing to be confirmed by Swift

For the current FIN service an RMA is not required for the MT9 series of message types.

In FIN+ the MT9 equivalent camt message types will require an RMA and are shown below.

To assist in the creation of FIN+ RMAs for these additional message types that require RMA, Swift is planning several optional Bootstrap events up to 2025 end (via requestable swift.com order form).

It is the responsibility of each Swift participant to analyze when and if to sign up for the optional bootstrap events.

As a result of the RMA Bootstrap and the implementation of the central Swift RMA database, Swift has created a new central Swift RMA Management Portal. This is currently available in Pilot mode and accessible utilizing the Swift WebPlatform product.

The new Portal will allow the easy management and exchange of RMAs across multiple Swift message channels (FIN, FIN+, API).

Institutions must migrate to the Portal before December 2023.

Once institutions move to the Portal, the concept of Business Profiles will be in effect (see below).

As Swift move towards multi-format messaging channels for FIN, FIN+ and API, there is a need to simplify the relationship management process.

RMA is the mechanism to record and enforce pre-agreed business message relationships between parties. To manage the business relationship, Swift alongside industry experts, have defined Business Profiles for each business family. This will replace the current RMA+ or RMA granularity functionality.

A Business Profile is a logical grouping of message types that support a given business family and is channel agnostic. When the RMA is exchanged using a Business Profile it will include all equivalent message types across FIN, FIN+ and API.

Please consult the Swift RMA Support Page for more detailed information regarding Business Profiles.

Yes, there is no change to this existing service. We will advise clients of any changes at the earliest opportunity.

Currently, there are no changes required to existing codes in use. We will advise clients of any updates at the earliest opportunity.

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, corporate clients sending payments via Access and/or Host-to-Host channels through the local Market Infrastructure/clearing can see the beneficiary name field extended to 140 characters from the current 70-character limitation. While there is no requirement to amend current payment formats, clients may need to use this new field if their beneficiary account name exceeds the current 70-character limit.

In Australia, corporate clients sending payments via Swift MT101/MT103 through the local Market Infrastructure/clearing can see the beneficiary name field extended to 140 characters from the current 70-character limitation. While there is no requirement to amend current payment formats, clients may need to use this new field if their beneficiary account name exceeds the current 70-character limit.

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.

Australia 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 do 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.

In Malaysia, corporate clients sending payments via Access and/or Host-to-Host channels through the local Market Infrastructure/clearing can see the beneficiary name field extended to 140 characters from the current 70-character limitation. While there is no requirement to amend current payment formats, you may need to use this new field if your beneficiary account name exceeds the current 70-character limit. We would also recommend avoiding use of special characters that are not part of the Swift FIN X character set when providing an End-to-End ID in your payment instruction.

Clients sending payments via Swift MT101/MT103 through the local Market Infrastructure/clearing can see the beneficiary name field extended to 140 characters from the current 70-character limitation. While there is no requirement to amend current payment formats, you may need to use this new field if your beneficiary account name exceeds the current 70-character limit.

In Singapore, the MEPS+ Phase 1 migration in August 2022 was focused on moving current payment details onto the ISO 20022 format in a Like-for-Like approach. There are no additional data requirements on top of the current MT messaging standards.  However, please avoid use of special characters that are not part of the Swift FIN X character set when providing an End-to-End ID in your payment instruction. As industry updates become available for SCRIPS Phase 2 migration, we will provide further information at the earliest opportunity.

In Thailand, corporate clients sending payments via Access and/or Host-to-Host channels through the local Market Infrastructure/clearing can see the beneficiary name field extended to 140 characters from the current 70-character limitation. While there is no requirement to amend current payment formats, you may need to use this new field if your beneficiary account name exceeds the current 70-character limit. We would also recommend avoiding use of special characters that are not part of the Swift FIN X character set when providing an End-to-End ID in your payment instruction.

Clients sending payments via Swift MT101/MT103 through the local Market Infrastructure/clearing can see the beneficiary name field extended to 140 characters from the current 70-character limitation. While there is no requirement to amend current payment formats, clients may need to use this new field if their beneficiary account name exceeds the current 70-character limit.

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.

Corporate clients sending payments via Access and/or Host-to-Host channels through the local Market Infrastructure/clearing can see the beneficiary name field extended to 140 characters from the current 70-character limitation. While there is no requirement to amend current payment formats, you may need to use this new field if your beneficiary account name exceeds the current 70-character limit. We would also recommend avoiding use of special characters that are not part of the Swift FIN X character set when providing an End-to-End ID in your payment instruction.

Clients sending payments via Swift MT101/MT103 through the local Market Infrastructure/clearing can see the beneficiary name field extended to 140 characters from the current 70-character limitation. While there is no requirement to amend current payment formats, you may need to use this new field if your beneficiary account name exceeds the current 70-character limit.

Canada AML regulator FINTRAC mandates name, account, and complete beneficiary address information, along with complete remitter details including address information where applicable in all wire payments. Per Payments Canada, the best practice is to utilize the structured address components where it will be mandatory to provide the information address in the fields for country, town name and street name in the structured address fields. No PO 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 delays in processing, and some may require that the beneficiary account number be prefixed by a transit code. Check your payees' standard settlement instruction to verify J.P. Morgan will reject wire payments with incomplete beneficiary information and missing remitter information where applicable.

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.