# How to Verify a Vendor Bank Change or Wire Request | RankShield Financial > The out-of-band callback that stops payment fraud, done right: the script, which number to call, the red flags that trigger it, and the pre-wire checklist. > > Source: https://rankshieldfinancial.com/resources/how-to-verify-wiring-instructions-bank-changes/ · RankShield Financial (verifiable pre-settlement payment security) RankShield Network · Financial · Payment Fraud # How to Verify a Vendor Bank Change or Wire Request: The Callback Script and Checklist Almost every business payment fraud is stopped by one control: verifying a new or changed payee out of band before you pay. Here is exactly how to do it, the script to use on the call, the red flags that should trigger it, and the checklist to run before any wire. By Jamie Kloncz Founder, RankShield Financial August 18, 2026 · 12 min read Key takeaways - One control stops most business payment fraud: verifying a new or changed payee, or any wire request, out of band before you pay. It works because the fraud is an authorized payment to a switched account, and a real confirmation on a channel the attacker does not control breaks the deception. - The one rule that makes it work: never use contact information from the request itself. Call a phone number you already had, from the signed contract, a prior invoice, or your vendor master, never the number, email reply, or link in the message asking for the change. This single mistake is why most callbacks fail. - On the call, have the person read the account and routing numbers to you from their records rather than reading yours to them, confirm who you spoke with and when, and never accept an emailed confirmation as a substitute for a live voice on a known number. - Verify every time these red flags appear: a new or changed bank account, a first payment to a new payee, any urgency or secrecy, a change delivered by email, or a request to bypass your normal process. A sudden change to payment details is the single most common sign of fraud. - A callback works until the one busy week it gets skipped, which is the week the fraud lands. The durable version makes verification a required step rather than a judgment call, which is what RankShield Financial enforces before a payment settles, sealing a record that it happened. Almost every serious business payment fraud, from a switched vendor bank account to a diverted closing wire to a spoofed executive request, is stopped by the same low-tech control: verifying a new or changed payee out of band before the money moves. The FBI put business email compromise at $3.046 billion in 2025, with 86 percent of the money moving by wire or ACH 1 , and the AFP found 76 percent of organizations faced attempted or actual payments fraud 3 , yet the single defense that reliably beats these attacks is a phone call made the right way. The problem is that most guidance stops at the words "call to verify" without saying which number, what to ask, or when, which is exactly where the control fails. This is the practical version: the one rule that makes a callback work, the script to use on the call, the red flags that should trigger verification every time, and the checklist to run before any payment to a new or changed payee. It is the how behind the advice on every other page of this site. ## Why out-of-band verification is the whole defense It is worth being precise about why one phone call defeats a multi-billion-dollar crime, because understanding the mechanism is what makes people actually do it. Business payment fraud, in almost every form, is an authorized payment sent to an account the payer was deceived into trusting. The attacker does not break into a bank or forge a signature; they convince a real, authorized employee to send a real payment to the wrong place, usually by controlling one communication channel, an email thread, and using it to supply new banking details. Because the payment is authorized, it passes every control built to catch an intruder. The deception lives entirely in that one channel. Out-of-band verification breaks the attack by stepping outside the channel the attacker controls. If the request to change bank details arrived by email, you confirm it by voice, on a phone number the attacker never touched, with a person you can identify. The fraudster can spoof the email, mimic the writing style, and even reply convincingly from the compromised inbox, but they cannot answer the real vendor’s phone. That is the entire logic: the confirmation has to travel on a different channel than the request, because a request and its confirmation on the same compromised channel confirm nothing. Everything else in this guide is just doing that one thing correctly. ## The one rule that makes a callback work Here is the rule that separates a real verification from a theatrical one: never use contact information supplied by the request itself. When an email says the vendor’s bank details have changed and gives a number to call to confirm, that number belongs to the fraudster, and calling it means a confederate cheerfully confirms the fraudulent account. The same is true of a reply-to address, a link to a portal, or a contact added to the signature. All of it came from the channel you are trying to verify around, so none of it can verify anything. This is the single most common way a callback fails, and it fails silently, because the person feels like they verified. Instead, reach the payee on a number you already had before the request existed: the number on the signed contract, on a prior invoice paid without incident, in your vendor master file, or on the company’s official website that you navigated to yourself. For a closing, use the number from the settlement statement or one you looked up independently, as the guide on [real estate wire fraud](https://rankshieldfinancial.com/resources/real-estate-wire-fraud-closing/) stresses. The test is simple: if the contact information could have been placed there by whoever sent the change request, do not use it. A verification is only worth making if the channel is one the attacker had no way to touch. ## The callback script: what to say and ask A good verification call is short and specific. Identify yourself and your company, and say plainly that you are calling to verify a change to payment details before you process a payment, so the person knows what you need. Then, and this matters, ask them to read you the correct bank account and routing numbers from their records, rather than reading your numbers to them for a yes or no. Reading the numbers to someone invites an automatic "yes," and a coached fraudster will confirm anything; having them state the details independently is what actually checks them. Confirm the payee name and the reason for any change while you are there, since a legitimate vendor can explain a bank switch and a fraudster’s story tends to wobble. Close the loop by recording who you spoke with, the number you called, and the date and time, so the verification is a fact you can produce later rather than a memory. Two things to refuse along the way: do not accept an emailed confirmation as a substitute for the call, because the email is the channel you are verifying around, and do not let urgency talk you out of the step, because manufactured urgency is a tool of the scam, not a reason to skip the check. If you cannot reach the payee on a known number, the payment waits. A held payment is an inconvenience; a sent one to a fraudster is usually unrecoverable. ## The red flags that should trigger verification every time You do not need to call the whole vendor list every week; you need to verify whenever specific triggers appear, and to treat those triggers as non-negotiable. The first and most important is any new or changed bank account, because the switched payee is the core of the crime. A first payment to a brand-new payee deserves the same treatment. So does any note of urgency or secrecy, a request to act fast, keep it confidential, or bypass a normal approval, since pressure and isolation are how the scam buys time. A change delivered by email, especially one that discourages a phone call or supplies its own number, should raise the alarm rather than lower it. A few more are worth training the eye for: a slightly wrong sender domain or a reply address that differs from the display name; a request that arrives just before a deadline or a holiday; an invoice or amount that is close to normal but not quite; and any instruction to route a payment somewhere the relationship has never used before. None of these individually proves fraud, and legitimate changes do happen, which is the point: you do not judge whether it is fraud, you verify. The discipline is to let the trigger, not your read of the person’s tone, decide when to pick up the phone, because the whole design of these attacks is to feel completely normal. ## The checklist to run before any wire Before releasing a payment to a new or changed payee, run the same short checklist every time, regardless of who is asking or how tight the deadline is. First, confirm the payee’s bank details out of band, by calling a number you already had and having them read you the account and routing numbers. Second, hold the first payment to new or changed details until that verification is complete, with no exception for urgency. Third, make sure a named person, not just a process, has approved the payee and the amount, so the decision is attributable. Fourth, keep a record of the verification and the approval, so you can show later exactly what was checked and by whom. Only when all four are true does the payment go. For a wire specifically, add two habits that buy back the finality: send a small test amount first where your bank and timeline allow, and confirm receipt with the payee before sending the balance; and know your reporting path in advance, so that if something is wrong you can call your bank to request a recall and report to the FBI at ic3.gov the same day, inside the narrow window where recovery is possible. The guide on [wire fraud recovery](https://rankshieldfinancial.com/resources/wire-fraud-recovery-first-72-hours/) covers that window. The checklist is deliberately boring, because boring and consistent is exactly what beats an attack designed to exploit the one time you were rushed. ## Why callbacks fail, and how to make verification a system If the callback is so effective, why does fraud keep succeeding? Because a manual control depends on a person remembering to apply it perfectly, every time, under exactly the conditions designed to make them skip it. A verification habit holds up on a normal Tuesday and collapses during a month-end close, a staff shortage, or a CEO-flagged "urgent and confidential" wire. It also does not survive turnover well: the discipline lives in one careful person’s head, and it leaves when they do. Attackers know this, which is why they engineer urgency and time their requests for busy periods. The one skipped callback, on the one request that was actually fraudulent, is all it takes, and that is the request most engineered to get skipped. The fix is to stop relying on memory and make verification a required step in the payment process rather than a judgment call. That means the system itself will not release a payment to a new or changed payee until the out-of-band verification and a named approval are recorded, so the control applies identically to a two-thousand-dollar invoice and a two-hundred-thousand-dollar wire, on a quiet day and a chaotic one. The [payee verification](https://rankshieldfinancial.com/resources/payee-verification/) discipline is exactly this idea, turned from a habit into a standard. A control you can skip under pressure is a control an attacker will eventually beat by applying pressure; a control you cannot skip is one they cannot. ## Where RankShield Financial fits This is where RankShield Financial comes in, and the honest framing is that it does not replace the callback in this guide; it makes it a step that cannot be skipped and produces the record that a manual call does not. It is a verification and attestation layer in the payment authorization path, not a bank or a custodian of funds, and it never touches the money. Before a payment to a new or changed payee settles, it requires the payee to be verified and a named person to have approved it, and it seals a checkable record of both, so the control applies every time rather than only when someone remembers, and so you can prove afterward exactly what was verified and by whom. The boundaries stay explicit, as everywhere on this site. RankShield enforces and records the verification; it does not read your email, it does not detect the phishing that starts the fraud, and it is a design-partner-stage product that claims no network it has not built. Its value is precisely that it converts the free, effective, easily-skipped callback into a system that holds under the pressure attacks are built to create. If you want that verification enforced in front of your payments, you can [see how it works](https://rankshieldfinancial.com/how-it-works/) or [request access](https://rankshieldfinancial.com/contact/). And whether or not you ever use a tool, the call itself, made on a number you already had, is the single most valuable thing anyone reading this can start doing today. Operate it ## Verify a payment before it settles Compose a payment and the conditions around it, then run the same check the product runs on a live rail. The verdict comes back before the money would move. Pay to Amount (USD) Conditions around this payment Bank details changed by email First-time payee Amount over approval policy Approver signature verifies PRE-SETTLEMENT VERDICT RANKSHIELD NETWORK Compose a payment on the left and run the check. The verdict is returned before the money moves, the way the product returns it on a live rail. Sandbox demo · reproduces the product’s verdict logic and signing metadata · not a live network call Downloadable · SVG The verification checklist that stops most business payment fraud: confirm the payee out of band on a number you already had, hold the first payment to new details until it clears, record a named approver, and keep a verifiable record. The one rule that makes it work is to never use a phone number, reply address, or link from the request itself, because if the attacker could have placed it there, it verifies nothing. FAQ ## Frequently asked questions Every question buyers ask before they trust a payment-security platform, answered directly. JAMIE KLONCZ · RANKSHIELD FINANCIAL ONLINE Pick a question on the left, or search above. You will get the direct answer, the way an answer engine would give it. REQUEST ACCESS → Self-check ## How exposed are your payments? Five controls decide whether an authorized-payment scam gets through on a fast rail. Answer them honestly to see where you stand. - 01 Do you send payments on instant or same-day rails (RTP, FedNow, same-day ACH)? - 02 Can one person both change a vendor’s bank details and approve the payment? - 03 Do you always confirm a bank-detail change on a number from your own files, not the request? - 04 Is the first payment to a new or changed payee held for verification before it goes out? - 05 Do you keep a signed record of exactly who approved each payment? Answer all five to see where you stand · 0/5 References - [FBI IC3, 2025 Internet Crime Report (business email compromise $3.046B; 86% of BEC money moved by wire or ACH)](https://www.ic3.gov/AnnualReport/Reports/2025_IC3Report.pdf) - [FBI, Public Service Announcement on Business Email Compromise (verify payment changes by an independently obtained phone number; report to ic3.gov)](https://www.ic3.gov/PSA/2022/PSA220504) - [Association for Financial Professionals, 2026 AFP Payments Fraud and Control Survey (76% of organizations faced attempted or actual payments fraud)](https://www.financialprofessionals.org/training-resources/resources/survey-research-economic-data/details/payments-fraud) About the author ## [Jamie Kloncz](https://rankshieldfinancial.com/about/) Founder, RankShield Financial Jamie founded RankShield Financial to verify a payment’s intent and authority before it settles on instant and tokenized rails. These guides are written from building that product and reading the primary sources directly: every statistic here links to its original filing or report, never a secondhand summary. - Primary sources only: each figure links to the original filing - Honest boundaries: what verification can and cannot do is stated plainly - Last verified August 18, 2026 How RankShield Financial verifies → Request access → Verify, then settle ## See your payments verified before they settle. RankShield Financial is rolling out with design partners on instant and tokenized rails. Request access and we’ll map it to your settlement flow. Request access How it works ## Frequently asked questions ### How do I verify a change to wiring instructions or bank details? Verify it out of band: confirm the change by voice, on a phone number you already had, before you send any money. Call the vendor, title company, or requester using a number from the signed contract, a prior invoice, your vendor master, or the company’s official website that you navigated to yourself, never the phone number, reply address, or link contained in the message that asked for the change, because that contact information may belong to the fraudster. On the call, ask them to read you the correct account and routing numbers from their records, confirm the payee and the reason for any change, and record who you spoke with and when. Treat any emailed confirmation as no confirmation at all, since email is the channel you are verifying around. ### What phone number should I call to verify a payment change? A number you already had before the change request existed, so the attacker had no way to place it there. Good sources are the signed contract, a prior invoice you paid without incident, your vendor master file, or the company’s official website that you looked up yourself. For a real estate closing, use the number on the settlement statement or one you independently looked up. The number you must never call is the one provided in the email, text, or message requesting the change, or a reply-to address or link in that message, because if the request is fraudulent, that number reaches a confederate who will happily confirm the fraudulent account. The simple test: if the contact information could have been placed there by whoever sent the change request, do not use it to verify the request. ### What should I ask on a verification call? Keep it short and specific. Identify yourself and your company, and say you are calling to verify a change to payment details before processing a payment. Then ask the person to read you the correct bank account and routing numbers from their records, rather than reading your numbers to them for a yes or no, because reading numbers to someone invites an automatic confirmation while having them state the details independently actually checks them. Confirm the payee name and the reason for any change, since a legitimate vendor can explain a switch and a fraudster’s story tends to break down. Finally, record who you spoke with, the number you called, and the date and time, so the verification is a fact you can produce later rather than a memory. ### When should I verify a payment, and when can I skip it? Verify whenever a specific trigger appears, and do not skip it based on how legitimate the request feels. The triggers that require verification every time are: any new or changed bank account, a first payment to a new payee, any urgency or secrecy or request to bypass normal approval, and any change delivered by email. Additional warning signs include a slightly wrong sender domain, a request timed just before a deadline or holiday, and an instruction to route money somewhere the relationship has never used. You do not judge whether it is fraud, because these attacks are designed to feel normal; you let the trigger decide when to verify. Routine payments to established, already-verified payees on unchanged details do not need a call every time, which is what keeps the control practical. ### Can payment verification be automated instead of done by hand? The manual callback is effective and free, and everyone should learn it, but it depends on a person applying it perfectly under exactly the conditions designed to make them skip it, which is why fraud still succeeds. Automating it means making verification a required step in the payment process: the system will not release a payment to a new or changed payee until an out-of-band verification and a named approval are recorded, so the control applies identically on a quiet day and during a chaotic close, and survives staff turnover. A verification and attestation layer can enforce that check before a payment settles and seal a record that it happened, without taking custody of funds or replacing your bank. The goal is not to remove the human judgment but to make sure the check is never the step that gets skipped under pressure.