A wire transfer approval process is the fixed sequence every outgoing wire must pass before the bank releases it: a written request with support, a callback to confirm the instructions on a known phone number, entry by one person and release by another, and a record of each step. Wires are hard to recall, so the checks happen before release.
Step 1: the wire request and its supporting documents
A wire request is a written instruction that starts the process, and nothing moves without one. It names the payee, the amount, the reason and the bank details, and it carries the invoice, contract or closing statement that supports the payment. An email saying "please wire today" is not a request.
Use one request form for every wire, paper or electronic. At minimum it captures:
- Requester name and date.
- Payee legal name as it appears on the contract or invoice.
- Amount and currency.
- Purpose, with the invoice, contract or settlement statement attached.
- Beneficiary bank name, routing or SWIFT code, and account number.
- Source of the bank details: the vendor master file, a signed contract, or new instructions received this time.
- Required value date and why.
The "source of bank details" field matters more than any other. A wire to a vendor already in the master file, paid by wire many times before, carries much less risk than one where the instructions arrived in an email this week. Where the details are new or changed, the request should not move to step 2 until the change itself has gone through vendor bank account change verification.
The requester should not be the person who enters the wire in the bank portal, and neither of them should be the final approver. In a very small team, the owner can be both requester and releaser if a bookkeeper enters the wire, provided the callback is still made.
Step 2: callback verification of wire instructions
Callback verification means phoning the payee to confirm the bank details before releasing a wire. The call goes to a number you already had on file, never to one in the email or document that carried the instructions. The caller reads out the details and the payee confirms them, rather than the reverse.
The FBI's Internet Crime Complaint Center describes business email compromise as criminals taking over legitimate email accounts to make unauthorized transfers, often by changing payment instructions. Its advice, in the IC3 public service announcement on business email compromise, is to use secondary channels or two-factor authentication to verify requests for changes in account information. A phone call to a known number is that secondary channel.
How to run the call
- Find the number independently. Use the vendor master file, a signed contract or the payee's public website. Never use a phone number in the email signature of the message that sent the instructions.
- Ask for the person you normally deal with, or for the payee's accounts receivable department.
- Read the account number and routing number to them and ask them to confirm against their own records. Asking them to read the numbers to you works too. Asking "is this right?" while they look at your email does not.
- Record the call on the wire request: date, time, number dialled, person spoken to and what they confirmed.
- Stop if anything is off. A payee who cannot be reached, or who sounds unsure of their own bank details, means the wire waits.
When a callback is not needed
Some businesses skip the callback for repeat wires to an unchanged template that has been verified before. That is reasonable if template edits are locked and require approval. If anyone can edit a saved template without a second person, a template wire is no safer than a new one, and the callback stays.
Why should two people release every wire transfer?
Two people should release each wire because a single login that can both create and release a wire can be phished, misused or simply mistaken, with no one to catch it. Dual control splits the bank portal roles: one user enters the wire, a different user reviews it against the request and releases it.
Most business banking portals offer a setting that requires a second user to approve wires before release. Turn it on, and confirm with the bank that it applies to every wire type, including international wires and wires sent from templates.
The releaser does more than click approve. Before releasing, they compare:
- the payee name, account number and amount in the portal with the signed request form;
- the bank details with the callback record;
- the purpose and support with what they know of the business.
A releaser who approves from a phone notification without opening the request is providing a second click, not a second check. The release should happen where the support is visible.
Keep administrator rights away from both roles. A bank portal administrator can usually create users and change approval rules, so the person who enters wires must never be an administrator.
Wire transfer approval limits and urgent exceptions
Approval limits set how large a wire each person may release, and above which amount a second approver or the owner must also sign. Limits are set both in your written policy and in the bank portal, and the portal's version is the one that actually stops a wire.
The table below is an example of a tiered limit structure. The amounts and roles are illustrative, not a recommendation.
| Wire amount (example) | Enter | Release | Extra step |
|---|---|---|---|
| Up to 10,000 to a verified template | AP clerk | Controller | None |
| Up to 50,000, or any new payee | AP clerk | Controller | Callback recorded before release |
| Over 50,000 | AP clerk | Controller and owner | Callback recorded, owner reviews support |
| Any international wire | AP clerk | Controller and owner | Callback recorded, currency and intermediary bank checked |
Urgent wires
Urgency is the pressure that breaks wire controls. Fraudulent requests often claim a deal will collapse, a supplier will stop shipping, or an executive needs it done before a flight. The policy should say plainly that no wire skips the callback or dual release because of a deadline.
Allow for real urgency with a defined fast path rather than an exception. Name a backup releaser who is reachable after hours, and keep the callback to a few minutes by maintaining verified phone numbers in the vendor master. Real business can then move quickly without anyone being asked to bend the steps.
What records prove the wire approval process ran?
The proof of a wire approval process is a file for each wire that lets someone who was not there see that every step happened in order. It holds the signed request, the support, the callback note, the bank's approval history showing two different users, and the bank confirmation.
An example wire log
Keep a wire log that summarizes each file. This row is an example.
| Field | Example value |
|---|---|
| Wire date | 2026-05-12 |
| Payee | Example Fabrication Ltd |
| Amount | 38,400.00 |
| Purpose and support | Deposit on purchase order 7712, contract attached |
| Bank details source | Vendor master, unchanged since 2025 |
| Callback | 2026-05-12 10:14, dialled number on contract, spoke to accounts receivable, account number confirmed |
| Entered by | J. Ortiz |
| Released by | M. Chen |
| Bank reference | FED reference from portal confirmation |
Reviewing the log each month
At month end, someone outside the wire process compares the wire log with the wires that appear on the bank statement. Every statement wire should have a log row and a file. Any wire on the statement without a file is the first thing to investigate, because it means the process was bypassed.
That review is one of the questions an auditor or reviewer will ask about cash, and it appears in the internal control questionnaire for cash. PreciseBankFlow extracts every line from the bank statement PDF and matches it against your records, so a wire with no matching entry is listed as an exception rather than found by eye. See how PreciseBankFlow lists bank statement exceptions for what that report contains.
Red flags that should pause a wire before approval
Red flags are features of a wire request that match how fraudulent requests usually look. Any one of them is reason to stop, make the callback and ask a second person before releasing. None of them proves fraud, but each is cheap to check and expensive to ignore.
Pause the wire when:
- The bank details are new or changed, especially when the change arrived by email.
- The beneficiary name does not match the payee. An invoice from one company paid into an account in a person's name, or a different company's name.
- The bank is in a different country or state from where the payee normally banks.
- The request asks for secrecy or tells you not to call.
- The sender's email address is slightly off, such as a swapped letter or a different domain ending.
- Payment method changed, for example from check to wire, which the IC3 announcement lists as a common tactic.
- An executive request comes from outside normal channels, such as a personal email account or a text message.
Wires from personal or family accounts
The same red flags apply to wires that bookkeepers, trustees and family members send on behalf of an older person. Sudden large wires to new recipients, pressure to keep a payment quiet, or a new "friend" directing transfers are classic warning signs. Elder financial abuse patterns in bank statements explains how those transfers look after the fact, and the same callback and second-person rules can prevent many of them.
What to do after a suspected fraudulent wire
If a wire has already gone out and you suspect fraud, contact your bank at once and ask it to request a recall from the receiving bank. Speed matters more than anything else, because funds are often moved again quickly. Keep every email and the wire file, and report the incident to the authorities as your bank or counsel advises.