Out of band verification means confirming a request over a separate channel that the person making the request does not control: if a change arrives by email, the bank confirms it by calling a phone number, or sending a code to a device, that it already had on file. The separation is the whole control. A callback to the number in the email's signature block uses a second medium but not a second channel, because the requester chose that number; it reaches whoever sent the email. For a bank's treasury client services desk, which changes users, entitlements, limits and callback contacts for business clients, the rule is simple to state and easy to break under pressure. Botminds' Treasury Management Client Services enforces it: its callback agent can only use a contact the bank held before the request, a contact change is verified on the number already held, and a number that arrives with a request is never called.
The examples come from a fictional credit union running the solution on sample data. The standards and statistics are from NIST, the FFIEC, FinCEN and the FBI, linked where used.
In band or out of band: what each way of confirming a request actually proves
In band (looks like verification): Reply to the email, or call the number in its signature block
Out of band (is verification): Call the number the bank held before the request arrived
In band (looks like verification): Whoever sent the request
Out of band (is verification): The bank's own file, set when the client was onboarded or last verified
In band (looks like verification): That the sender agrees with themselves
Out of band (is verification): That the person at the number on file agrees to this change
In band (looks like verification): (502) 555-0188, supplied in the request: marked never to call
Out of band (is verification): (812) 555-0147, on file since March 4, 2021: the controller said she did not send it
In band (looks like verification): Nothing beyond the email
Out of band (is verification): Taking over the client's phone line as well
What is out of band verification?
Out of band verification is confirmation through a channel independent of the one a request or login arrived on. NIST's digital identity guidelines, revised in July 2025, describe the device version: "An out-of-band authenticator is a physical device that is uniquely addressable and can communicate securely with the verifier over an independent communications channel, which is referred to as the secondary channel" (NIST SP 800-63B-4). The guidelines are written for federal systems, but bank authentication guidance draws on the same vocabulary, and the FFIEC's 2021 guidance cites the earlier edition.
The term is used in two senses. In authentication it means a one-time code or approval sent to a separate device. In operations it means a callback or confirmation through a channel the requester did not supply. The principle is the same: the confirmation must travel on a path an attacker who controls the first channel cannot also control.
Out of band verification for transactions, and for the changes behind them
Banks have used out of band verification on transactions for years: a call before a large wire, a code before a new payee. The FFIEC notes that "some authentication controls use out-of-band communication and encryption protocols to support secure authentication" (FFIEC, Authentication and Access, 2021). The weaker point is usually not the transaction but the change that makes the next transaction possible: a new user, a raised limit, a new callback number.
The FBI's advice to businesses names that change directly: confirm any request to change account information over a second channel or with two-factor authentication (FBI IC3, Business Email Compromise: The $55 Billion Scam, 2024; business email compromise tools sets that advice beside the bank's own controls). The same advice applies on the bank's side of the counter. A maintenance request that changes who may move a client's money is a request for a change in account information, and it deserves a second channel at least as much as the wire that follows. What a callback file must show covers the evidence side.
Why the number in the signature block is in band
A number supplied with a request belongs to the request. Calling it tests whether the sender answers their own phone, which they will. Fraudsters supply a number for exactly that reason: it looks like an invitation to verify and is in fact the verification step, captured.
On the sample request the email named the client's controller and gave a number to call, (502) 555-0188. The bank's file held (812) 555-0147 for her, on file since March 4, 2021. The solution shows both side by side, with the supplied number marked "Never call this", and its callback agent cannot dial it. The FFIEC lists a related control for call centers: spotting a contact that departs from how and where the customer usually reaches the bank, an internet calling app or an unidentifiable number among its examples (FFIEC, 2021; contact center fraud prevention quotes it). A number the client has never used is such a deviation, whoever offers it.
A request by email, verified out of band in Treasury Management Client Services
Agent
Channel agentTests how the request arrived against the channels the agreement allows; flags a lookalike domain, its age, a differing reply-to and a first-time sender.
Never: reads a request's own claim about where it came from as proof
Agent
Callback agentPicks the contact the bank held before the request and drafts the script; shows any number in the request as never to call.
Never: calls or messages a number or address taken from the request
A person decides
Specialist calls the number on fileConfirms who answered from details in the bank's file, reads the change back exactly, asks whether they sent it.
A person decides
Specialist decidesRecords the outcome in the client's words; a "did not send it" ends the request with no change and a referral.
Why email cannot be the second channel
Email cannot verify an email, and NIST says so in mandatory terms, naming three weaknesses: access with only a password, interception in transit, and rerouting attacks such as DNS spoofing (NIST SP 800-63B-4, section 3.1.3.1).
"Email SHALL NOT be used for out-of-band authentication."
NIST SP 800-63B-4, Digital Identity Guidelines, section 3.1.3.1
For a maintenance desk the point is sharper: if the request came by email, the attacker may already be inside the client's mailbox, and a confirming email goes straight to them.
The same logic rules out a reply to the sender asking "can you confirm?", a confirmation link in the reply, and a request to "send it again from your usual address" when the usual address may be the compromised one. In the sample setup the first reply to any held request goes nowhere until the callback is complete, and the drafted note afterwards goes to the controller's address on file, never to the one on the request.
How to verify a request to change contact details
Verify it on the contact the bank already holds, never on the new one. A request to change a callback number is a request to change the out of band channel itself, and for wires a change to the security procedure the client agreed (the commercially reasonable security procedure test); confirming it on the new number lets the requester verify their own takeover. NIST treats the step as seriously as issuing a new credential: changing the registered phone number counts as binding a new authenticator (NIST SP 800-63B-4, section 3.1.3.3), and the FFIEC expects banks to have a process for changed phone numbers and carriers (FFIEC, 2021). SIM swap fraud prevention quotes both.
The sample credit union writes it as a rule: a contact or callback change is verified on the number already held, and nothing changes until the client is reached there. Its queue that Tuesday held such a request, a property manager asking by email to change its wire callback contact; the chain was broken before anyone replied. If the old number is genuinely gone, the fallback is a second administrator's number on file or a branch visit with identification, not the number in the request.
Can a deepfake voice pass a callback?
A cloned voice can answer a call only if the call reaches the fraudster, so an outbound call to a number held before the request defeats it unless the line itself has been taken over. That is why the channel, not the voice, carries the proof. FinCEN has warned that criminals use generative AI to pose as executives or trusted employees and tell staff to send large payments to accounts the criminals control (FinCEN Alert FIN-2024-Alert004; wire fraud AI quotes the alert).
AI in fraud reported to the FBI in 2025: the voice is no longer evidence
22,364
complaints reporting AI-related information
$893M
adjusted losses on those complaints
$30M+
reported by businesses lost to BEC scams involving AI
The risks that remain are the line and the inbound call. A fraudster who has ported or swapped the client's number receives the bank's call; NIST tells verifiers to weigh signs such as a device swap, a SIM change or a number port before relying on the phone network (NIST SP 800-63B-4), and the SIM swap guide covers that attack in depth. A fraudster who calls the bank, in a convincing voice, has verified nothing; the sample rules hold every telephone request for a callback the bank places.
Out of band authentication examples, ranked for a maintenance desk
Not every second channel is equally strong, and the right one depends on the change. The ranking below orders common methods by what an attacker who controls the request would also have to control to defeat them.
Ways to confirm a maintenance request, ranked by what an attacker must also control
| Method | Out of band? | What an attacker must also control | Use it for |
|---|---|---|---|
| Outbound call to the number on file, with an exact read-back | Yes | The client's phone line, through a port or SIM swap | Payment-release users, limits, administrator and contact changes |
| Confirmation in person at a branch with identification | Yes | A convincing identity document and a visit | When the number on file is gone or disputed |
| Request through the bank's secure message center | Partly | The client's online banking credentials | An allowed channel; still confirm high-risk changes by callback |
| One-time code to a device on file | Yes | The device or its number; NIST restricts delivery by telephone network | Lower-risk changes; not a substitute for a read-back |
| Signed service change form | Partly | A copy of a signature, which most signed documents provide | An allowed channel; confirm by callback |
| Reply to the requesting email | No | Nothing more | Never |
| Call to a number given in the request, or an inbound call | No | Nothing more | Never |
The request desk: the chain shows which number was called, and which was refused
What the callback still cannot prove
A good callback proves that the person at the number on file agreed to this change; it does not prove the change is allowed or sensible. NIST is blunt about the method's limit: "Out-of-band authentication is not phishing-resistant" (NIST SP 800-63B-4). A client being coached by a fraudster on another line can say yes to a change they do not understand, and a genuine administrator can ask for something the agreement does not let them have alone.
That is why the callback is one link of five, not the whole check. The sample forged request would have failed even if the controller had been fooled into saying yes: wire release needed the owner's countersignature, and the requested approval limit sat above the client's approved exposure. Why administrator requests are the ones to check hardest and which steps an agent may and may not take complete the picture. To see the callback rule enforced on a live queue, start from Treasury Management Client Services.
Questions people ask
What does out of band verification mean in banking?
Confirming a request or login through a channel separate from the one it arrived on, and one the requester does not control: a call to a number on file, a code to a registered device, a visit in person. It protects against an attacker who controls the first channel, such as a compromised email account.
Is out of band verification the same as multi-factor authentication?
Not quite. Multi-factor authentication combines different kinds of factor at login; an out-of-band device is one possible factor. A callback on a maintenance request is out of band verification of a request, not of a login, and it is usually done by a person.
Should a bank ever call the number in an email signature?
Not to verify the request. It may be a perfectly good number for a genuine client, but the bank cannot know that from the email, so it proves nothing. The bank calls the number it already holds; if that number is out of date, updating it is itself a change verified on the old number or in person.
Is a text message code good enough for a maintenance change?
For low-risk changes it may be. For anything that lets someone move money, a voice callback with an exact read-back adds what a code cannot: the client hears what is being changed. NIST also restricts telephone-network delivery of codes because numbers can be ported or swapped.
What if the client insists on being called on a new number?
Treat it as a contact change: verify it on the number already held, a second administrator's number, or in person, before using the new one. A client in genuine difficulty can usually be reached one of those ways; a fraudster cannot.