Supplier Bank Detail Change Verification
Hold every supplier bank-account change in one run that checks the request, looks for linked payees and waits for a call-back.
These images are illustrations of the concept, not screenshots of the actual product.
Overview
This concept is a FluidGrids workflow for one of the riskiest moments in a supplier relationship: the day its bank details change. Instead of handling the request in an inbox thread, the design runs every change as one workflow that checks the request, looks for warning signs and waits for a recorded call-back and a second approver before the payment details are touched.
In supply chain and procurement, a bank-detail change request can arrive by email looking entirely routine. Accounts payable teams are asked to act quickly, the checks that matter are done inconsistently, and the record of who verified what ends up scattered across mailboxes. A single fraudulent change can redirect a supplier's payments before anyone notices.
The illustration shows a paused run for a bank detail change at a sample supplier, badged as awaiting a call-back, with Cancel run and Pause buttons. Its node timeline records the completed steps: a change-request form from accounts payable intake, first received by email; a Botlit confirmation with the supplier contact on file; a vendor master lookup in the ERP; an account-links check in IntelWatchtower that found two links; and a versioned risk-tier rule that set a critical tier. The run now waits at the call-back approval for a named analyst, ahead of a second approver, the ERP bank-details update and the update to the supplier record in Subscriber Bot. The Verification panel lists what the run found: a request domain that does not match the one on file, a new account in a different country, the account appearing on two other payee records, and a call-back number taken from the vendor master rather than the email. The analyst records the call-back result as confirmed by the supplier, not requested by the supplier, or unreachable, adds notes, keeps Require second approver switched on and chooses Record and continue or Reject change. A Recent bank changes panel highlights this request as paused above earlier requests from other suppliers, each with its date and outcome, such as confirmed and approved, or rejected because the supplier had not requested it.
Three other Burdenoff products take part by design. Botlit is designed to confirm the request with the supplier contact of record. IntelWatchtower is designed to report whether the new account already appears on other payee records in the sources the team has registered. Subscriber Bot is designed to hold the supplier record, which changes only after the approvals and the ERP update. FluidGrids holds the order of the checks, the risk rule, the call-back pause and the second approval, and every step lands in the run history.
What this concept shows
- A form trigger that starts the run from accounts payable intake
- A Botlit step that confirms the request with the supplier contact of record
- A domain check that flags a request sent from a domain other than the one on file
- An IntelWatchtower check for the new account on other payee records, flagged as linked payees
- A versioned risk-tier rule that sets the tier before the run pauses
- A call-back step that uses the number from the vendor master, with results for confirmed, not requested or unreachable, plus notes
- A Require second approver toggle and Record and continue or Reject change actions before the ERP and Subscriber Bot are updated
- A Recent bank changes list with each supplier's request date and outcome
How it works
- Accounts payable intake submits the change request through a form, which starts the run.
- Botlit confirms the request with the supplier contact of record, and the run looks the supplier up in the vendor master.
- The run compares the requesting domain with the one on file and asks IntelWatchtower whether the new account appears on other payee records.
- A versioned decision rule sets the risk tier.
- The run pauses while an accounts payable analyst calls back on the vendor master number and records the result.
- A second named approver signs off, then the ERP bank details are updated and the supplier record in Subscriber Bot changes.
Who it's for
- Accounts payable analysts and managers
- Procurement and supplier management teams
- Finance controllers
- Treasury and payments teams
- Fraud prevention and internal controls teams
Illustrations
1 illustration of this concept. Select one to view it full size.
Bank Detail Change Run Paused for a Call-Back
The illustration shows a FluidGrids run for a bank detail change at a sample supplier, badged paused and awaiting call-back, with Cancel run and Pause buttons. The Node timeline shows completed steps for the change-request form from accounts payable intake, a Botlit contact confirmation, a vendor master lookup in the ERP, an IntelWatchtower account-links check with two links found and a risk-tier rule set to a critical tier. A highlighted call-back approval waits for a named analyst, ahead of pending steps for a second approver, the ERP bank-details update and the Subscriber Bot record update. The Verification panel flags a domain mismatch, a new account in a different country and linked payees, and marks the call-back number as a verified source. Below sit Call-back result options, a notes field, a Require second approver toggle switched on, and Record and continue or Reject change buttons. A Recent bank changes panel shows this request as paused above earlier sample requests and their outcomes.
Topics
- supplier bank detail change verification
- vendor bank account change fraud prevention
- call-back verification workflow
- payment redirection fraud controls
- vendor master change approval
- accounts payable fraud workflow
- supplier bank change approval
- two-person approval for vendor changes
- business email compromise payment fraud
- linked payee detection
Related concepts
SOC Containment Playbook Approvals
Run containment as a playbook that pauses for a named approver before anything is blocked or disabled.
2 illustrations
Run History, Inspection and Recovery
Follow every workflow execution node by node, then retry, resume or approve runs from a desktop or a phone.
5 illustrations
Visual Decision Rules
Build a process's decision logic as a versioned tree of conditions, scores and outcomes, and test it against sample inputs.
1 illustration
Workspace Settings, Roles and Audit Trail
Configure a workspace, decide who can do what with a role matrix, and trace every change in a filterable audit log with diffs.
3 illustrations
Part of an industry solution
This concept appears in a cross-product solution on burdenoff.com — see how it works alongside other Burdenoff products to solve a problem in that industry.
