Out-of-Band Verification: Why "Page and Wallet Match" Is Not Enough

This article has three layers:

1. Layer 1: The Intuition: You cannot use a phone number provided by a scammer to verify that same scammer.
2. Layer 2: Real-World Use: Business Email Compromise (BEC), bank callbacks, Signal safety numbers, and hardware wallets.
3. Layer 3: Channel independence, what to verify, and how to guide users in product design.

Layer 1: The Intuition

1.1 Verifying a scammer with the scammer's own number

A finance employee receives an email from a "supplier": "We have changed our bank account; please send future payments to this new account." The email ends with: "If you have any questions, please call xxx to verify."

The finance employee is cautious and calls the number. The person on the other end confirms the details. The payment is made.

The problem is: The phone number was provided by the scammer within the same email. The information being verified and the information being used for verification come from the same channel. Since the attacker controls this channel, they control both the "question" and the "answer."

The correct approach is: Use a phone number that you already had and was not provided by this email to call the supplier.

1.2 Why the webpage and wallet are not two separate channels

A wallet can guarantee that "what you are signing is what is displayed in the popup," but it cannot guarantee that "what is displayed in the popup is what you actually intended."

Layer 2: Real-World Use

• Business Email Compromise (BEC): In annual reports from the FBI's Internet Crime Complaint Center, BEC is consistently one of the highest-loss crime types, costing billions of dollars every year. The standard defense for almost all corporate finance departments is: Any change in receiving accounts must be confirmed via a callback to a known phone number.
• Bank Callbacks: For large or unusual transfers, banks will call the number they have on file for you, rather than the number you provided during the transaction.
• Signal / WhatsApp Safety Numbers: The ultimate defense against Man-in-the-Middle (MITM) attacks is for two people to compare safety numbers in person or through another channel (see TOFU and Public Key Pinning). Telegram's use of emojis during calls follows a similar design: both parties read them aloud during the call; if they match, there is no MITM.
• Hardware Wallets: The screen is independent of the computer, serving as an "out-of-band" display channel. This holds true provided the device can fully decode and display the transaction; otherwise, it degrades into a blind sign (see Blind Signing vs. What You See Is What You Sign, and the Bybit incident regarding frontend integrity).
• Cryptocurrency Transfers: Before making a first-time transfer or a large transfer, verify the beginning and end digits of the receiving address through a different channel (phone, in person, or a different messaging app).

Layer 3: Principles and Engineering

3.1 Channel Independence

The standard for two channels being "independent" is: If an attacker breaches one, they do not automatically breach the other.

3.2 What to verify

• Verify enough digits of the full information: Verify at least several digits at the beginning and the end of the address; the more, the better (verifying only the first and last 4 digits cannot prevent address poisoning, see Address Poisoning).
• Verify against a trusted reference: Use information provided verbally by the person or your own saved records, rather than a message they just sent.
• The direction of verification: Have the other person say the information out loud for you to compare, rather than you reading it out and them saying "correct" (they might say "correct" without actually hearing it clearly).

3.3 Guiding users in product design

A product cannot perform out-of-band verification for the user, but it can:

• Provide explicit prompts during first-time transfers, large transfers, or high-risk actions: "Please verify the beginning and end of the receiving address through another channel (e.g., by asking the recipient directly)."
• Explain why "the page and wallet match" is insufficient, otherwise users will feel they have already verified it.
• Offer an alternative: "If it is inconvenient to verify, you can first send a very small amount and wait for the recipient to confirm receipt before sending the rest."
• Avoid including clickable action links in notification emails; instead, guide users to open the official website themselves (to prevent the email itself from becoming an attack channel, see SPF, DKIM, and DMARC).

3.4 Relationship with other lines of defense

Out-of-band verification is the final and most human-dependent line of defense. It has the highest cost, so it should only be required at the most critical moments, consistent with the logic of risk control scoring and friction design.

Summary