The Verify-on-a-Second-Channel Rule

Why this matters

Almost every serious loss a small shop takes to fraud has the same shape: somebody asked, through a channel the shop trusted, for money to go somewhere new or for access to be handed over, and somebody in the office did it. Nothing was hacked in the sense people imagine. A supplier's mailbox was, or a phone number was spoofed, or a voice was faked, and the request rode in on it. One habit stops nearly all of it, and it costs a few minutes a month. This card owns that habit; the other security cards in the library lean on it.

The rule, stated so it can be followed

Any change to where money goes, or to who can get into an account, is confirmed on a channel you already had before the request arrived. Never on the channel the request came in on, and never on contact details the request itself supplies.

Three phrases in that sentence do the work:

• A change to where money goes. New bank details for a supplier, a new direct-deposit account for an employee, a new payout account at your card processor, a "please pay this one to our other account" note. The amount on a familiar invoice is not the target; the destination is.
• Who can get into an account. A new admin added to your email, a password reset you did not start, a request to transfer your domain, a support agent asking for the code that just arrived by text, a "new tech" asking to be added to the scheduling software.
• A channel you already had. A phone number, address or person recorded in your own files before this request existed. The vocabulary for this is out-of-band verification: confirming through a path (a band) separate from the one carrying the request, so that whoever controls the first path does not control the second.

The rule says nothing about whether the request looks real. That is the point. You are not asked to detect fakes, which people are bad at under time pressure. You are asked to run one check that works whether the request is fake or genuine.

What counts as a channel you already had

Caller ID is not a channel you had. It can be set to show any number, so a call that appears to come from your supplier's real number proves nothing. The only safe direction is outbound: you dial, from your own records.

A number you looked up yourself counts, with a caution. A supply house's main line from its own website, typed into the browser by you, is reasonably safe. A number from a search result ad is not, because scammers buy ads against company names. Prefer the vendor file; fall back to a printed statement; use a web lookup last.

Why it beats the technical controls at this size

A shop of ten people has an email filter, maybe multifactor authentication, maybe a decent antivirus. Each of those defends a door. The fraud in this category walks through a door that is already open: the supplier's own mailbox, compromised on their side, sends you a perfectly authenticated email from their real address, in the middle of a real thread about a real order. Every filter you own passes it, correctly, because it is genuine mail from a genuine account. See related: Business Email Compromise and Wire Fraud Countermeasures for Trade Businesses, which covers how those takeovers happen.

The second-channel rule does not care. The attacker owns the mailbox; they do not own the phone sitting on the supply house's AR desk, and they do not own the number you wrote down fourteen months ago. To beat the rule they would need to control two independent channels at once, and at small-shop scale nobody bothers. They move on to the next office that pays on the strength of an email.

It also beats money recovery. Once a payment lands in a fraud account it is usually moved within hours, and on a business account the federal consumer protections do not apply the way owners expect. See related: Reg E + UCC 4A: ACH and Wire Fraud Protections for Trade Businesses. Prevention is a five-minute call; recovery is a race you usually lose.

The call that works

Most people skip the callback because it feels awkward, like accusing a supplier of lying. It is not, if you say it as policy:

OFFICE: Hi, it's Dana at the shop, account 4471. We
        got a letter saying your remit-to bank changed.
        Before we update anything we always call the
        number we have on file. Can you confirm it?
AR REP: We haven't changed banks. What did it say?
OFFICE: New routing and account, effective Monday,
        signed by your controller. I'll forward it
        to you, but I'm not replying to that thread.
AR REP: Send it to me direct. That's not us.
OFFICE: Done. We'll keep paying the old account.

Notice what Dana did not do: ask the email sender to confirm, or say "can you call me back" (which lets the attacker choose the callback path), or read the new account number aloud to see if the rep recognized it. She dialled out, named the policy, asked an open question, and kept the old destination live.

One gate, two outcomes

The test of a rule is that it gives the right answer whether the request is real or not, at a cost you will keep paying. Here it is run on two requests in the same month at a twelve-person plumbing shop.

Request A: the supplier "changes banks." An email arrives from the AR address of the shop's main supply house, replying inside a thread about an open order, attaching a signed letter with new remittance details and asking that the next payment, a little under a fifth of a typical month's materials spend, go to the new account. The office manager opens the vendor file, finds the AR line recorded at onboarding, and calls. The rep confirms nothing changed. The email account had been taken over on the supplier's side; the thread was real, which is why it was convincing. Outcome: payment held to the old account, supplier warned, ten minutes spent. Without the rule, that payment leaves and probably does not come back.

Request B: a tech changes his direct deposit. A text from a technician's number reads: new bank, can you switch my pay before Friday. The office manager does not reply to the text. She waits until he is in the shop at 7 a.m., asks him face to face, and he confirms and fills in the paper form. Outcome: genuine change, made one day later than he asked, about four minutes spent. Had the text come from a stolen phone or a spoofed number, the same check would have caught it, and his whole paycheck would have gone to a stranger, which is the version of this fraud payroll offices see most.

Same gate, opposite results, both correct. Across a year, a shop this size sees perhaps six to ten destination changes, most genuine. At a few minutes each the rule costs well under an hour a year. The one fraudulent request it stops typically costs more than that hour many hundreds of times over.

How it fails in practice

The rule rarely fails because someone disagrees with it. It fails at a joint:

• The callback went to the number in the request. The office "called to verify" using the phone number printed on the fake letter, and a friendly accomplice confirmed. This is the single most common failure, and it is why the vendor file needs its own number, recorded at onboarding.
• Verification by reply. "Can you confirm these details are correct?" sent back into the compromised thread. The attacker reads it and says yes.
• The owner exempted himself. The office will verify a supplier but not the owner, so the attacker becomes the owner: a text from a new number, an urgent call in a voice that sounds right. The rule applies to the owner first. See related: Voice Cloning and the Urgent Call From the Owner, and The Gift Card Request From the Boss.
• Verified once, then trusted the thread. The first change was checked and genuine; three weeks later a second "small correction" to the account number came through the same thread and was applied without a call. Every change gets its own call.
• Access requests treated as harmless. People guard money and hand over access freely: the six-digit code read out to "support," the new user added because the email said so. Access is the step before money.

What changes the answer

There is no number on file. A new supplier onboarded by email with no recorded phone line has no channel you already had. Do not create one from the request. Get it from a source you found independently (their printed catalog, a statement, a visit to the counter) and record it then, before any payment details are ever accepted.

The person on file has left. The AR contact you had is gone. Call the company's main line from your own records and ask for accounts receivable; do not accept a new contact name or number offered in the change request itself.

The request is urgent. Urgency changes nothing about the procedure and should raise your suspicion. "Must be done today or the order ships late" is how the request avoids your callback. A real supplier will wait a day for a real check.

The amount is tiny. Some attackers ask for a small test payment to the new account first. A small amount to a new destination is still a new destination.

How to make it stick

Write it as one sentence in the office procedures and have every person who can move money or change access read and initial it. Add a field to the vendor record for "verified callback number, date recorded, recorded by," fill it for every supplier now, and refuse to accept payment details for any vendor whose field is blank. Tell suppliers and staff that you do this; it reduces the awkwardness to zero and it tells attackers the office is not worth trying. The SOP that operationalises this for supplier bank changes is its own card. See related: The Vendor Bank Detail Change SOP.

References

• See related: Business Email Compromise and Wire Fraud Countermeasures for Trade Businesses
• See related: Reg E + UCC 4A: ACH and Wire Fraud Protections for Trade Businesses
• See related: The Vendor Bank Detail Change SOP
• See related: Voice Cloning and the Urgent Call From the Owner
• FBI Internet Crime Complaint Center (IC3) public service announcements on business email compromise, which describe the payment-redirection pattern this rule interrupts