Fed wire reject reason codes: what each error family asks you to fix

Fed wire reject reason codes are the error codes the Fedwire Funds Service sends back when it will not process a message. Since Fedwire moved to ISO 20022 on 14 July 2025 they come in two families: technical errors, with codes beginning "T", for messages that break the XML schema or Fedwire's usage rules, delivered one at a time in an admi.002; and business errors, with codes beginning "E", "F", "H" or "I", for messages that fail Fedwire's business edits, delivered for a payment as a pacs.002 status report listing every error. A reject means the payment never settled, which makes it a repair, not a return. Botminds' Payment Repair is an agentic solution for that repair queue: its agents read the reject, name the cause and propose a fix with its evidence for a person to approve, ahead of the 6:45 p.m. customer-transfer cutoff.

Everything on this page about codes and messages comes from the Federal Reserve's own public Fedwire ISO 20022 FAQs, linked where it appears. The full error code glossary is not public, and this page says so where it matters; the screens are the solution's sample data on a fictional Corvane National Bank.

What is a Fedwire reject?

A Fedwire reject is the Fedwire Funds Service refusing a message it has received, because the message breaks its format or its business rules. The payment does not settle, no funds move, and the sender gets an error message back with a code and a description. It is the network's version of what Article 4A calls rejection by a receiving bank, which happens "by a notice of rejection transmitted to the sender orally, electronically, or in writing" and "need not use any particular words" so long as it says the bank will not execute or pay the order (UCC 4A-210(a)).

Two other things are often called rejects and are not the same. A receiving bank can refuse a payment it has received through Fedwire, which it does by returning it; and a bank's own payments hub can refuse a client's payment before it ever reaches Fedwire, which sends it to the repair queue. All three land on the same desk, but they come back as different messages and each needs a different kind of fix.

The two families of Fedwire error codes, and what each asks you to fix

The Federal Reserve sorts its error codes by type, and the type tells the repair desk where to look before it reads the description. The table follows the Fed's own description of how each is delivered.

The "one at a time" detail is the one that costs time. A technical reject reports a single code, so a message with three faults can come back three times. A repair desk that fixes only the reported error and resends is working the network as a validator, one round trip per fault, with the cutoff running. Validating the whole repaired message before resending, against the same usage rules, turns three round trips into one.

What does a T error code mean on a Fedwire message?

A T code means the message itself is malformed or breaks one of Fedwire's usage rules, so the Fed could not or would not process it as written. The Fed's public FAQs explain a handful of them, and they show the range.

• T100: in "a very rare instance", the Fedwire Funds Service could not open, read or parse the sender's message at all. The admi.002 then carries "NOTAVAILABLE" instead of the original reference, and the Fed suggests requesting the Endpoint Details Sent Report to see which messages were not processed.
• T125: for FedLine Direct users, an error on outgoing wires that the Fed's answer ties to the Business Application Header: "the routing number in the From Member ID in the Business Application Header must be associated with the FedLine Direct connection owner".
• T134: a customer drawdown payment answering a drawdown request with charge bearer CRED, sent without an amount in the Charges Information field.
• T505: the code a participant puts in its own admi.002 when it cannot open a message the Fed sent it. The Fed sends no reply, but receipt of the admi.002 starts an investigation at the Fed.

These are examples, not the list. The Fed states that "The Error Code Glossary is included as an appendix in the Fedwire Funds Service ISO 20022 Technical Guide" (Fedwire technical documentation FAQs), and that guide is available only to a participant's authorised contacts, so a public page cannot reproduce it. A repair desk should have its own copy, kept with its date, because the codes change with Fedwire releases.

What is an admi.002 message?

An admi.002 is the ISO 20022 message Fedwire uses to reject a message for a technical error, and for business errors on nonvalue messages. Its most useful field for a repair desk is the reference: "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", and the admi.002 "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" (Fedwire format FAQs).

The IMAD, Fedwire's Input Message Accountability Data, is therefore the key that ties a reject to the payment in the repair queue. A desk that matches rejects to payments by amount and beneficiary instead will, sooner or later, repair the wrong one of two similar payments, or miss that a reject belongs to a payment it thought had gone.

What does RJCT mean in a pacs.002?

RJCT, for rejected, is the transaction status Fedwire puts in a pacs.002 payment status report when it rejects a value message: a customer transfer (pacs.008), a bank transfer (pacs.009) or a return (pacs.004). For those messages, business errors arrive this way, with all the error codes and descriptions in one report rather than one at a time.

The pacs.002 has a second use that looks like a reject and is not. Fedwire sends a pacs.002 with status PDNG, pending, when a value message is still being processed or has been held by the Reserve Banks (as how to track a wire transfer quotes), and then another by the close of business with ACSC (accepted, settlement completed) or RJCT (Fedwire format FAQs). A desk that treats PDNG as a failure will repair a payment that is about to settle; one that treats it as a success will tell a client a payment has gone that may yet be rejected.

Rejects that Fedwire does not raise, and checks it does not make

Passing Fedwire's validation does not mean the receiving bank can process a payment, and the Fed's own FAQs list several gaps. A good repair checks for these even though no T or E code will flag them.

• 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." A wrong purpose or reason code can pass Fedwire and fail the receiver.
• Line breaks and blank text. The carriage-return line feed is in Fedwire's permitted character set and "will not cause a rejection", but the Fed recommends against it in free text because it is causing problems for receivers' systems; free-text elements that contain only spaces cause similar problems.
• Duplicates. Fedwire checks each sender's IMADs and rejects a message that repeats one it has processed. That check stops a repeated message, not a repeated payment: a repair resent as a new message when the original had in fact settled is a second payment, and the IMAD check will not catch it.

The BIS makes the general point for every network migrating to ISO 20022: validation runs from the first formatting check to the network's own rules, and "Standardised error codes and descriptive messages facilitate root-cause identification" (CPMI Brief No 11, April 2026). A code tells you where to start; it does not tell you whether the payment, once fixed, will be paid to the right person. For that, see why valid is not right in payment validation.

What is the difference between a rejected and a returned wire?

A rejected wire never settled; a returned wire settled and came back. The difference decides which messages arrive, who acts and whether money has to be applied back to the client's account.

Returns have their own failure mode, the returned wire that cannot be matched to anything, which the return nobody can post works through. And the client's side of a return, from "account closed" to the fees, is in why a wire is returned.

Can a rejected wire be sent again?

Yes: a rejected wire did not settle, so once it is repaired it can be sent as a new message, the same day if it makes the cutoff. Three cautions apply. Resend it as a new message with its own IMAD, because Fedwire rejects a message whose IMAD repeats one it has already processed. Use the "possible duplicate" flag only when the bank genuinely does not know whether an earlier send was processed, for example after a connection failure; the Fed then checks the IMAD and rejects the message if it has already been processed. And if the repair changes who is paid or how much, it needs the same second-person check as any other repair.

There is also a client to think about. A bank that receives a client's payment order and decides not to execute it is rejecting the order under Article 4A, and acceptance and rejection have their own timing rules (UCC 4A-209). A reject that the bank cannot repair the same day should become a message to the client the same day, saying what is needed.

How Payment Repair works a Fedwire reject

Payment Repair treats a network reject the way it treats a failure at the bank's own hub: as the first line of a diagnosis. The agents match the reject to the payment by its reference, read the code and description, look up the rule behind it, propose a fix with its sources, and re-validate the whole repaired message so that one round trip does the work of several.

The reason it failed, the rule, and the fix on the same line

Some rejects should not be repaired by the desk at all. When a beneficiary bank's name check says the account belongs to a different company from the one named, and the client has paid both, there is nothing on file that proves which the client meant. Payment Repair's agents then offer candidates and recommend returning the payment to the client rather than proposing a fix.

When the code says what failed but nothing proves the fix: candidates, not a proposal

Questions people ask

Where is the Fedwire error code list?

The Federal Reserve publishes it as the Error Code Glossary, an appendix to the Fedwire Funds Service ISO 20022 Technical Guide. Only a participant's End User Authorization Contacts and other authorised contacts can request access to that guide, so ask your bank's Fedwire contacts for the current copy.

Are Fedwire error codes the same as ISO 20022 reason codes?

No. Fedwire's T, E, F, H and I codes are its own, describing why the Fed rejected a message. ISO 20022 reason codes, from the published external code lists, are what banks put in status reports and returns to say why they rejected or returned a payment; Fedwire checks only that such a code is up to four alphanumeric characters.

How long does it take to fix a rejected wire?

It depends on the cause and the cutoff. A technical error in the message's form can often be fixed and resent within minutes; a business error that needs the client's input, such as a beneficiary bank that cannot be identified, can take until the client answers. A bank should tell the client the same day if the payment will miss its date.

Does a rejected wire cost the client a fee?

That depends on the bank's fee schedule and its agreement with the client. Because a rejected wire did not settle, no other bank in the chain has deducted a fee; any charge is the sending bank's own.

What does "possible duplicate" mean on a Fedwire message?

It is a flag a sender sets in the Business Application Header when it is not sure whether a message was already processed, for example after it received neither an acknowledgement nor a rejection. Fedwire then checks the IMAD: if a message with that IMAD has already been processed, it rejects the new one.

To see a reject turned into a diagnosis and a proposed fix on the sample bank, start from Payment Repair.