IMAD vs OMAD is input versus output: the IMAD, Fedwire's Input Message Accountability Data, identifies a message as the sending bank put it into the Fedwire Funds Service, and the OMAD, the Output Message Accountability Data, identifies the same message as Fedwire delivered it to the receiving bank. Together they pin down one Fedwire leg of a wire. The UETR, the Unique End-to-End Transaction Reference, is different: it is meant to follow the whole payment through every bank, and since July 2025 it is mandatory on Fedwire value messages too. Customers mix these up, and so do staff, which is why wire inquiries stall on the wrong number. Botminds' Wire Inquiry & Payment Tracking reads all of them from the bank's own systems and joins them into one route, so the officer does not have to ask the customer for any.
The definitions below come from the Federal Reserve's own documents, quoted and linked. The example references belong to a fictional sample wire in the solution.
IMAD vs OMAD: one Fedwire message, two accountability numbers
IMAD (Input Message Accountability Data): The message as the Fedwire sender put it in.
OMAD (Output Message Accountability Data): The message as the Fedwire Funds Service delivered it to the receiver.
IMAD (Input Message Accountability Data): The sender's Fedwire connection; senders on FedLine Direct may skip or reorder sequence numbers, but not repeat one.
OMAD (Output Message Accountability Data): Fedwire, on the way out.
IMAD (Input Message Accountability Data): Checks it for duplicates: a repeated IMAD from the same sender is rejected.
OMAD (Output Message Accountability Data): Delivers it with the message the receiving bank gets.
IMAD (Input Message Accountability Data): The sending bank, when a receiver or correspondent says it cannot find the payment.
OMAD (Output Message Accountability Data): The receiving bank, when it confirms what it received.
IMAD (Input Message Accountability Data): That this particular message was submitted, and is the reference on a reject or a return.
OMAD (Output Message Accountability Data): That Fedwire delivered this particular message to the receiving bank.
What is an IMAD?
An IMAD is the Input Message Accountability Data on a Fedwire message: the identifier that marks one message as submitted by one sender. Fedwire relies on it to stop the same payment going twice. When a sender is unsure whether a message went through and marks a resend as a possible duplicate, "the Fedwire Funds Service will check the IMAD of the business message to assess if it has been already processed", and "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" (Format FAQs, question 8).
The IMAD is also how a bank finds its own rejected message. A rejected message comes back as an admi.002 that carries the IMAD of the original in its related reference, so the bank can match the reject to what it sent (question 9; Fedwire reject reason codes quotes the answer). The IMAD carries the Fedwire cycle date too: the Fed's FedTransaction Analyzer pages note a known "cycle date duplication in the IMAD field for the period of July 14 through Aug. 15, 2025", the first weeks after the move to ISO 20022 (FedTransaction Analyzer FAQs).
What is an OMAD?
An OMAD is the Output Message Accountability Data: the identifier on the message as Fedwire delivered it to the receiving bank. It is the receiving bank's reference for what it got, which is why a beneficiary's bank asked "did you receive it?" answers best with the OMAD. Under Operating Circular 6, when a payment order settles, the receiving bank gets an Advice of Credit, a message that "advises the Funds Participant of a credit to its Master Account" (OC 6, sections 2.5 and 8.2.6).
The 'imad' and 'omad' numbers at the bottom of the message are added by the Fed and identify the date, time, and receiving and sending terminal.
Federal Reserve, Bank Secrecy Act Manual, September 1997, describing a sample Fedwire message
That description is from the legacy message format of 1997, when the two numbers sat at the foot of a printed message. Today they sit in the business application header and group header of an ISO 20022 message, and senders on FedLine Direct number their own IMADs; the idea is unchanged. One number is stamped on the way in, one on the way out, and between them they make a Fedwire leg accountable.
What is a Fed reference number?
"Fed reference number" is the customer's phrase, not one of the Fed's field names. The Fed's own format questions name the IMAD, the OMAD, the UETR, the Sender Reference and the End-to-End Identification. When a customer, a title company or a supplier asks for the Fed reference number, they want proof that a wire went through Fedwire and a number the other side's bank can look up: for the sending side that is the IMAD, for the receiving side the OMAD, and for anyone tracing beyond the first bank the UETR.
The numbers on a wire: who assigns each, what it proves, and who needs it
| Number | Assigned by | Follows the payment through | What it proves | Give it to |
|---|---|---|---|---|
| IMAD | The sender's Fedwire connection | One Fedwire leg | This message was submitted to Fedwire | The receiving bank or correspondent that cannot find it |
| OMAD | Fedwire, on delivery | One Fedwire leg | Fedwire delivered this message to the receiver | The sending bank, as confirmation of receipt |
| UETR | The bank or software that creates the payment | Every bank in the chain that carries it | Nothing by itself: it is the key other banks look the payment up by | Any bank on the route, and the customer for its records |
| End-to-End Identification | The originating customer, through its bank | The whole chain, to the beneficiary | Which invoice or obligation the payment is for | The beneficiary, to reconcile |
| Sender Reference | The sending bank | The sending bank's own records | Which payment in the bank's own system | The bank's own staff |
| Bank wire number and correspondent case | Each bank's own systems | One bank only | Where that bank filed it | Staff at that bank |
Is the UETR the same as the IMAD?
No. The IMAD belongs to one Fedwire message; the UETR belongs to the payment and is meant to travel with it through every bank. The Fed's format rules make the UETR "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", and add that "The Fedwire Funds Service checks the UETR for proper format but does not validate the uniqueness of it" (Format FAQs, question 11). Fedwire guarantees the IMAD is not repeated by a sender; it does not guarantee the UETR is unique.
The CPMI explains why that is workable. The UETR follows "the technical standard RFC 4122 (version 4)", and "no centralised authority is required to administer the creation of unique identifications, but instead the generation of UETRs can be accomplished through the decentralised use of an algorithm" (BIS CPMI, Harmonised ISO 20022 data requirements, 2026). Uniqueness comes from the arithmetic of random identifiers, not from a registry. What a UETR can and cannot tell you follows it beyond Fedwire.
The customer's own numbers: End-to-End Identification and Sender Reference
Two more references matter to customers and are often confused with the Fed's. The End-to-End Identification is the customer's own reference for the payment, such as an invoice number. The Fed says it "is the equivalent of the optional tag 4320 Reference for Beneficiary in the current legacy format, is mandatory in the ISO 20022 format", and is "provided to help the beneficiary/creditor reconcile the payment"; a bank may enter "Not Provided" if the customer gave none (Format FAQs, question 15).
The Sender Reference is the sending bank's own number, legacy tag 3320. Neither is a Fedwire accountability number, and neither will help another bank find the payment as fast as the IMAD or the UETR. They are what a beneficiary uses to know what it was paid for.
Which number proves a wire was sent?
The Fedwire records do, for the Fedwire leg: "The Reserve Banks' records are conclusive as to the timing of acceptance and payment of a payment order" (OC 6, section 8.2.7). In practice a bank shows that with the IMAD and OMAD and the final status: a pacs.002 with ACSC, "Accepted Settlement Completed", which Fedwire sends after any PDNG status "by the close of business" (Format FAQs, question 12).
Two cautions keep that proof honest. It proves the Fedwire leg, not the credit to the beneficiary: on a cross-border wire the Fedwire leg ends at a correspondent that still has to send the payment on. And a screenshot of online banking proves only that the customer asked; a "sent" status there may mean released by the bank, not settled by the Reserve Banks.
Every reference on one wire, side by side, in Wire Inquiry & Payment Tracking
One sample wire in Wire Inquiry & Payment Tracking, and where each number was born
| When | Event | Number | Example on the sample wire |
|---|---|---|---|
| Wed 2:48 p.m. | Customer submits the wire in business online banking | Bank wire number | TCB-W-261021-0388 |
| Wed 3:04 p.m. | The bank releases it to Fedwire | IMAD, and the UETR the payment will carry end to end | 20261021TSLYCB1Q000388 · 3b7e1c04-9a2f-4d68-8e51-c27a90f4d6b2 |
| Wed 3:06 p.m. | Fedwire settles it with the correspondent and delivers the message | OMAD | 20261021VLMRNY3R004127 |
| Wed 4:31 p.m. | The correspondent converts and sends it on | The same UETR, now on the cross-border leg | 3b7e1c04…d6b2 |
| Thu 1:05 p.m. | The correspondent forwards an intermediary's request for information | Correspondent case number | VB-RFI-88213 |
Duplicates, retries and why the IMAD matters to the wire room
The IMAD is the wire room's protection against paying twice. A sender should mark a message as a possible duplicate only "when the Fedwire Sender has not received an acknowledgement for, or rejection of, a previously sent message", and Fedwire then processes it only if that IMAD has not been seen. The Fed also uses a Copy Duplicate marker, "DUPL", on copies it sends in response to an admi.006 retrieval request or a pacs.028 status request, so a copy is never mistaken for a second payment (Format FAQs, question 7).
For an inquiry desk the lesson is practical. When a customer says "the beneficiary never got it" and the bank's own screen shows no acknowledgment, the answer is not to send it again but to find out, by IMAD, whether Fedwire processed the first message. Operating Circular 6 says a participant that "does not receive an Acknowledgment or Rejection" should "notify the Appropriate Reserve Bank Staff promptly" (OC 6, section 8.6.1).
Which number to ask for, depending on who is asking
- Your customer says the beneficiary has not been paid
Give the receiving bank the IMAD and the UETR; ask it for the OMAD it received, or a statement that it has no message.
- A beneficiary asks whether money has arrived
Look up incoming messages by amount and sender; quote the OMAD of the message you received.
- A correspondent asks about a payment you sent
The UETR first: it is the reference its tracker and case system use.
- A title company or supplier wants proof
The IMAD with the time the payment settled; on a domestic wire the receiving bank's confirmation completes it.
- A returned payment arrives
Match it by the original IMAD and the original UETR, which a pacs.004 must carry.
A last point on returns. When a bank returns a payment that arrived in the legacy format, the Fed maps the old IMAD, tag {1520}, to the return's original message identification, and if the original payment had no UETR "then a new one should be assigned as this is a mandatory element in a pacs.004 message". Every number on this page can come back on a return. How a full trace uses them is set out step by step, and Wire Inquiry & Payment Tracking shows them joined on one wire.
Questions people ask
Can I track a wire with an IMAD?
Your bank can, on the Fedwire leg: the IMAD identifies the message it sent and lets the receiving bank find what arrived. You cannot look it up yourself, and it says nothing about banks beyond the first receiver; for those, the UETR is the reference.
Who assigns the UETR?
Whoever creates the payment message. On Fedwire, a bank sending through FedLine Direct must include a correctly formatted UETR, and for messages created by hand in the FedPayments Manager application, the application generates it. The CPMI expects the same UETR to be carried unchanged through the chain.
Can two wires have the same UETR?
They should not: the CPMI relies on the RFC 4122 algorithm, not a registry, to make each one unique. But Fedwire does not check; it "checks the UETR for proper format but does not validate the uniqueness of it". A tracking system should therefore join on the UETR together with the amount, the date and the IMAD, not on the UETR alone.
What does PDNG mean on a wire?
Pending. Fedwire sends a pacs.002 with PDNG while a value message is still being processed or has been stopped by the Reserve Banks, and follows it by the close of business with ACSC, accepted and settled, or RJCT, rejected. A PDNG does not say why.
Where does the IMAD appear on a returned wire?
In the return itself. For a payment received in the legacy format, the original IMAD (tag 1520) maps to the return's original message identification, and the original UETR is mandatory on the pacs.004; the Fed publishes the mapping in its format FAQs.
How late can a bank ask Fedwire for a copy or a status?
Until 7:15 p.m. ET on a funds-transfer business day, for a pacs.028 status request on a value message already sent or an admi.006 retrieval request, after the 7:00 p.m. close for payments (Fedwire operating hours).