Wire callback procedures: one account number from email to Fedwire

Wire callback procedures are the steps a bank follows to confirm a payment instruction by phone before it releases a wire: the bank calls the client or the payee at a number it already holds, asks them to state the details, and records what was said and by whom. Done that way, a callback is the one check in the wire room that can catch a forged account number, because it is the only one that goes outside the channel the forgery came through. Done the common wrong way, calling the number printed on the request, it reaches the fraudster and confirms the fraud. Botminds' Wire Fraud Prevention builds the callback around that difference: its callback agent takes the number only from the bank's own records, shows where each number came from, and strikes any number that arrived with the instruction; a person then makes the recorded call.

This guide follows one account number through a fictional sample bank as it runs through the solution. Corvane National Bank's client, Brightwater Mechanical, pays its steel supplier, Kessler Steel Supply, about once a month; its last 11 payments all went to Kessler's account ending 4471 at Quillfield Bank. On Thursday 22 October a new number arrived: an account ending 9086 at Harrowgate Savings Bank in Houston.

What is a wire callback?

A wire callback is a telephone verification of a payment order or of a change to payment details, made by the bank to a number it chose. It is a recognised security procedure, not an informal courtesy: Article 4A of the Uniform Commercial Code, which governs business wires, defines a security procedure as one agreed between the bank and its customer and says it "may require the use of algorithms or other codes, identifying words or numbers, encryption, callback procedures, or similar security devices".

Two kinds of callback are often confused. The first verifies that the customer sent the order: the bank calls an authorised person at the client to confirm a wire it received. The second verifies the payee: the bank, or the client, calls the beneficiary to confirm that the bank details are really theirs. In business email compromise the first kind passes, because the client really did send the order. Only the second kind tests the account number, and it is the one the sample wire needed.

One account number's path from the supplier's email to Fedwire

The account number ending 9086 passed through five hands before it would have reached Fedwire, and each copied it faithfully. The email that carried it was a reply inside the real invoice thread, sent from a look-alike of Kessler's domain registered nine days earlier. Attached was a letter on Kessler's 2023 letterhead announcing the new account and citing an ongoing audit as the reason, and a Houston phone number for questions.

At 3:47 p.m. Brightwater's accounts payable clerk uploaded the letter to the bank's treasury portal. At 4:11 she keyed a $286,400.00 wire to the new account; at 4:12 a request arrived to change Kessler's beneficiary template to the same bank; at 4:16 the CFO approved the wire with his token. Every step was performed by an authorised person with valid credentials. Had the wire not been held, the payments hub would have formatted the same number into the Fedwire message, which since 14 July 2025 has used the ISO 20022 standard, and the beneficiary's bank in Houston would have credited the account. FinCEN described exactly this sequence in 2016 as its third scenario: a criminal impersonates a supplier, and the customer "updates its supplier's payment information on record and submits the new wire transfer instructions to its financial institution".

Look at the path as a series of controls and the problem is plain. The portal checked the clerk's login; the approval checked the CFO's token; the hub checked the message format. Each answered "is this the person, is this the format?" and none asked "is this Kessler's account?". The number itself was never tested until someone called Kessler.

What number should a bank call back?

A bank should call a number of known origin: one it held before the instruction arrived, from a source the fraudster could not have touched. In practice that means the beneficiary template set up and confirmed earlier, the client's onboarding file, or the signed treasury management agreement. It never means a number in the email, the letter, the invoice or a voicemail, and it never means a number the client's clerk read off the same email.

In the sample wire, the letter's Houston number, (713) 555-0164, was struck out and never offered. The agent proposed (412) 555-0187 from Brightwater's beneficiary template for Kessler, on file since 9 March 2021 and reconfirmed in April 2025. Showing the date matters: a number "on file" that was itself changed last week, by email, is not a number of known origin.

The callback number of known origin, with the instruction's number struck out

When is a callback required for a wire?

No federal rule requires a callback on every wire. A callback is required when the bank's funds transfer agreement makes it part of the agreed security procedure, or when the bank's own procedures say a held wire needs one. The bank decides the triggers and writes them down.

FinCEN's guidance points the same way without fixing the triggers. Its 2019 advisory on email compromise suggests checking a suspicious emailed instruction through a second channel, or with someone else authorised on the account, and leaves the when to the bank. A callback to a number of known origin is the most common way to use that second channel.

Financial institutions may verify the authenticity of suspicious emailed transaction payment instructions by using multiple means of communication or by contacting others authorized to conduct the transactions.

FinCEN Advisory FIN-2019-A005, on email compromise fraud

The usual triggers are changes, not amounts alone: new bank or account details for a known payee, a first wire to a new payee, a change to a beneficiary template, and an amount well outside the client's pattern with that payee. At the sample bank, every beneficiary change needs a callback and two names; a first wire to a payee needs one above $10,000; and a wire more than three times the client's 12-month median to that payee is held. Each threshold is a setting the wire operations manager can change, and each change is a new version on the trail.

What should a callback script ask?

A callback script should make the other side produce the facts, never just agree with them. "Can you confirm your new account ending 9086?" invites a yes from anyone. "Which bank and account should we pay you at?" can only be answered correctly by someone who knows.

A second call often follows the first. Once the payee denies the change, the operator calls the client at its own number on file. In the sample wire, the operator called Brightwater's CFO at 4:35 p.m.; he asked the bank to cancel. Under Article 4A a sender can still cancel a payment order that the bank has not yet accepted, which for an outgoing wire means not yet executed, so the call came in time.

The call's result, filled in from the recording for the operator to confirm

What is vendor impersonation fraud, and why is the template the second target?

Vendor impersonation fraud is a business email compromise in which the criminal poses as a supplier and asks the customer to pay a new account. It is the scheme in the sample wire, and its quiet second step is the more dangerous one: changing the beneficiary template, so that every later payment to the supplier goes to the new account without anyone typing it again.

At the sample bank, the template change arrived at 4:12 p.m., one minute after the wire was keyed: request BC-2210, moving Kessler's template to Harrowgate Savings Bank. Had only the wire been stopped, next month's payment would have gone to the fraudster from a template that looked approved. The solution treats every template change as its own held item, needing a callback at a number of known origin and two names. The supplier's controller denied this one at the number on file, and the request was blocked and linked to the stopped wire.

The template change behind the wire, blocked and linked

The template's own phone number deserves the same protection. A fraudster who can change the callback number on a template has defeated every future callback in advance. That is why a change to contact details needs a callback to the old number, not the new one.

When nobody answers before the cutoff

No answer is not a confirmation. A held wire whose callback goes unanswered stays held, the call is retried, and the client is told the payment may go the next business day. At the sample bank, two of the 38 callbacks made by mid-afternoon had no answer; both wires waited.

The pressure comes from the clock. The Federal Reserve accepts customer transfers until 6:45 p.m. Eastern, and banks set earlier client cutoffs to leave review time, so a callback that starts at 4:45 p.m. may not finish in time. The solution escalates held wires to the supervisor 30 minutes before a cutoff and to the wire operations manager at 15, so the decision to hold over is made by someone with the authority to make it, not by default. How the Fedwire day and the coming Sunday and holiday hours shape that decision has its own guide.

What records should a callback leave?

A callback should leave enough for someone who was not there to judge it: the number dialled and where it came from, the time, who called, who answered and their role, the questions asked and the answers given, the recording, and the decision that followed with both names. A note reading "called, confirmed" fails every one of those tests.

The record matters because, under Article 4A, the bank carries the burden of showing it followed the agreed security procedure, and a callback that cannot be shown did not happen as far as a dispute is concerned. How that burden decides who bears a loss is set out separately. The general retention rule for Bank Secrecy Act records is five years; the sample bank keeps wires, callbacks and decisions for seven, and the solution will not accept a setting below five. Its trail cannot be edited, and every export is itself logged.

Callbacks done this way are also faster to supervise. The checker who adds the second name sees the same number, source, recording and answers the operator saw, so the signature means something. To see the callback screens together, start from Wire Fraud Prevention.

Questions people ask

Should the bank or the client make the callback to the vendor?

Both can, and in business email compromise both should. The client is best placed to verify its own supplier before it sends the order; the bank calls when its procedures hold the wire. A bank callback does not relieve the client of checking its own supplier, and a client callback does not replace the bank's procedure.

Is a callback still useful if the fraudster has cloned a voice?

Yes, because a sound callback does not rely on recognising the voice. It relies on the number having been on file before the request and on the payee stating its own bank details. A fraudster who controls neither the number nor the payee's records cannot pass it, whatever the voice sounds like.

Can a callback be done by email or text instead?

Not when the instruction came by email: a reply reaches whoever controls the mailbox. The point of a callback is to use a different channel from the one the instruction used, at an address the bank chose.

How long should a callback take?

The call itself is usually a few minutes; the work around it is the long part. By Botminds' estimate, finding a trustworthy number and making the call takes about 15 minutes by hand and about 8 with the number and script prepared, most of which is the conversation.

Does a callback make the bank liable if it misses a fraud?

A callback that is part of the agreed security procedure, and is done and recorded as agreed, generally helps the bank rather than hurting it. The risk lies in skipping it or recording it badly, because then the bank cannot show it followed its own procedure.