Format Frequently Asked Questions

ISO^® 20022 Format Questions

1. Will there be an ISO 20022 message to replace the service message (SVC 1090)?

   Most known use cases of the service message are replaced by the following ISO 20022 messages that have been included in the Fedwire^® Funds Service ISO 20022 message portfolio and should be used instead of service messages:

   • Return request and response — Fedwire Funds Service customers will be able to send a camt.056 to request the return of the amount of a previously settled payment order and can respond to such request with a camt.029 message to indicate if they will honor or refuse the return request.
   • Request a status of a previously sent payment or drawdown request — Fedwire Funds Service customers will be able to send a pacs.028 message to another Fedwire Funds Service customer to request a status of a previously sent drawdown request.

   For the remaining use cases, two ISO 20022 messages, i.e., Investigation Request (camt.110) and Investigation Response (camt.111) have been added to the Fedwire Funds Service ISO 20022 message portfolio to allow customers to deal with exceptions and investigations with wires sent over the Fedwire Funds Service.

2. Will the business function codes and type/subtype codes appear anywhere within the ISO 20022 messages?

   The Fedwire Funds Service business function codes and type/subtype codes used today will be eliminated, but the functionality provided by these features will be replaced with the combination of Local Instrument Codes and the type of ISO 20022 message sent. See the Appendix of the Fedwire Funds Service ISO 20022 Implementation Guide and the Local Instrument Codes section of the Fedwire Funds Service ISO 20022 Quick Reference Guide on the MyStandards^® website.

3. Will there be different cutoff times for the ISO 20022 messages?

   With the ISO 20022 implementation, the cutoff times for the Fedwire Funds Service will not change, but the way the cutoff times are triggered will change. Today, the cutoff times for the Fedwire Funds Service are controlled by the type code (i.e., 10, 15, 16) in tag {1510}. With the ISO 20022 implementation, the cutoff times will be based on the combination of specific Local Instrument Codes and the type of ISO 20022 message as noted in the Appendix of the Fedwire Funds Service ISO 20022 Implementation Guide on the MyStandards website. This topic was covered in more detail during the Customer Credit Transfers webinar on April 26, 2023.

4. Why is the Instruction For Next Agent data element not available in the pacs.008 and pacs.009 messages? Rather, there is only the Instruction For Creditor Agent data element. How will the sender to receiver information that appears in tag {6500} Sender to Receiver Information today be communicated?

   Use of the Instruction For Next Agent element will cause for non-straight through processing of payment instructions. The functionality previously supported by tag {6500} Sender to Receiver Information is now accommodated by enhanced ISO 20022 message capabilities (e.g., additional data elements are available to capture additional parties and agents involved in payments). No need for use of this element has been identified in ISO 20022-based systems, and the element is a candidate for removal from the standard at the global ISO 20022 level in November 2025. Use of the element is also not aligned with global best practices and the Committee on Payments and Market Infrastructures (CPMI) harmonized ISO 20022 data requirements for enhancing cross-border payments (Off-site) that will become effective by the end of 2027.

5. Where can I find more information on how to create US tax payments in ISO 20022 format?

   All US Treasury tax payments must be made using the customer credit transfer message (pacs.008). We have published guidance on how to format a customer credit transfer message for sending US Treasury Single Payer tax payments via the Fedwire Funds Service in the US Treasury Tax Payments Format Requirements section of the Fedwire Funds Service ISO 20022 Quick Reference Guide on the MyStandards website. The format will also align to the requirements that will be updated in the Electronic Federal Tax Payment System (EFTPS) Handbook.

6. Where can I find more information on IMADs/OMADs and other identifiers?

   We have published guidance on the usage of the Fedwire Funds Service Input Message Accountability Data (IMAD) and Output Message Accountability Data (OMAD) in the Business Application Header and Group Header of the underlying ISO 20022 business message in the IMAD/OMAD & Other Identifiers section of the Fedwire Funds Service ISO 20022 Quick Reference Guide on the MyStandards website.

7. We are unable to open/read/parse the ISO 20022 message sent by the Fedwire Funds Service. What happens when we send an admi.002 to the Fedwire Funds Service?

   If you are unable to open/read/parse any ISO 20022 messages sent by the Fedwire Funds Service, then you can send us (the Fedwire Funds Service) an admi.002 to indicate that you are unable to open the message. Please include “NOTAVAILABLE” in the Reference element of the Related Reference component and error code “T505” in the Rejecting Party Reason element. We will NOT send any responses back to you when you send us an admi.002. However, receipt of the admi.002 will alert us to initiate an investigation on our end.

8. When a Fedwire Sender sends a message to the Fedwire Funds Service, what value should be included in the “To” element of the Business Application Header?

   You should always include the Fedwire Funds Service routing number (i.e., 021151080) in element To/FIId/FinInstnId/ClrSysMmbId/MmbId of the business application header for all messages you send to the Fedwire Funds Service.

9. What is the difference between the “Copy Duplicate” and “Possible Duplicate” data elements in the business application header and when should these elements be used?

   ISO 20022 data element in business application header and Purpose & Use

   ISO 20022 data element in business application header	Purpose & Use
   Copy Duplicate	Must not be used by Fedwire Funds Service customers and can only be used by the Fedwire Funds Service. The Fedwire Funds Service will include this element with the value “DUPL” in the Fedwire Funds Service business application header when it responds to the following messages sent by a Fedwire Sender to indicate that the message is a copy of an original message: Retrieval request (admi.006) message sent by a Fedwire Sender to request a copy of a previously sent or received message. Payment status message (pacs.028) sent by a Fedwire Sender to request a copy of the status of previously sent value message. If the Fedwire Funds Service is in “contingency mode” (e.g., during a Saturday business resumption test or during an extreme contingency event in which the Fedwire Funds Service had to failover to its backup site – which has never happened), the Fedwire Funds Service would include the Copy Duplicate element with the value “DUPL” in the business application header it appends to the acknowledgement message it delivers to the Fedwire Sender and the advice of credit it delivers to the Fedwire Receiver.
   Possible Duplicate	Fedwire Senders should only include this data element with the value “true” in their business application header when they are not sure whether the message was already processed (i.e., when the Fedwire Sender has not received an acknowledgement for, or rejection of, a previously sent message). This could happen when the Fedwire Sender is having issues or if the Fedwire Funds Service is experiencing a disruption.

10. How does the Fedwire Funds Service handle messages that contain the “Possible Duplicate” element in the Fedwire Sender’s business application header?

    For any business application header that contains the value “true” in the Possible Duplicate element, the Fedwire Funds Service will check the IMAD of the business message to assess if it has been already processed:

    • If no message with that IMAD has already been processed, then the Fedwire Funds Service will process the message. Upon successful processing, the Fedwire Funds Service will not include the Possible Duplicate element in the business application header it appends to the acknowledgement message it delivers to the Fedwire Sender and the advice of credit message it delivers to the Fedwire Receiver.
    • If a message with that IMAD has already been processed (i.e., it is a duplicate IMAD), then the Fedwire Funds Service will reject the message.

    
     
11. Where can I find the original IMAD in an incoming admi.002 (technical/business error) message to help me determine which message was rejected?

    If the message you sent had a technical/business error, the Fedwire Funds Service will send an admi.002 message and provide an error code that begins with “T” along with the error description. In addition, the admi.002 message will include the IMAD of the original message in the Reference element of the Related Reference component so you can use this IMAD to reconcile to the message that was rejected by the Fedwire Funds Service.

    In a very rare instance, if the Fedwire Funds Service is unable to open/read/parse a message sent by the Fedwire Sender, then we will send an admi.002 with an error code of “T100” with the error description and include  “NOTAVAILABLE”  in the Reference element of the Related Reference component of the admi.002 message.  Should this rare event occur, you can submit a request for the Endpoint Details Sent Report to determine if any value or nonvalue messages have not been processed.

12. Is there a way to indicate that a payment is related to Fed Funds Sold (FFS) or Fed Funds Returned (FFR)?

    The business function codes FFS (Fed Funds Sold) and FFR (Fed Funds Returned) will not be available in ISO 20022 messages. However, you can identify a fed funds payment in a Financial Institution Credit Transfer (pacs.009) message by indicating the following in the Purpose/Proprietary data element:

    • Fed Funds Sold
    • Fed Funds Returned
13. What are the requirements for the UETR data element in value messages?
    The Unique End-to-End Transaction Reference (UETR) is a mandatory data element for value messages (pacs.008, pacs.009, pacs.004) to provide a universally unique identifier which can be used as an end-to-end reference of a payment transaction.  The Fedwire Funds Service checks the UETR for proper format but does not validate the uniqueness of it.  The format of the UETR is documented in the ISO 20022 usage guidelines for the value messages on the Fedwire Funds Service Release 2025 page on the MyStandards website. 
    
    Messages sent via the FedLine Direct® solution

    • The Fedwire Sender must include a UETR that conforms to the proper format.

    
    Messages sent via the FedPayments® Manager – Funds application via the FedLine Advantage® solution

    • For imported messages – the Fedwire Sender must include a UETR that conforms to the proper format.
    • For manually created messages – the FedPayments Manager – Funds application will generate the UETR when it submits the message to the Fedwire Funds Service for processing.
14. How do we handle receiving a Payment Status (pacs.002) message with a “PDNG” status?
    The Fedwire Funds Service will send a Payment Status (pacs.002) message with a PDNG (Pending) status when a value message (pacs.008, pacs.009, pacs.004) is in process or has been intercepted by the Federal Reserve Banks. The Fedwire Funds Service will send another pacs.002 message by the close of business with one of the following statuses to resolve the pending status:  

    • ACSC (Accepted Settlement Completed) for successfully processed value messages.
    • RJCT (Rejected) for rejected value messages.
15. If I receive an incoming Payment Return (pacs.004) message that I need to return (i.e., “return of a payment return”), how do I complete the reference identifications in my outgoing Payment Return (pacs.004) message?

    To map the references from the incoming Payment Return (pacs.004) message to the outgoing Payment Return (pacs.004) message, please follow the mapping provided in the table below:

    Incoming Payment Return (pacs.004)	Outgoing Payment Return  (pacs.004)
    Message Identification (mandatory)	Original Message Identification (mandatory) This should be the Message Identification of the incoming pacs.004 message.
    Original Instruction Identification (optional)	Original Instruction Identification (optional) This should be the Original Instruction Identification (if provided) of the incoming pacs.004, which is the Instruction Identification of the original value message (pacs.008 or pacs.009) that is being returned by the incoming pacs.004.
    Original UETR (mandatory)	Original UETR (mandatory) This should be the Original UETR of the incoming pacs.004, which is the UETR of the original value message (pacs.008 or pacs.009) that is being returned by the incoming pacs.004.
    Original End To End Identification (optional)	Original End To End Identification (optional) This should be the Original End To End Identification (if provided) of the incoming pacs.004, which is the End To End Identification of the original value message (pacs.008 or pacs.009) that is being returned by the incoming pacs.004.
    Original Transaction Identification (optional)	Original Transaction Identification (optional) This should be the Original Transaction Identification (if provided) of the incoming pacs.004, which is the Transaction Identification of the original value message (pacs.008 or pacs.009) that is being returned by the incoming pacs.004).

16. How do I complete the reference identifications in a Payment Return (pacs.004) message for a payment that was received in the legacy FAIM format?
    To send a Payment Return (pacs.004) message to return a value message sent to you in the legacy FAIM format, please follow the identification mapping provided in the table below:
    

    Original FAIM  value message	Payment Return (pacs.004)  to be sent in ISO 20022 format
    Tag {1520} Input Message Accountability Data (IMAD)	Original Message Identification (mandatory) This should be the IMAD of the original value message being returned.
    Tag {3320} Sender Reference  (if provided)	Original Instruction Identification (optional) This should be the Sender Reference (if provided) of the original value message being returned.
    Tag {3620} Payment Notification  (if UETR is provided)	Original UETR (mandatory) This should be the UETR (if provided) of the original value message being returned.  If the original payment did not include a UETR, then a new one should be assigned as this is a mandatory element in a pacs.004 message.
    Tag {4320} Reference for Beneficiary (if provided)	Tag {4320} Reference for Beneficiary (if provided)    Original End To End Identification (optional) This should be the Reference for Beneficiary (if provided) of the original value message being returned.
    Not available in FAIM format	Original Transaction Identification (optional) This can be left blank.

Postal Address Requirements

1. Where can I find more information on the postal address requirements?

   Refer to the Postal Address Format Requirements section of the Fedwire Funds Service ISO 20022 Quick Reference Guide on the MyStandards^® website.

2. Will Fedwire Funds Service support both structured and unstructured address information in ISO 20022 messages for agents and other parties in the message?

   With the ISO 20022 implementation on March 10, 2025, we will support both structured, unstructured, and a hybrid option for postal address information for agents and parties in ISO 20022 messages. However, in a future release after the March 10, 2025 implementation (timing to be determined), we will only support the hybrid option for postal address information. For additional details, see the response to question 3 below. Also, please refer to the Postal Address Format Requirements section of the Fedwire Funds Service ISO 20022 Quick Reference Guide on the MyStandards website.

3. Why are there two sets of postal address formatting requirements and when will the Fedwire Funds Service implement the “hybrid end-state” postal address requirements for all parties/agents in ISO 20022 messages? Will unstructured address information eventually be retired?

   There are two different sets of postal address formatting requirements as follows:

   • Interim — Supports cross-border interoperability as financial institutions migrate at different times to sending ISO 20022 messages via the SWIFT network. The interim format allows for the use of structured postal address information or unstructured but does not allow the combination of both structured and unstructured.
   • Hybrid/end-state — Focuses on use of structured postal address information, requiring at least the country code and town name, but also permits use of up to 2 lines of free-formatted address information (70 characters each). In a future release after the ISO 20022 implementation on March 10, 2025 (timing to be determined), the Fedwire Funds Service will require the hybrid/end-state postal address requirements for all parties and agents at which time you will no longer be able to use only unstructured address lines.

    

   For additional details, please refer to the Postal Address Format Requirements section of the Fedwire Funds Service ISO 20022 Quick Reference Guide on the MyStandards website.

4. Can we use both structured and unstructured addresses in the same ISO 20022 message?

   Yes. You need to apply the appropriate postal address requirement to every party/agent within an ISO 20022 message. For example, in a pacs.008 message, you can use the interim postal address format for all financial institutions and for the debtor and creditor, but you must use the hybrid/end-state format for the ultimate debtor and ultimate creditor. For additional details, please refer to the Postal Address Format Requirements section of the Fedwire Funds Service ISO 20022 Quick Reference Guide on the MyStandards website.

5. If we identify a party/agent with a BIC do we need to provide a name and address?

   No. You do not need to provide a name and address if you identify a party/agent in an ISO 20022 message with the international standard (ISO 9263) BIC (Business Identifier Code), which is used to uniquely identify businesses involved in financial transactions.

6. Today, we identify an originator and beneficiary with only an account number and identify an intermediary bank with only a clearing system member identification. Will ISO 20022 messages require us to include a name and address for these parties?

   With the Fedwire Funds Service ISO 20022 implementation you will no longer be able to identify an originator (debtor) or beneficiary (creditor) with only an account number or identify an intermediary bank (intermediary agent 1, 2, or 3) with only a clearing system member identification. The only time you can use an identifier alone to identify a party/agent in the message is when you use the international standard (ISO 9263) BIC (Business Identifier Code) to uniquely identify businesses involved in financial transactions. Otherwise, you will need to include the name and address in line with the postal address formatting requirement for the party/financial institution. For additional details, please refer to the Postal Address Format Requirements section of the Fedwire Funds Service ISO 20022 Quick Reference Guide on the MyStandards website.

7. What is the CPMI and where can we find the CPMI requirements for enhancing cross-border payments?

   The Bank for International Settlements’ Committee on Payments and Market Infrastructures (CPMI), in collaboration with the private sector Payment Market Practice Group (PMPG), developed the Harmonised ISO 20022 data requirements for enhancing cross-border payments (Off-site) which was published on October 17, 2023. The report documents the core set of ISO 20022 messages that support cross-border payments, along with general and minimum data requirements across that set (the ‘CPMI data model’) designed to improve how messages are processed throughout the end-to-end payments chain.

   With the ISO 20022 implementation on March 10, 2025, the Fedwire Funds Service will enable its participants to apply the CPMI data model described in the report.

8. The Fedwire Funds Service ISO 20022 postal address requirements for the Ultimate Debtor, Initiating Party, Ultimate Creditor, and Originator are different than the requirements included in the CBPR+ guidelines for these parties. How do we handle these differences?

   Given the timing of the Fedwire Funds Service ISO 20022 migration in March 2025, we have aligned the postal address requirements for the Ultimate Debtor, Initiating Party, Ultimate Creditor, and Originator to the “hybrid end-state” requirements that the Cross-Border Payments & Reporting Plus (CBPR+) Group will introduce in November 2025.  See the Postal Address Format Requirements section of the Fedwire Funds Service ISO 20022 Quick Reference Guide on the MyStandards website for more details.

   A subgroup of US representatives of the CBPR+ Group (i.e., US CBPR+ Mirror Group) is defining a market practice to cater for temporary interoperability issues that may occur between April 2024 (CHIPS ISO 20022 migration), March 2025 (Fedwire Funds Service ISO 20022 migration) and November 2025 when the CBPR+ ISO 20022 guidelines will include the “hybrid end-state” postal address option for these parties.  The market practice is published on the Fedwire Funds Service Release 2025 page on the MyStandards website.

Top of Page