Payment redirection fraud: the callback that stops a redirected payoff

Payment redirection fraud is the scheme in which a criminal changes where a genuine, expected payment goes. The payment was always going to be made — a supplier's invoice, a closing disbursement, a loan payoff — and a convincing message, usually from a compromised or lookalike mailbox, announces new bank details, so the payer sends the right amount to the wrong account. In corporate banking the control that answers it is a callback: a rule that a changed instruction must be confirmed by telephone, to a number the institution already holds, before the money is released, with the release locked until somebody has made the call and written down what was said. Four things have to be settled in advance for it to be worth anything: what triggers a call, which number is dialled, what is asked, and what the record must show. None of those four may be taken from the request itself, because the request is the thing in doubt. Botminds' Drawdown & Payoff Request Processing locks the release the moment an instruction stops matching the verified payee file, offers the number from that file rather than the one in the letter, and keeps the call, its outcome and the release together on one trail.

This page is about the version of the scheme a lender's funding desk meets: a redirected loan payoff, where the payee is another lender and the payment is the whole outstanding balance. (How a bank's wire room runs callbacks on its customers' outgoing wires is covered in a sibling guide; this one stays with the payoff.) The worked example runs on fictional sample data at a fictional bank's funding desk; every person, company, telephone number and account in it is invented. The legal material is the Uniform Commercial Code and federal rules and advisories, linked where they appear.

What is payment redirection fraud in corporate banking?

It is a payment made by the right person, for the right amount, at the right time, to the wrong account. FinCEN's advisory describes the mechanics: criminals compromise or impersonate the email account of a party to a transaction and use it to send fraudulent payment instructions, so that the payer's bank sends the funds to an account the criminal controls (FinCEN Advisory FIN-2016-A003). Nothing about the payment is unusual except the destination, which is why the scheme survives every check that looks at amount, timing or counterparty.

A loan payoff is close to an ideal target. The amount is the entire balance, the payee is a lender the borrower's bank may never have paid before, the letter travels by email, and the good-through date supplies urgency the criminal does not have to invent. What the published loss figures say about this class of fraud is set out in a sibling guide; the rest of this page is the control.

The callback: four fixed parts and one person

It is a written rule with four fixed parts and one person at the end of it. The trigger says when a call must happen. The number says who is dialled and where that number comes from. The script says what is asked and in what order. The record says what must be written down. The person makes the call and decides what the answer means — which is the one part that cannot be written in advance.

The distinction that matters is between a callback and a confirmation. A confirmation asks the other side to agree with something you already have: "we have your new account ending 9023, can you confirm?" A callback asks the other side to tell you what they have, on a channel you chose, and then compares it with the request. Those two conversations can use the same words and have opposite value, because an attacker who controls the mailbox will happily confirm their own numbers back to you.

A callback is also not a verification of the person's identity so much as a verification of the channel. You are not trying to prove that the voice belongs to a particular employee. You are trying to reach the payee's own organisation by a route the attacker cannot have supplied, and to ask it a question about its own records. That is why the number matters more than the questions.

When does a redirected payment need a callback? Five triggers

A trigger list that says "when the payment looks suspicious" is not a procedure, because the whole difficulty is that these payments do not look suspicious. Triggers have to be mechanical — facts a system or a clerk can test without judgement. The five below are the sample desk's, and between them they cover the shapes a redirected payment takes.

Notice what is not on the list: the amount. Large payments deserve a second approver, and most desks have one, but a trigger list built on size misses the common case — a modest, routine payment to a supplier whose details have quietly changed. Size decides how many people approve. Change decides whether anybody calls.

Who you call on a payoff: the number you already hold, never the one in the letter

The number is the whole control. Everything else in the procedure is protecting the assumption that the call reached the payee's own organisation rather than the person who wrote the request. A number taken from the letter, the email signature, the reply-to address, or a website reached by a link in that email provides no assurance at all, because all four are under the writer's control.

Federal agencies say it plainly. In a joint advisory on email compromise aimed at food-sector payments, the FBI, the FDA's Office of Criminal Investigations and the USDA advise organisations to "verify all payment changes, credit requests, and transactions in person or via a known telephone number rather than through a number or link provided in a suspicious email" (Cybersecurity Advisory AA22-340A). The useful word in that sentence is "known". The unhelpful one is "suspicious": a procedure that only applies to emails somebody found suspicious will not fire on the convincing ones, which are the ones that cost money. Write the rule for every change, not for the alarming ones.

A verified number has a history a desk can describe. It was given in a signed authorisation at onboarding, or taken from the payee's main published switchboard and confirmed with the department, or captured during an in-person meeting. Whichever route, the directory entry should carry the date and the source, so that a year later somebody can answer the question "how do we know this number is theirs?" without guessing.

On the sample day the difference was two digits. Every payment to the fictional payee had gone to a bank in Columbus since March 2025. The emailed payoff letter asked for a different bank in Dayton and printed a telephone number for questions — (614) 555-0193 — that was not in the file. The specialist dialled (614) 555-0148, the payoff desk's number in the verified directory. The payee said the account had not changed and the letter was not theirs. The number in the letter was never dialled, and that is the sentence the whole procedure exists to make true.

The number comes from the file, and the number in the letter is struck out

What to ask the payee's payoff desk on the callback

Six things, in an order designed so that the payee tells you their details rather than agreeing with yours. The sequence matters more than the wording: every question that reads your figures out loud converts a callback into a confirmation.

Why the law cares: a security procedure, not a nicety

A callback is not just good practice; it is one of the devices the Uniform Commercial Code names when it defines a security procedure for payment orders, alongside codes, identifying words and encryption (UCC § 4A-201). The same section adds that comparing a signature with a specimen on file is not, by itself, a security procedure (the text is quoted in our guide to wire callback procedures).

That second point is worth reading twice, because signature comparison is what many desks still rely on. Under Article 4A it is not a security procedure on its own, which means a bank whose entire defence is that the instruction looked properly signed is defending with something the Code has already excluded.

Why it matters is the next section of the Code. Where a bank and its customer have agreed a security procedure, an order received in the customer's name can be effective as the customer's order whether or not it was actually authorised — provided the procedure is commercially reasonable and the bank accepted the order in good faith and in compliance with it (UCC § 4A-202(b)). The loss allocation turns on the procedure, so the procedure is the thing that will be examined.

And commercial reasonableness is not a matter of opinion. Under UCC § 4A-202(c) it is a question of law, decided by looking at what the customer asked the bank for, what the bank knew of the customer and the size, type and frequency of its payment orders, what alternative procedures were offered, and what similarly situated customers and banks use (our guide to bank liability for wire fraud quotes the subsection in full). Four of those five considerations are documentary. What the customer asked for, what the bank knew about them, what alternatives were offered, and what similar institutions do are all things a bank either has written down or does not. For transfers over Fedwire the analysis is federal: Regulation J incorporates Article 4A for funds transfers through the Federal Reserve Banks (12 CFR 210.25).

Dual control sits beside the callback, not instead of it

Dual control and callbacks answer different questions. A callback asks whether the instruction is genuine. Dual control asks whether one person acting alone can move money. Among the preventive controls the OCC sets out for fraud risk management are dual controls over monetary instruments and customer transactions, alongside separation of duties (OCC Bulletin 2019-37) — and a desk that has one without the other has a visible hole.

The combination that works has three rules. The person who received the instruction should not be the only person who verifies it. The person who makes the callback should not be able to unlock the release on their own say-so — on the sample desk the lock is released by the record of the call, and a second named approver signs every release above $1,000,000. And a change to the payee directory, which is what every comparison is measured against, requires both a callback and two people, so the control cannot be defeated by quietly updating the thing it compares to.

What the record has to show the morning after

The test for a callback record is simple: could somebody who was not there reconstruct the call a year later, without asking you? That means seven things, and most desks capture three of them.

Which trigger fired, and against which comparison — not "wire check failed" but "account differs from the verified directory entry dated 3 March 2025, used twice". The number dialled, and where that number came from. The time of the call. Who answered, by name and role. What they confirmed and what they denied, in their words rather than as a tick. The outcome, as one of a fixed set: confirmed, denied, or no answer. And what happened next, linked to the release or to the fraud report.

Two details separate a record that helps from one that does not. The number dialled should be stored as a value, not as "the number on file", because the file changes. And the record should be attached to the request and to the payment that followed, so that a later question about the payment reaches the call without anybody searching a mailbox. On the sample desk the call logged at 1:49 p.m. travelled with the release to the supervisor's approval screen and into the quarter's log of callbacks and caught instruction changes.

Every outgoing instruction compared field by field with the verified file

Where callbacks fail: urgency, the single caller, the unanswered phone

Procedures rarely fail because somebody disagreed with them. They fail at the edges, under time pressure, in the cases nobody wrote down. Four failures recur.

Urgency. A request that arrives late in the day with a reason to hurry is applying pressure to exactly the step that takes the longest. The answer is structural rather than moral: set the desk's own release cut-off early enough that a callback still fits inside it, and treat a request that cannot be verified before the cut-off as tomorrow's payment. The cost of a day of interest is knowable; the cost of a wire to a stranger is not.

The single caller. Where the person who received the instruction is also the only person who verifies it, records it and releases it, the procedure has one point of failure and no way to notice. Separating any one of those roles is worth more than lengthening the script.

The unanswered phone. This is the case most procedures omit, and it has exactly one correct answer: the payment does not go. Not a message left and a release on the assumption; not the alternative number helpfully printed in the request; not an email "to save time". Leave a message on the directory number, try the payee's main published line, and if neither answers, the request waits. FinCEN's long-standing advisory frames the obligation as a matter of judgement rather than a checklist: "success in detecting and stopping BEC and EAC schemes requires careful review and verification of customers' transaction instructions and consideration of the circumstances surrounding such instructions" (FinCEN Advisory FIN-2016-A003).

The confirming callback. A call in which the bank reads out the new details and the other side says yes is worth almost nothing, and it feels like compliance, which makes it the most dangerous of the four. Build the script so the payee speaks first.

Why an email reply cannot clear a redirected payment

No, and the reason is specific rather than squeamish: in this class of fraud, email is the compromised channel. A reply confirming a change of account may come from a mailbox the attacker controls, from a domain one character different from the payee's, or from an auto-forwarding rule the payee does not know exists. Using email to verify an emailed instruction verifies nothing — it asks the same source the same question twice.

Three alternatives are genuinely equivalent, and all three share the same property: the channel is chosen by you, not offered by the request. In person, where the relationship allows it. A telephone call to a number you already hold, which is the practical answer almost every time. Or the payee's own authenticated portal, where you log in rather than follow a link — on the sample day, the re-issued payoff letter arrived that way, and the agents read and checked it again from scratch rather than treating it as already verified.

A video call sits in between. It is better than email where you know the person's face and you placed the call. It is not better than email where somebody sends you a meeting link. What the published numbers actually say about this class of fraud is worth reading before deciding how much to invest in the control, and who carries the loss when the payment goes anyway explains why the control sits on the sending side.

Questions people ask

How is payment redirection different from other wire fraud?

In most wire fraud something about the payment is wrong: an unauthorised sender, an unusual amount, a new kind of payee. In payment redirection the payment itself is genuine and expected, and only the destination has changed, so checks on the sender or the amount pass. The one comparison that catches it is the account in the instruction against the account the payer already verified.

Does a payoff callback have to be recorded?

No law requires a voice recording, and most desks do not make one. What matters is the written record: the trigger, the number dialled and where it came from, the time, who answered, what they confirmed or denied, the outcome and what followed. Article 4A puts weight on whether the bank acted in compliance with its agreed security procedure, and a procedure nobody can show was followed is hard to distinguish from one that was not.

What happens to the payoff if nobody answers the callback?

The payment waits. Leave a message on the directory number and try the payee's main published line, but do not release on an assumption, do not use a number from the request, and do not substitute an email. If the delay costs a day of interest on a payoff, that is a knowable cost; a wire to an account nobody has ever paid is not.

Is dual control the same thing as a callback?

No. Dual control means no single person can move the money alone; a callback tests whether the instruction is genuine at all. They fail differently, which is why regulators list dual controls and verification as separate preventive controls. Two people approving the same unverified instruction are two people making the same mistake.

Should the payee's new telephone number be used if they say the old one is disconnected?

Not from the request, and not from the document that prompted the call. Go to the payee's own published main line, or to a contact established through an existing relationship, and work inwards from there. A disconnected number is a reason to verify harder — it is also exactly what somebody impersonating that payee would like you to believe.

Who should make the call: the person who received the instruction?

Preferably not the same person doing all of it alone. Someone has to make the call, and it is usually the specialist who holds the request; the separation that matters is that releasing should not rest on that one person's unrecorded word. On the sample desk the release unlocks against the logged call rather than against the caller's say-so, and a second named approver signs every release above $1,000,000.