A three-layer verification call
The goal is not merely to ask whether the email was sent. Read back the critical facts.
Confirm the person
Use a known phone number, official directory or existing relationship. Ask for the individual responsible for the invoice or transfer.
Confirm the payment
State the invoice, purpose, amount and currency so the recipient can detect a fabricated or altered request.
Confirm the bank details
Read back the account name and final identifying characters rather than asking a yes-or-no question about a full number supplied by you.
Record the approval
Note the date, channel, person and details confirmed. For a business, attach the record to the payment approval.
Match the risk signal to the response
| Signal | Why it matters | Safe response |
|---|---|---|
| New account | The request changes the destination of value | Pause and verify through a pre-existing channel |
| Urgency or secrecy | Pressure reduces the chance of independent review | Slow the process and add a second approver |
| Name mismatch | Account and recipient may not align | Do not explain it away without bank and recipient confirmation |
| Unusual currency or country | The route differs from the expected relationship | Ask for the business reason and supporting record |
| Request to misstate purpose | It may evade controls or change protection | Refuse and report the request internally |
Example: verification that only repeats the attacker's data
A buyer receives new bank details by email and replies to the same thread asking if they are correct. The compromised mailbox answers yes. The buyer has confirmed nothing independently because the attacker controls both the request and the response.
A proper check uses a number from the signed contract or the supplier's established record. The buyer names the invoice and reads back key account details to a known contact, then documents the confirmation before payment release.
Useful checks with narrow meanings
IBAN checksum
Catches many character errors but cannot prove account existence or ownership.
Payee-name confirmation
Can compare account and name within supported systems but does not validate the underlying transaction.
Test payment
Can show that value reaches an account but cannot prove the account belongs to an honest counterparty.
Independent confirmation
Connects the real recipient and real obligation to the destination account when performed through a trusted channel.
Combine identity, account and instruction checks
Identity verification asks whether the person or organization is the intended recipient. Account verification asks whether the payment details belong to or are authorized by that recipient. Instruction verification asks whether the current request is genuine. A document, checksum or familiar email can support one of these questions without answering the other two.
Use independent evidence for each layer. Confirm the legal or personal name, payment purpose and relationship. Obtain account details from a trusted source and use any bank-provided name check as an additional signal. Confirm new or changed instructions through contact information stored before the request. Read back the details rather than asking only whether they look correct.
Record the outcome in proportion to the risk. A first payment, high value, unusual urgency or beneficiary change deserves stronger review. If information conflicts, pause and resolve the discrepancy instead of choosing the most convenient version. A small test can confirm routing, but it cannot prove that the person requesting the payment is honest or authorized.
Use technical checks in their proper role
Understand the limits of an IBAN checksum.
For business workflows, build dual approval and bank-detail controls.
Use format validation in its proper role
A valid checksum supports accuracy but never replaces independent recipient confirmation.
IBAN Format Checker
Check the length, characters and ISO 13616 mod-97 checksum locally in your browser.
Recipient-check and fraud sources
The sources below support independent recipient checks and prompt error reporting. They cannot replace a trusted callback or proof that the account belongs to the intended person.
Questions that establish who will receive the money
Is a video call enough?
It can help verify a known person, but deepfakes and compromised accounts mean the channel and expected context still matter. Use established contact information and internal controls.
Should I send a small test payment?
A test can validate routing but not honesty or ownership. Complete recipient verification first.
What if the recipient refuses a verification call?
Do not release a high-risk or changed-detail payment until your organization can complete an acceptable independent check.
This page uses worked reasoning and authoritative references; it does not claim first-hand testing or personalized advice. See our editorial policy.
Use this alongside the cross-border money safety collection to verify recipients, changed instructions and recovery evidence.