A contractor vendor bank change verification process checks a request independently before anyone changes the vendor record or releases a payment using the new instructions. The central control is a known-channel check: contact an authorized vendor representative through contact details established separately from the request being verified.
An email arriving inside a familiar project conversation is not sufficient approval. Neither is an attached bank letter on its own. The question is not whether the message looks professional. It is whether the vendor's authorized representative actually requested the change and your authorized team approved its use.
Separate Three Different Decisions
A bank change touches three records: the request, the vendor master, and the payment. The vendor master is the controlled record holding the supplier's approved payment details. A payment batch is a separate instruction to send money.
Verifying a request should not silently update both. Updating the vendor master should not silently approve an invoice. Approving an invoice should not silently approve changed bank instructions. Keep those decisions visible even when one system supports all three.
The FBI's business email compromise guidance recommends phone verification using previously known numbers rather than numbers supplied in the email request. It also discusses secondary signoff for vendor payment changes. This is longstanding guidance checked for this draft, not evidence of a new construction fraud trend or a promised prevention rate.
The workflow below is a proposed administrative control, not a security product, banking service, or guarantee against fraud. Your finance and security owners should approve its details.
Use Four Gates: Receive, Verify, Authorize, Reconcile
Gate 1: Receive Without Changing the Approved Record
Log the request against the existing vendor ID. Preserve the original message, time received, requested effective date, and the invoices or payments it claims to affect. Assign a reviewer and a backup so the request is not handled through an informal favor.
Keep the proposed instructions separate from the approved payment record while verification is pending. Avoid copying full account details into general project boards, chat threads, or shared task descriptions. Use your approved restricted storage and refer to a request ID in the workflow.
Flag any payment already being prepared that may be affected. An authorized finance owner should determine its handling under the company's controls and obligations. Do not automatically send it to the old account, and do not treat urgency as permission to use the new one.
Gate 2: Make an Independent Known-Channel Check
Start with a previously established vendor contact whose role includes the authority to confirm payment instructions. Use the independently maintained number on file, not a number newly supplied in the change request or its attachment.
Confirm the vendor identity, the person's authority, whether they requested the change, its effective date, and which payments it covers. Handle sensitive details through the approved restricted channel. Record the outcome and the source of the contact details without exposing the account number in the audit log.
If the known contact has left or cannot confirm the request, record verification as incomplete. Escalate to the approved vendor re-verification route. A request to replace the verification contact at the same time as the bank account needs its own independent review, not a shortcut around the check.
Gate 3: Authorize the Change Separately
Have the designated approver review the independent-check evidence before a permitted user changes the vendor master. Where staffing allows, separate preparation and approval. In a small business, name the owner or alternate who supplies that second review; do not pretend there is separation when one person performs both actions.
Keep an audit record of who approved, who entered the change, when it became effective, and which record was changed. Then read back the saved record in the actual system. An approval email is not proof that the correct account was entered.
Gate 4: Check the Payment and Close the Request
Before release, the authorized payment reviewer checks that the payment references the approved vendor record and intended instruction version. A batch created before the change may not reflect the current master record. Check how your actual banking and accounting tools handle that situation.
Record payment release separately from bank processing, receipt confirmation, and reconciliation. Use your approved process to confirm the outcome. A screenshot of an instruction does not establish that the intended recipient received the money.
A Bank-Change Verification Checklist
Use this as an example to review with the responsible owners, not as an adopted company policy.
| Checkpoint | Evidence to retain | Do not substitute |
|---|---|---|
| Request captured | Original request and vendor ID | A forwarded summary alone |
| Independent contact | Known contact source, reviewer, time, outcome | Number supplied in the change email |
| Authority checked | Basis for the representative's authority | Familiar name or email signature |
| Change approved | Named approver and decision | Invoice approval |
| Master read back | Saved-record check by authorized reviewer | Approval without checking entry |
| Payment checked | Instruction version and release decision | Assuming an old batch updated itself |
The log should let a reviewer reconstruct the decision without becoming a directory of sensitive bank data. Define access, retention, and the evidence location with the people responsible for those controls.
Illustrative Example: A Subcontractor's Friday Request
Imagine a hypothetical contractor receives a bank-change email shortly before a scheduled payment run. The message appears to come from a regular subcontractor and asks for immediate use of the attached instructions. This is a teaching scenario, not an account of a Blackwing engagement.
The bookkeeper logs the request and flags the affected payment for the finance owner's decision. The reviewer calls the previously established vendor contact. That person confirms a change was requested but says it applies to future invoices, not the current one.
The reviewer records the distinction and routes it for approval. The vendor-master effective date and the current payment are reviewed separately. The example shows why "verified" needs a defined scope. It is not enough to learn that some change exists and then assume every open payment should use it.
Build the Control Into the Tools
Use explicit states such as received, verification incomplete, independently confirmed, approved for entry, saved and checked, and closed. Route exceptions to a person, not to an automated approval rule based on email wording.
Blackwing's workflow systems implementation can turn an approved process into roles, forms, restricted handoffs, and tested exception paths. The construction practice focuses on connecting office and project work. Neither replaces your bank's controls or your security response arrangements.
Frequently Asked Questions
Is Replying to the Original Email Enough Verification?
No. A reply stays within the channel carrying the request. Use an independently established contact route and confirm the person's authority. If that route cannot establish the request, record the gap and escalate rather than marking it verified.
Does a Bank Letter Prove a Vendor Requested the Change?
Not by itself. Treat the letter as supporting material to review, not as a replacement for independent verification and internal authorization. Your approved process should define how supporting documents are checked and where they are stored.
What If Money May Already Have Been Sent Incorrectly?
Use your incident process immediately. The FBI advises contacting your financial institution promptly and reporting suspected business email compromise to IC3. Preserve the records for authorized responders. Do not assume that a transfer can be recalled or that funds will be recovered.