Format Frequently Asked Questions

ISO^® 20022 Format Questions

1. Is there an ISO 20022 message to replace the old 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 should send a camt.056 to request the return of the amount of a previously settled payment order and should respond to such request with a camt.029 message to indicate if they will refuse the return request.
   • Request a status of a previously sent payment or drawdown request — Fedwire Funds Service customers can 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) can be used to deal with exceptions and investigations with wires sent over the Fedwire Funds Service.

2. What are the cutoff times for the different ISO 20022 messages?

   The cutoff times for ISO 20022 messages are based on the combination of specific Local Instrument Codes and the type of ISO 20022 message. Refer to the Operating Hours page for details.

3. 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 is the sender to receiver information communicated?

   Use of the Instruction For Next Agent element may cause 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 — see guidance table below). 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 ISO 20022 standard at the global 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.

   Guidance on how to accommodate tag {6500} FI to FI information in ISO 20022

   FAIM 3.0.7 tag {6500}	ISO 20022 data element
   Instructing FI "INS" information	Previous Instructing Agent 2, 3
   Intermediary FI "INT" information	Intermediary Agent 2, 3
   "For further credit to" information	pacs.008 only – Ultimate Creditor
   "On behalf of" information	pacs.008 only – Ultimate Debtor
   Use of pre-agreed processing conditions	Service Level

4. Where can I find more information on how to create U.S. Treasury tax payments in the ISO 20022 format?

   All U.S. 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 U.S. Treasury Single Payer tax payments via the Fedwire Funds Service in the U.S. Treasury Tax Payments Format Requirements section of the Fedwire Funds Service ISO 20022 Quick Reference Guide on the MyStandards website. The format also aligns with the requirements in the Electronic Federal Tax Payment System (EFTPS) Handbook (eftps.gov > Help & Information > Downloads).

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

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

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

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

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

10. 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) are not available in ISO 20022 messages. However, if you need to identify that a message is a Fed Funds payment, then you should include FFS or FFR in the Purpose/Proprietary element in a Financial Institution Credit Transfer (pacs.009) message.

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

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

    
     
13. We use the FedLine^® Direct solution. Are we allowed to skip IMAD sequence numbers or send them out of sequence?

    Yes, Fedwire Senders can send IMADs out of sequence or skip a sequence number. However, the Fedwire Funds Service application checks for duplicate IMADs and will reject a message if it contains a duplicate IMAD for the Fedwire Sender.

14. Can you explain how we should be using the Originator element in the return payment messages (i.e., camt.056, camt.029 and pacs.004) and in the drawdown response message (pain.014)?
    • In the camt.056 the Originator is the party who originated the request for the payment return
    • In the camt.029 the Originator is the party who originated the response to the payment return request
    • In the pain.014 the Originator is the party who originated the response to the drawdown request
    • In the pacs.004 the Originator is the party who agreed to return the payment

    
     
15. What is the mandatory End-to-End Identification used for?

    The End-to-End Identification, which is the equivalent of the optional tag {4320} Reference for Beneficiary in the current legacy format, is mandatory in the ISO 20022 format. This information is provided to help the beneficiary/creditor reconcile the payment. You can include "Not Provided" to meet the requirements if this is not provided by your customer.

16. We are required to include Charge Bearer in a customer credit transfer (pacs.008) message — what code should we use?
    • SHAR – This code is commonly used. If you are required to use Charge Bearer, we recommend you use this code unless one of the other codes applies. This code indicates that the wire processing charges will be shared, i.e., the originator/debtor will pay any fees associated with the wire payment of their financial institution (originator's bank/debtor agent) and the beneficiary/creditor will cover any fees of their financial institution (beneficiary's bank/creditor agent).
    • CRED – This code indicates that all fees associated with the wire payment will be paid by the beneficiary/creditor. This means that all financial institutions in the payment chain may deduct fees, thereby reducing the payment amount to the beneficiary/creditor. If financial institutions do so, then any fees deducted from the wire amount must be documented in the Charges Information (amount and agent).
    • DEBT – This code indicates that the originator/debtor is responsible to cover all fees associated with the wire payment, including fees that may be due to any intermediaries and the beneficiary's bank/creditor agent. 
    • SLEV – This code indicates that charges are to be processed in line with a (bilateral) service level agreement between the sending bank and the receiving bank.

    
     
17. Why is account information optional for parties and agents in payment messages and what element is the correct place to add the account information?

    Account information is optional, but you are encouraged to include account information to help facilitate straight through processing. You should include the account information in the corresponding party/agent element, e.g., the account of the Debtor (originator) in the Debtor Account element using either the Identification/Other option for domestic account numbers (e.g., DDA numbers) or the Identification/IBAN option when you have an International Bank Account Number (IBAN) account number.

18. How do we use the Intermediary Agent?

    There is some misuse today in the current FAIM format as customers duplicate the Receiver FI as the Intermediary FI. The Intermediary Agent should only be used to identify a financial institution different from the Instructed Agent and from the Creditor Agent that is truly playing an intermediary role in the payment chain to allow the Instructed Agent (Fedwire Receiver) to reach the Creditor Agent. For example, you would include an Intermediary Agent for an international payment if there was a third financial institution between the Instructed Agent and the Creditor Agent.

19. How do we send payment orders to a Bankers' Bank/Corporate Credit Union?
    Please follow the instructions provided below to send a payment order to a Bankers' Bank/Corporate Credit Union. Please note that you should not repeat the Bankers' Bank/Corporate Credit Union information in the Intermediary Agent section.
     

    	Instructed Agent	Creditor Agent	Creditor	Creditor Account (Other/Identification)
    Financial Institution Credit Transfer (pacs.009)	Bankers' Bank/Corporate Credit Union	[Cell intentionally left blank]	Institution that holds an account with the Bankers' Bank/Corporate Credit Union	Account information
    Customer Credit Transfer (pacs.008)	Bankers' Bank/Corporate Credit Union	Institution that holds an account with the Bankers' Bank/Corporate Credit Union	Customer of the institution	Customer account information

20. Should we be using the Carriage Return Line Feed (CRLF) in free-formatted text elements in our messages?

    Federal Reserve Financial Services (FRFS) recommends that Fedwire Funds Service participants do not use the CRLF in free-formatted text elements in their messages to avoid delays in the successful processing of their transactions. While the CRLF character (hard return key) is part of the Fedwire Funds Service ISO 20022 permissible character set (i.e., will not cause a rejection by the Fedwire Funds Service application), its use by Fedwire senders in free-formatted text elements (e.g., when including payment remittance information) is causing issues for Fedwire receivers’ downstream systems and applications.

21. Can we use only spaces in free-formatted text elements in our messages?

    FRFS recommends that Fedwire senders do not include spaces in free-formatted text elements in their messages to avoid delays in the successful processing of their transactions. Use of only spaces in free-formatted text elements (e.g., unstructured remittance information) is causing issues for Fedwire receivers’ downstream systems and applications.

22. Are we required to uppercase the external codes?

    While the Fedwire Funds Service does not validate the external codes, we recommend that you uppercase the external codes as this may become a requirement later. Today, the Fedwire Funds Service only checks for up to four alphanumeric characters. Please refer to the  External code sets (Off-site)  web page for the latest list.

Postal Address Questions

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. 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 two lines of free-formatted address information (70 characters each). As of Nov 16, 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.

3. Can we use both structured and unstructured addresses for different agents and parties 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.

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

   No. Our format specifications do not require you 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.

5. Can we identify an originator and beneficiary with only an account number and identify an intermediary bank with only a clearing system member identification?

   No. The only time you can use an identifier alone under our format specifications is 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.

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

   The implementation of ISO 20022 on July 14, 2025, enabled Fedwire Funds Service participants to apply the CPMI data model described in the report.

7. 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 that occurred in July 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 U.S. 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), July 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.

8. Can you explain the ISO 20022 postal address terminology?

   ISO 20022 Postal Address Elements	U.S. Postal Address Equivalents
   Department	Department
   Sub-Department	Sub-Department
   Street Name	Street Name
   Building Number	Street Number
   Building Name	Name given to a particular building
   Floor	Floor
   Room	Suite number or apartment number
   Post Box	P.O. Box
   Post Code	Zip Code
   Town Name	City
   Town Location Name	For U.S., this could be used to identify a county
   District Name	Type of administrative division that in some countries is managed by the local government
   Country Sub Division	State
   Country	Country

9. Can you clarify if the creditor's postal address is required in a customer credit transfer (pacs.008) or drawdown request (pain.013) message?

   While the Fedwire Funds Service's message format specifications do not require the creditor's postal address in a pacs.008 and pain.013 message, you should consult your compliance and legal departments on what information (e.g., creditor's postal address) you may need to include in messages to satisfy your compliance obligations. A Fedwire sender should also check with the Fedwire receiver and any other bank that may process the transfer to understand additional requirements that they may have to ensure straight-through processing (e.g., creditor's postal address in addition to the creditor's name).

Payment Return Messages Questions

1. 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. For additional details, please refer to the Use of ISO 20022 messages related to payments received in the FAIM format section of the Fedwire Funds Service ISO 20022 Quick Reference Guide on the MyStandards website.

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

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

3. Why is the Underlying Customer Credit Transfer component under the Original Transaction Reference not available in a pacs.004?

   The Underlying Customer Credit Transfer component under the Original Transaction Reference component in a pacs.004 is not available for use in a pacs.004 sent across the Fedwire Funds Service. This implementation is aligned with the global best practice defined by the HVPS+ group. The Return Chain in a pacs.004 must identify all parties/FIs involved in the pacs.004 return payment; these parties/FIs should be identified by their role in the pacs.004 and not by their role, if any, in the original pacs.008 or pacs.009 message.

4. What is the restriction for making a return request and payment return (e.g., one week, one month, one year)?

   The Fedwire Funds Service does not impose restrictions on the date that a return request or payment return message may be sent.

5. What is the correct ISO 20022 message to return funds of a previously settled value message?

   The correct ISO 20022 message to return funds of a previously settled value message (e.g., customer credit transfer (pacs.008) or financial institution credit transfer (pacs.009) message) is the ISO 20022 payment return (pacs.004) message. If a Fedwire Funds Service participant is not capable of sending a pacs.004 message and decides to send a new customer credit transfer (pacs.008) or financial institution credit transfer (pacs.009) message to return a previously settled value message, then any payment return-related information should be populated in the unstructured remittance information element of the message. A Fedwire receiver may decide to reject a pacs.008 or pacs.009 message that is used to return a previously settled value message due to the Fedwire sender’s use of the incorrect message type.

6. We use the FedLine Direct Solution. Why are we receiving a camt.029 (return request response) as a reject message from the Fedwire Funds Service? Does this mean our outgoing return request response (camt.029) messages were not delivered to the Fedwire receiver?

   If you receive a camt.029 message after you have sent a return request (camt.056), this means your message was not delivered to the Fedwire receiver due to business errors. The Fedwire Funds Service uses the camt.029 messages for negative acknowledgement back to the Fedwire senders as indicated below:

   • If a Fedwire sender sends a return request (camt.056) successfully, the Fedwire sender will receive a positive acknowledgement with an admi.007 (positive response to a nonvalue message) and that indicates the message was delivered to the Fedwire sender.

   
   

   If there were business errors with the camt.056 message, the Fedwire sender will receive a negative acknowledgement in a camt.029 message that includes all the business errors.

7. What is the correct ISO 20022 message to request return of funds of a previously settled value message?

   The correct ISO 20022 message to request return of funds of a previously settled value message (e.g., customer credit transfer (pacs.008) or financial institution credit transfer (pacs.009) message) is the ISO 20022 return request (camt.056) message. Fedwire Funds Service participants must not send the information request (camt.110) message, which replaces the FAIM service message (type 90), to request return of funds. Use of the investigation request (camt.110) message to request return of funds may cause a rejection by a Fedwire receiver of the request due to the Fedwire sender’s use of an incorrect message type, thereby further delaying the possible return of funds.

Investigation Messages Questions

1. Is there an ISO 20022 message to replace the old 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 should send a camt.056 to request the return of the amount of a previously settled payment order and should respond to such request with a camt.029 message if they refuse the return request.
   • Request a status of a previously sent payment or drawdown request — Fedwire Funds Service customers can 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), can be used to deal with exceptions and investigations with wires sent over the Fedwire Funds Service.

2. Can I send multiple investigation response (camt.111) messages for one incoming investigation request (camt.110) message?

   Yes, you may want to send an initial camt.111 message to inform the sender of the camt.110 that you have received the inquiry and are looking into the matter, then follow up with another camt.111 message with the appropriate response to close the inquiry.

3. Can I send multiple investigation request (camt.110) messages to inquire about the same payment message?

   Yes, you can send multiple camt.110 messages to ask a series of questions about a particular payment message. Another use case is where you have sent a camt.110 and receive a camt.111 that does not fully address your question. You can send another camt.110 message with a follow up question related to the same payment message.

Ultimate Creditor and Ultimate Debtor Questions

1. Could you provide information on how we should use the Ultimate Creditor and Ultimate Debtor elements?
   • Ultimate Debtor: This should be used to include "payment on behalf of'" information that is currently provided in a free-formatted field. For example, Company A in Seattle is the main treasury hub and makes all payments on behalf of all other Company A's branches. Company A in Seattle would be identified as the Debtor when it makes the payment on behalf of Company A's New York branch for its invoice. Company A's New York branch would be identified as the Ultimate Debtor.
   • Ultimate Creditor: This should be used to include "for further credit to" information (i.e., when the Creditor is not the ultimate beneficiary) that is currently provided in a free-formatted field. For example, Jane Smith receives a scholarship fund, which will be credited to the account of Jane's father, John Smith, held with the Creditor Agent. John Smith would be identified as the Creditor and Jane Smith would be identified in the Ultimate Creditor.

   
    
2. If our institution includes information in the Ultimate Creditor element of a payment message, how do we know that the Creditor Agent will review that information, and what action can we expect them to take?
   • The information in these elements replaces today's free-formatted "for further credit to" or "payment on behalf of" information that should be passed on just like today with the free-formatted information (i.e., pass on the information to the Creditor so they know who has actually paid them, or who is the ultimate beneficiary of the funds that are credited to their account).

   
    
3. How should we handle information in the Ultimate Creditor and Ultimate Debtor elements?
   • If you receive a payment message with information in the Ultimate Creditor or Ultimate Debtor elements, you should include that information in the payment message you send to the next agent or, if you are the Creditor Agent, in the notice you send to the Creditor.

   
    
4. Where do I include the account for Ultimate Creditor?

   Account field is not available in the Ultimate Creditor section as the Ultimate Creditor receives the funds on the account of the Creditor. If you need to include an account number for the Ultimate Creditor:

   • For a company, select Organization and include the information in the Other Identification field and select "BANK" in the Scheme Name Code.
   • For a person, select Private and include the information in the Other Identification field and select "CUST" in the Scheme Name Code.

   
    

Drawdown Messages

1. How should we correctly format drawdown requests and drawdown transfer messages?

   When honoring a bank or customer drawdown request (pain.013), a Fedwire sender needs to make sure the corresponding customer drawdown transfer (pacs.008) or bank drawdown transfer (pacs.009) message is correctly formatted by maintaining the roles of customers and financial institutions identified in the drawdown request. In practice, this means that the Debtor, Debtor Agent, Creditor and Creditor Agent reflected in the drawdown request message must remain as the Debtor, Debtor Agent, Creditor and Creditor Agent, respectively, in the drawdown transfer message.

2. How should we use the drawdown request response (pain.014) message?

   There are a number of uses of drawdown request response (pain.014) messages:

   • When you do not plan to honor an incoming drawdown request (pain.013) message, you should send a pain.014 message with status “RJCT” (Rejected) as Transaction Status.
   • When you need more time to determine whether or not you will honor an incoming drawdown request (pain.013) message, you may send a pain.014 message with status “PDNG” (Pending) as Transaction Status. Afterwards you should follow up with another pain.014 message to communicate the final response, i.e., either reject or accept the drawdown request.
   • When you plan to honor the incoming drawdown request (pain.013) message, you may respond by sending a pain.014 message with status “ACTC” (Accepted) as Transaction Status. However, you may simply send the drawdown transfer message (pacs.008 or pacs.009).

   
   
3. We use the FedLine Direct Solution. Why are we receiving a pain.014 (drawdown request response) as a reject message from the Fedwire Funds Service? Does this mean our outgoing drawdown request (pain.013) message was not delivered to the Fedwire receiver?

   If you receive a pain.014 message after you have sent a drawdown request (pain.013), this means your message was not delivered to the Fedwire receiver due to business errors. The Fedwire Funds Service uses the pain.014 message for negative acknowledgement back to the Fedwire senders as indicated below:

   • If a Fedwire sender sends a drawdown request (pain.013) successfully, the Fedwire sender will receive a positive acknowledgement with an admi.007 (positive response to a nonvalue message) and that indicates the message was delivered to the Fedwire sender.

   
   

   If there were business errors with the pain.013 message, the Fedwire sender will receive a negative acknowledgement in a pain.014 message that includes all the business errors.

4. We are receiving a "T134" error when sending a customer drawdown payment in response to an incoming drawdown request (pain.013) with a Charge Bearer code of CRED. What should we do?

   The T134 error is triggered if a Fedwire sender fails to include an amount in the Charges Information field when responding to a drawdown request (pain.013) that included a Charge Bearer code of CRED. Under the format specification, CRED indicates that all fees associated with the transfer will be paid by the beneficiary/creditor.

   • If the sender of the drawdown request is not instructing the sender of the drawdown payment (and any other receiving bank that handles the transfer) to charge against the principal amount of the transfer, it should instead consider using Charge Bearer code of SHAR, which does not require the Charges Information field to be completed.
   • If the sender of the drawdown payment receives a drawdown request with a Charge Bearer code of CRED and does not intend to charge against the principal amount of the wire, it should include $0.00 in the Charges Information field.

   
   

   Note that any receiving bank that charges against the principal amount of a transfer through the service must obtain authorization to do so consistent with applicable law.

Additional Questions

1. Are there plans to update the E-Payments Routing Directory to include additional information (e.g., full address)?

   There are currently no plans to change the format of the E-Payments Routing Directory file or add additional data elements in the future.

2. What is a BIC?

   A Bank Identifier Code (BIC) is a unique code that is used to identify financial institutions globally. A BIC makes it easier to identify institutions involved in financial messaging, e.g., in ISO 20022 messages.

   While often associated with the Swift^® financial messaging network, a financial institution does not have to be a Swift participant to obtain a BIC. You can visit this page to learn more about signing up for a non-connected BIC (Off-site).

Top of Page