How to verify wire instructions before a payoff leaves the bank

To verify wire instructions, compare every field in the instruction you have been sent with the instruction your own records already hold for that payee, treat any difference as a stop rather than a question, and resolve it by telephoning a number you held before the request arrived. That is the whole method, and its difficulty is not intellectual: it is that the comparison has nine fields, the file is in a different system from the request, and the request usually turns up on an afternoon when there is no time. Botminds' Drawdown & Payoff Request Processing does the comparison as the document is read, and keeps the release button locked until a person has made the call and written down what the payee said.

The worked example below is the solution's sample funding desk: fictional people, banks, borrowers, accounts, telephone numbers and domains, running through one real afternoon of a payoff. The legal and supervisory material is linked where it appears.

How do you verify wire instructions?

Verification has three parts, and they are done in this order because each one is cheaper than the next. First, compare the instruction against what you already hold: the verified payee file, and every payment you have made to that payee before. Second, read the document itself for the things that cannot be compared — who sent it, from where, and how it was made. Third, if either of the first two produces a difference, telephone the payee on a number you held before today and ask them to confirm the account, then write down who you spoke to and when.

What makes this a procedure rather than a habit is that steps one and two must happen on every payment, not only on the suspicious ones. Fraudulent payoff letters do not look suspicious; that is their design. The letter in the sample case had the right borrower, the right loan number, the right principal to the cent, the right per diem and a correct good-through date. The only thing wrong with it was the account, and the only way anyone was ever going to find that was by comparing it with the account on file.

The supervisory framing is the same. The OCC's fraud risk management principles ask that "processes should be designed to anticipate fraud and deploy a combination of preventive controls and detective controls", adding that "detective controls are important because even with strong governance and oversight, collusion or circumvention of internal controls can allow fraud to occur" (OCC Bulletin 2019-37). The comparison is the preventive control. The call-back is what stops a preventive control from being a warning somebody clicks past.

The fields worth comparing, and the order to compare them in

Nine fields carry the whole of the risk, and they are not equally informative. Account number and beneficiary bank are where the money actually goes. The beneficiary name is where the lookalike hides. The remaining six are the ones that catch a careful forger being slightly too careful.

Order matters because it decides how fast a bad instruction stops. Compare bank, account and beneficiary name first; those three are a lookup, they take a second, and together they catch any changed account, which is the shape this fraud takes. Compare the sender and the document origin second, because those catch the case where the banking fields are unchanged and the fraud is elsewhere. Leave the arithmetic last: a payoff letter whose figures are wrong is usually an error, not an attack, and it is handled by sending it back.

One field deserves its own warning. A valid routing number tells you a real bank exists; it tells you nothing about whether that bank holds an account for your payee. Routing-number validation is frequently mistaken for verification, including in audit findings, and it is not even half of one field.

Does the name have to match the account number? Legally, no

This is the fact that decides who the comparison protects, and most people on a funding desk have never been told it. When a payment order identifies the beneficiary by both name and account number and the two refer to different persons, the Uniform Commercial Code provides that the beneficiary's bank, if it does not know of the conflict, may rely on the number. The text is blunt about the duty: the beneficiary's bank does not have to work out whether the name and the number belong to the same person (UCC § 4A-207(b)(1); our guide to UCC 4A-207 quotes it and the Studco case in full).

The practical consequence is that nobody downstream is checking the thing most people assume is checked. If your instruction says "Corvane Equipment Finance LLC" and carries an account number belonging to someone else entirely, the receiving institution is generally entitled to credit the number and move on. The name is, for this purpose, a label. The only comparison that protects the originator, the borrower and the payee is the one made before the order is sent — on your desk, by you.

That also disposes of an argument heard in operations meetings: that the receiving bank will catch it. It will not, and it is not obliged to. Who ends up bearing the loss when a payment reaches the wrong account is a longer and less comfortable question, worked through for a payoff in who loses when a loan payoff goes to a fraudster.

Four signals that live in the document, not in the data

Four things about a payoff letter can be assessed without comparing a single banking field, and they are the part of verification most desks skip because no system puts them in front of anyone. All four were present in the sample case.

FinCEN's advisory on e-mail compromise lists the same shapes as red flags, among them instructions sent from an address that copies a known customer's with one or more characters added, changed or removed. It is also careful about how to use them: no one red flag on its own necessarily means the activity is suspicious. That caution is why the four signals change the strength of the case rather than deciding it, while a changed account decides it on its own.

Nine fields compared, and the four signals printed beside them

The red rows are the two that matter: a different bank and a different account. The four signals below them are what the person on the telephone will want to describe to the payee.

The lookalike domain, one character at a time

The lookalike domain is worth its own section because people are poor at it and software is excellent at it. The joint advisory from the FBI, the FDA's Office of Criminal Investigations and the USDA describes the technique precisely: accounts and web addresses "may include extra letters or words, substitute characters (such as the number '1' for a lower case 'l'), or use a different top level domain", and it gives the worked example that the genuine "abccompanyllc.com" may be spoofed by "abccompany.biz", "abccompany11c.com", or "abcompanyllc.com" (Cybersecurity Advisory AA22-340A).

Read those three again slowly. The second substitutes two digits for two letters in a position nobody looks at. The third removes one of a doubled letter. Neither is visible in a mail client that shows a display name instead of an address, which most do, and neither is visible to a person who has read the address four hundred times and now sees the shape rather than the characters.

The advisory's countermeasure is the one that scales: "carefully check hyperlinks and email addresses for slight variations that can make fraudulent addresses appear legitimate and resemble the names of actual business partners. Look for additional punctuation, changes in the top-level domain". On the sample desk that check is a setting rather than a diligence: a domain is flagged when it is younger than thirty days or within one edit of a payee's known domain, and both conditions were true of the letter that arrived at 11:41.

The payee directory is the control — so guard it like one

Everything above rests on one file being right: the list of payees and the banking details you have verified for each. A comparison against a corrupted file is worse than no comparison, because it produces a green result. The attack that follows from this is obvious and it is the one sophisticated fraud actually uses: do not forge the payment, change the file.

So the file gets the strictest rules on the desk. Nothing that reads a request may write to it. A change needs a call-back and two people, exactly as a release does, and every change is stored with the call that supported it, so that a year later someone can ask why this account replaced that one and get an answer. The joint advisory puts the policy requirement in one line: "ensure company policies provide for verification of any changes to existing invoices, bank deposit information, and contact information".

The question to ask about your own desk is narrow and uncomfortable: who can edit the payee file, and does anyone review that they did? On many desks the answer is that the person who makes the payment also maintains the file, which is the single-person control that dual approval on the payment was meant to prevent.

Test it: seed a changed account into your own queue

A control nobody has tried to defeat is a belief. The test below takes an afternoon, needs no new software and can be run next week against whatever a desk runs today. The only rule is that the specialists must not know which afternoon it is.

Three numbers come out of that afternoon, and all three are worth reporting upward. How many of the three were caught at all. How long each took from arrival to challenge, measured against your own cut-off rather than against the network's. And, the one that usually causes the argument, whether the desk's response was to stop the payment or to send an email asking a colleague whether this looked right.

Expect the third case to be the one that passes. A correct account, correct amount, correct reference and a sender one character out is invisible to a comparison that only looks at banking fields, and it is the shape used to establish a relationship before the account change arrives a fortnight later.

What good evidence looks like afterwards

The point of verification is not to feel confident on the day; it is to be able to show, later, that a specific person compared specific fields and made a specific call. Three things make that possible, and all three are cheap at the time and impossible to reconstruct afterwards.

The first is the comparison itself, stored as a comparison: these nine fields, this file version, this result, at this time. The second is the call-back, stored with the number dialled, where that number came from, who answered and what they said — the number's source being the part that matters, because "we called them" is worth nothing if the number came out of the letter. The third is what the approver saw, which should be the comparison and the call, not a summary of them.

A call-back, with the number struck out and the number on file dialled

In the sample case the call took five minutes. The payee's payoff desk confirmed that its account had not changed and that the letter was not theirs; the payee re-issued through its portal at 2:06 p.m.; the corrected letter was read and re-checked, approved by a second person at 2:14 and released at 2:16 — one hour and forty-four minutes before the desk's own cut-off, and inside the good-through date, so the borrower paid no extra day of per diem. The whole defence cost the bank five minutes of a specialist's afternoon.

The checks that fire even when nothing changed

A verification procedure that only reacts to differences has a blind spot shaped like a new payee. There is nothing to compare the first instruction against, and the first instruction is the one that establishes what every later comparison will treat as normal. So three rules fire on absence rather than on difference.

The first payment to any payee requires a call-back, because the file entry is being created rather than used. A payee not paid for twelve months requires one, because dormancy is when a compromised mailbox is most useful and least noticed. And a payoff letter that did not come from the payee's own portal requires one even if every field matches, because the channel is itself a control and an instruction that avoids it has chosen to.

Those three, plus any change to bank, routing, account or beneficiary name, are the call-back triggers on the sample desk, and they are settings: a bank can add to them, and the particular agreement's own payment mechanics clause still beats any default. What is not a setting is the lock itself. The release button stays locked while any check is open, and that cannot be switched off — which is the difference between a control and a recommendation, and it is the thing to look hardest at in any account verification product you are shown.

Questions people ask

How do I know if wire instructions are legitimate?

You cannot know from the instruction itself, which is why verification is a comparison rather than a reading. Match the beneficiary name, bank, routing and account against what you already hold for that payee and against what you paid them last time; read the sender's domain, the reply-to address and how the document was produced; and telephone the payee on a number you held before the request arrived. A document that looks perfect and carries an account you have never paid is the normal shape of this fraud.

What is a verified payee directory?

It is the bank's own list of payees with the banking details it has confirmed for each, together with the evidence of how each was confirmed — who was called, on what number, and when. It is what every incoming instruction is compared against, which makes it the highest-value file on the desk: changing one line in it defeats every comparison afterwards. It should be editable only under the same dual control as a payment, and never by anything that reads requests.

Does the beneficiary name have to match the account number?

Not as a matter of law in the United States. Under UCC § 4A-207, where a payment order names a beneficiary and gives an account number that identify different persons, a beneficiary's bank that does not know of the conflict may rely on the number, and is not required to check whether the two agree. Some other jurisdictions have introduced confirmation-of-payee schemes that do check; a US funding desk should assume nobody downstream is checking and make the comparison itself.

What is a first-payment-to-a-new-payee rule?

A rule that requires a call-back when there is no history to compare against. The first time you pay a payee, the instruction cannot be verified by comparison, so it is verified by telephone, and what the call confirms becomes the file entry that every future payment is checked against. A desk with a comparison rule and no absence rule has left its first payments unguarded.

Who should be allowed to change wire instructions on file?

Not the person who releases payments, and not any system that reads incoming requests. A change should need a call-back on the previously held number and a second person's approval, and the change should be stored with the call that supported it. The simplest test of a desk's control is to ask who has edit rights on the payee file and compare that list with the list of people who can release money; any name on both lists is the control failing.

How often should wire controls be tested?

Often enough that the desk cannot guess the week, and always with a case that should pass as well as cases that should fail — a control that stops everything is as useless as one that stops nothing. Twice a year is a reasonable floor for a commercial funding desk, with a fresh test after any change to the payee file's permissions, the cut-off, or who may approve a release. The call-back procedure itself is the part worth testing hardest, because it is the part that depends on a person.