Call to verify. The number came from the fraud.

Callback verification sits at the end of almost every wire fraud checklist ever written, and it has quietly become the step where a suspicious request turns into a confident one. This is a teardown of the control itself: the four ways it fails, why it is still worth doing, and the artifact that should replace the phone call.

The Tuesday that the checklist worked perfectly

Picture a closing coordinator at a mid-size title agency. It is Monday, 4:47pm, and a funding is scheduled for Tuesday at two. An email lands in an existing thread from the seller's attorney's office. Same domain, same signature block, same paralegal who has been on the thread for three weeks and who once apologised for a typo in the legal description. The message is unremarkable except for one thing: amended wire instructions. The firm's operating account is under review by their bank, so today's disbursement should go to a different institution.

The coordinator does exactly what she was trained to do. She does not reply to the email. She picks up the phone and calls the number in the signature block to verify. A woman answers with the firm's name. She knows the file number. She knows the property address, the seller's name, and the payoff amount to the cent. She apologises for the last minute change and mentions the bank review in the same slightly embarrassed tone anybody would use. The coordinator confirms the routing and account digits back to her, hears them repeated correctly, thanks her, and hangs up.

Then the coordinator opens the file checklist and ticks the box that says verbal verification of wire instructions performed with known contact. She writes the time. She initials it. This is not carelessness. This is a professional following a documented procedure that her errors and omissions carrier, her underwriter, and her state regulator all endorse.

The money leaves at 9:15 the next morning. Nobody notices for eleven days.

That composite is assembled from a pattern the FBI and the title insurance industry have documented many times over, and the detail that matters is not that somebody was fooled. It is that the control was executed correctly and still produced the wrong answer. The callback did not fail because it was skipped. It failed because it was performed.

How big is the problem the callback is supposed to solve?

Real estate is the clearest place to see it, because closings are high value, time boxed, and involve parties who have never met. Reported losses from real estate wire fraud in 2025 ran to roughly 275 million dollars across more than twelve thousand complaints, according to FBI Internet Crime Complaint Center data as compiled in CertifID's 2026 State of Wire Fraud report. The same report's survey work found that something on the order of one in four homebuyers received a communication during their transaction that they considered suspicious, which tells you the attempt rate is far higher than the loss rate.

Business email compromise, the broader category that vendor and executive impersonation sit inside, accounted for 3.05 billion dollars in reported United States losses across 24,768 complaints in 2025, with 86 percent of that money moving by wire or ACH (FBI IC3 2025 Internet Crime Report). Those rails are fast and, once the funds are onward transferred, usually final.

Layer on synthetic media. One widely cited compilation of publicly reported incidents put deepfake enabled fraud at roughly 1.65 billion dollars for 2025 (Surfshark), and the single most discussed case remains the engineering firm Arup, where a finance employee released the equivalent of about 25.5 million dollars across fifteen transfers after a video call on which, as later reporting described it, every other participant was synthetic.

Here is the uncomfortable observation that motivates this entire post. In a large share of these documented losses, somebody performed a verification step. The victim did not skip the control. The control ran, returned a green light, and the money moved.

What is callback verification actually asserting?

Strip away the procedure and a callback makes a chain of four claims, each of which has to hold for the control to mean anything.

1. This phone number belongs to the counterparty.
2. The call I placed reached that number.
3. The person who answered is authorised to confirm payment instructions for that counterparty.
4. What they told me is true.

Note that the control does not test any of these directly. It tests a proxy for all four at once: the call felt right. The number looked familiar, somebody picked up, they used the firm's name, they knew things only an insider should know, and they sounded like a person rather than a script. Every one of those signals is now cheap to manufacture, and they are cheap in ways that did not require any breakthrough in artificial intelligence, only the ordinary commoditisation of tools that already existed.

The useful analogy is a hiring manager who checks a candidate's references by calling the phone numbers the candidate wrote on their own resume. The process is real, the questions are sensible, the notes go in the file, and the entire exercise is scoped by information the subject supplied. That is the structural shape of a callback to a number that arrived in a compromised thread.

Why does the callback keep failing?

Four failure modes, in rough order of how often they show up in loss narratives.

Failure one: the number came from the attacker

This is the big one, and it is far more mundane than people expect. Guidance says to call a known number, and in practice the number gets taken from whatever is nearest to hand: the signature block of the email requesting the change, the letterhead on the attached invoice, the contact block on the closing statement, the website the email linked to, or a contact record that somebody updated three weeks ago when a polite message asked them to.

An attacker who has been sitting in a mailbox for a fortnight does not need to spoof anything to beat this. They edit the signature block on the message they send, or they submit a change of contact detail early in the relationship, long before the payment request, so that by the time anybody calls the known number, the known number is theirs. The most effective version of the attack does not touch the phone system at all. It touches your address book.

There is a second, subtler variant that catches sophisticated teams. The attacker leaves the main switchboard number alone and changes only the direct dial. The verifier calls, reaches a real sounding voicemail greeting with the right firm name, leaves a message, gets a call back within four minutes from a number that now appears in their recent calls, and treats that returned call as independent confirmation. It is not. The entire loop was seeded by the attacker.

Failure two: caller identification attests to a carrier, not a person

Many teams have quietly upgraded their mental model from I called them to they called me and the caller ID matched, which is strictly worse, and the reason it is worse deserves explaining properly because the telecom industry's own fix is widely misunderstood.

STIR and SHAKEN are the framework North American carriers use to sign call metadata, built on the PASSporT token defined in IETF RFC 8225 and the identity header in RFC 8224. When an originating carrier signs a call, it applies an attestation level. Full attestation means the carrier authenticated the customer and confirmed they are entitled to use that calling number. Partial attestation means the carrier knows the customer but not that they are entitled to that particular number. Gateway attestation means the carrier is simply passing along traffic it received from elsewhere.

Read that carefully. At its strongest, the framework asserts a relationship between a carrier and its subscriber, and that the subscriber may legitimately present that number. It says nothing whatsoever about the identity of the human speaking, and it does not stop somebody who legitimately controls a number from being an impostor on the call. It was designed to attack illegal robocalling at scale, and it helps with that. It was never designed to establish that the individual on the line is authorised to redirect 1.1 million dollars.

So when a verifier reasons that the caller ID matched the number on file and therefore the call was genuine, they are drawing an identity conclusion from a routing fact. Those are different categories.

Failure three: the voice stopped being evidence

For most of the history of commerce, recognising somebody's voice was a decent identity signal, because reproducing it required either an unusual talent or an expensive studio. That has ended, and it ended faster than institutional guidance could be rewritten.

Convincing synthetic speech now requires a short sample of a target's voice, and for the people whose voices matter most in a wire fraud (a managing partner, a chief financial officer, a firm's owner), that sample is usually public. A conference panel, a podcast appearance, a webinar recording, a local news interview, a voicemail greeting. Surveys of contact centre and fraud leaders through 2025 and 2026 have repeatedly found that a majority doubt their organisation's ability to distinguish a synthetic voice from a real one in a live call, and the honest reading of that is not that the vendors are bad. It is that a human ear on a compressed phone line, under time pressure, is a poor classifier.

Note also what the attacker does not need. They do not need a perfect clone. They need a voice that survives a two minute call on a mobile connection with background noise, where the listener has no strong prior and every reason to believe the call is routine. Telephony's own audio quality is doing a meaningful part of the attacker's work.

Failure four: the person calling wants the deal to close

This one is not technical and it is the one that policy cannot fix. The person performing the callback is almost never a fraud investigator. They are a closing coordinator, an accounts payable clerk, a paralegal, or an office manager, and their job, their performance review, and the mood of everybody around them are all aligned with completing the transaction today.

Verification in that setting is not a neutral inquiry. It is a hurdle to be cleared, and human beings clear hurdles by looking for reasons to proceed rather than reasons to stop. Confirmation bias is not a character flaw here, it is the predictable output of the incentive structure. Add the deliberate time pressure the attacker introduces (funding is at two, the seller is on a flight, the rate lock expires) and you get a verifier who is motivated to accept the first plausible reassurance.

Any control whose reliability depends on a busy person being sceptical at the exact moment they are most motivated not to be is a control with a structural defect.

So is the callback worthless?

No, and it would be irresponsible to write this piece without saying so plainly.

A documented callback to an independently sourced number stops a large volume of unsophisticated fraud. Plenty of attempts are not run by patient operators with mailbox access and a cloned voice. They are opportunistic, poorly researched, and they collapse the moment anybody picks up a phone and asks a question the attacker cannot answer. The callback also creates a record, and a record matters later, both for insurance and for the legal question of whether the party followed a commercially reasonable security procedure.

That legal dimension is worth understanding, because it shapes behaviour more than most technologists realise. Under Article 4A of the Uniform Commercial Code, which governs commercial wire transfers in the United States, loss allocation between a bank and its customer turns substantially on whether the parties agreed to a commercially reasonable security procedure and whether it was followed in good faith. That framing rewards documented process. It is why the callback is written into so many agreements, and it is also why the callback has calcified: it is legally load bearing, so nobody wants to be the first to say it is technically hollow.

The honest position is therefore not stop calling. It is: keep calling, and stop treating the call as the thing that authorises the payment. Downgrade the callback from a control to a courtesy, and put a real control underneath it.

What actually replaces the phone call?

Reframe the question. The callback is an attempt to answer "did the payee really send these instructions?" using a channel, a sound, and a memory. Every one of those is deniable and none of them leaves an artifact that a third party can check.

The replacement asks the payee to do one thing instead: sign the instruction. Not sign in the sense of typing a name into a document, which proves possession of a mailbox and is a separate problem covered in this piece on what an e-signature actually attests. Sign in the cryptographic sense, using a key held on a device the payee enrolled, over the exact bytes of the instruction that is about to be executed.

What exactly gets signed

The important design choice is that the signature covers the payload, not a session. A payee logging in and clicking approve proves that somebody had a session. A payee producing an assertion whose challenge is derived from the hash of this specific instruction proves that the holder of that key saw and accepted these specific numbers.

Canonicalise the instruction, hash it, and use the hash as the challenge:

instruction = {
  "file_ref":      "TTL-2026-04471",
  "beneficiary":   "Harlow & Sons Attorneys LLC",
  "bank_routing":  "021000021",
  "bank_account":  "****8891",
  "amount_cents":  110475000,
  "currency":      "USD",
  "effective":     "2026-09-22",
  "requested_by":  "[email protected]"
}

payload_hash = sha256(canonical_json(instruction))
challenge    = payload_hash

# The payee's enrolled device produces a WebAuthn assertion over that challenge.
# The receipt is stored with the file.
receipt = {
  "payload_hash": payload_hash,
  "signed_at":    "2026-09-21T18:22:07Z",
  "credential":   "cred_7f21ac...",
  "signature":    "MEUCIQD..."
}

Verification runs against a published key and does not call anybody:

def instruction_is_authorised(instruction, receipt, payee_public_key):
    expected = sha256(canonical_json(instruction))
    if receipt["payload_hash"] != expected:
        return False                      # the numbers changed after signing
    if not verify(payee_public_key, receipt["signature"], expected):
        return False                      # not this payee's key
    if age(receipt["signed_at"]) > timedelta(hours=72):
        return False                      # stale authorisation
    return True

Read what that buys you. If the attacker alters a single digit of the account number after the payee signed, the recomputed hash no longer matches and the receipt is void. If the attacker produces their own receipt, it does not verify against the payee's enrolled key. If the attacker phones the closing coordinator with a flawless cloned voice and the correct file number, none of it matters, because the disbursement endpoint is not asking a human whether the call felt right. It is asking whether a valid receipt exists.

This is the same structural move described in the piece on signing what the screen actually shows, applied to a wire instruction instead of a blockchain transaction. Bind the authorisation to the payload, and render the payload somewhere the attacker does not control.

How the methods compare

The row worth studying is bank account validation. It genuinely helps, and it answers a different question: does this account exist and does the name on it match the expected payee. That is useful and it is not the same as knowing that the payee asked you to send money there. A validated account owned by an attacker who used a genuine business name passes. This is the same gap covered in the piece on supplier bank detail changes, where the entire attack is a legitimate looking change request against a real relationship.

What does the payee actually experience?

The objection every title officer raises within thirty seconds is that homebuyers and one time sellers will not install anything, and they are right. So the flow has to work for somebody who has never heard of any of this.

The practical shape is that enrollment happens once, early, at a moment when the relationship is already being established and nobody is under wire pressure. For a closing, that is at engagement or at the point the file opens, not at 4:47pm the day before funding. The party being enrolled proves they are a live human on a device they control, using a companion device pairing flow with an on device face match and a liveness challenge, and what persists afterwards is a key on their phone. No biometric template is stored anywhere, only a one way key, which matters both for privacy and for what a breach of the title agency would expose.

When instructions are issued, the payee gets a prompt showing the beneficiary name, the last four digits of the account, and the amount, rendered on their own device rather than in the email thread. They confirm with the same gesture that unlocks their phone. That is the whole interaction, and it takes about fifteen seconds. The closing coordinator's screen shows a verified receipt instead of a checkbox that says a call was made.

You can see the mechanic running in the signing demo, and the integration surface is documented in the developer docs. The relevant point for a title or accounts payable team is that this gates one endpoint. It does not replace the escrow platform, the bank, or the wire rails.

What do you do when the counterparty cannot sign?

Most of them cannot, today. That is the honest state of the world and any advice that ignores it is useless. So run a graduated policy rather than a binary one, and write it down.

Tier one, enrolled payee. A valid receipt exists over this exact instruction. Release. No call required, and the file carries an artifact an underwriter or an insurer can verify without phoning anybody.

Tier two, not enrolled, below threshold. Perform the callback, but to a number obtained from a source that predates the current thread: a prior year engagement letter, the state bar or licensing directory, the recorded instrument, the bank's own branch line. Record where the number came from, not just that a call happened. That single field, source of number, is the highest value change most teams can make this quarter, because it converts an unfalsifiable checkbox into something reviewable.

Tier three, not enrolled, above threshold. Do not rely on the call. Require a second, out of band confirmation that the requester does not control: a signed letter delivered through a channel established before the transaction, an in person or video confirmation with a party you have met, or a hold and a small test transfer confirmed by the payee through a pre existing account relationship. Slow is acceptable here. Final is not.

Any tier, on a change. Treat a change to payment details as a distinct, higher risk event than an original instruction, because the attacker's entire play depends on the change being processed as routine. This mirrors the argument in the piece on why adding a payee is the real transaction: the moment that decides the outcome is the one where the account shape changes, not the one where the money moves.

Honest limits

• Enrollment coverage is the whole game. A signed instruction control protects the counterparties who enrolled. Everybody else is back on tiered callbacks. Realistically you start with repeat counterparties (lender partners, law firms you close with monthly, your top vendors by spend) and grow from there.
• It does not help if enrollment itself was compromised. If an attacker enrolled the key at the start of the relationship, everything downstream verifies perfectly. Enrollment is where the trust is established and it deserves the strongest check you have.
• A coerced or careless payee still signs. The receipt binds intent to a key, not judgment to a person. If the real payee is themselves deceived about where their money should go, the signature is valid and the outcome is bad. That is a different category, and the related discussion of authorised push payment scams treats it directly.
• It does not recover funds. This is a prevention and evidence control. Once a wire is onward transferred, the recovery question belongs to the banks and law enforcement, and speed of reporting dominates everything else.
• Manav has not shipped a signed confirmation of payee adapter for banks. The bank side composition described above, where a receiving institution signs its account ownership response, is a proposal rather than a product. What is shipped today is the per action signature, the companion device enrollment, and offline verifiable receipts.

What to do this week

1. Add a mandatory source of number field to your callback log. Not whether a call happened, but where the digits came from. Review last quarter's entries and count how many trace back to the requesting message.
2. Pull your five largest disbursements from the last ninety days and reconstruct what evidence exists that the payee asked for those details. If the answer is a checkbox and somebody's memory, you have found your exposure.
3. Write a threshold into policy above which a phone call is explicitly not sufficient, and pick the number this week rather than after an incident.
4. Stop accepting inbound calls as verification. Make the rule outbound only, to a number sourced before the current thread, with no exceptions for urgency.
5. Move payment detail changes into their own approval path with a different reviewer than the one processing the transaction.
6. Identify your ten highest volume repeat counterparties and enroll them for signed instructions. Ten covers a surprising share of disbursement value at most agencies.
7. Ask your errors and omissions carrier, in writing, what evidence they expect to see on a contested wire. Their answer will tell you what your file needs to contain.
8. Brief the team that a caller who supplies correct file details has proven nothing, because that information sits in a mailbox the attacker may already read.

Frequently asked questions

Is callback verification enough to prevent wire fraud? No. A callback establishes that a number was answered and the voice was persuasive. It does not establish identity. The number is frequently sourced from material the attacker controls, caller identification attests to a carrier relationship rather than a speaker, and voice cloning has removed the last reliable signal. It remains useful against unsophisticated attempts and should not be the control that authorises release.

Does STIR and SHAKEN stop wire fraud calls? No. STIR and SHAKEN sign call metadata so a receiving carrier can see what the originating carrier is willing to attest about the calling number, using the PASSporT token from IETF RFC 8225. At full attestation it asserts the subscriber is entitled to use that number. It makes no claim about the identity or authority of the human speaking, which is the fact a wire verification actually needs.

How do deepfakes defeat wire verification calls? They remove the informational content of a familiar voice. Convincing synthetic speech can be produced from short public samples, and the people whose voices carry authority in a payment (a partner, a controller, a firm owner) usually have public recordings. On a compressed phone line, under deadline pressure, a human listener is a weak classifier, which is why majorities of fraud leaders surveyed in recent years report low confidence in detecting synthetic voice live.

What replaces phone verification for wire instructions? A payee signed instruction receipt. The payee's enrolled device produces a cryptographic assertion over the hash of the exact instruction, including beneficiary, account and amount. The disbursing platform verifies that receipt offline against a published key and refuses to release without it. Altering any field after signing invalidates the receipt, and an attacker without the payee's device cannot produce one.

Should we keep doing callbacks at all? Yes, for counterparties who are not enrolled, and with two changes. Call outbound only, never treating an inbound call as verification, and record where the number came from rather than only that a call occurred. Above a value threshold, require a second confirmation through a channel established before the transaction, because a call alone should not authorise an irreversible transfer.

Does bank account validation solve this instead? It helps and it answers a different question. Validation confirms that an account exists and that the name matches expectations. It does not confirm that the payee asked you to send money to that account. An attacker operating an account opened in a convincing business name can pass validation cleanly, which is why account checks and instruction signing address different halves of the problem.

What about one time payees like homebuyers who will never enroll? Enroll them once at the point the file opens, when there is no wire pressure and the relationship is being established anyway. The flow is a companion device pairing with a liveness check, taking under a minute, and it leaves a key on the buyer's own phone with no biometric stored. For genuinely unreachable parties, use the tiered policy and treat the callback as a weak control with a hard threshold above it.

Sources

1. FBI Internet Crime Complaint Center, 2025 Internet Crime Report (business email compromise totals and complaint counts): ic3.gov annual reports
2. CertifID, 2026 State of Wire Fraud report (real estate wire fraud losses and homebuyer survey findings): certifid.com
3. Surfshark research, compilation of publicly reported deepfake fraud incidents and totals: surfshark.com/research
4. IETF RFC 8225, PASSporT: Personal Assertion Token (the token underlying STIR and SHAKEN): rfc-editor.org
5. IETF RFC 8224, Authenticated Identity Management in the Session Initiation Protocol: rfc-editor.org
6. Federal Communications Commission, STIR and SHAKEN caller ID authentication resources: fcc.gov/call-authentication
7. American Land Title Association, wire fraud prevention and best practices materials: alta.org
8. Uniform Commercial Code Article 4A, funds transfers and commercially reasonable security procedures: law.cornell.edu

A callback tells you that a phone was answered. It has never told you who answered it, and it stopped being able to tell you what they sounded like.