Contractor payment security: preventing fraud when bank details change

A bank-detail change should trigger a verification and approval process before it affects contractor payments. Confirm who requested the change through a trusted route, restrict who can approve it, and check which payments already use the old instructions. A convincing email or a successful login is only one piece of evidence.

For a company paying thousands of contractors, the difficult cases often arrive just before a payment cutoff. Someone says their account closed, asks for an urgent replacement, or claims an executive approved an exception. Give staff a reliable way to handle legitimate urgent requests while completing the required checks.

Use the bank-change control matrix, case template, and tabletop example to define ownership. The worksheet instructions explain how to run the exercise without collecting bank credentials.

Separate identity, destination, and payment authority#

Three questions need separate answers: Is this the contractor or an authorized representative? Does the proposed recipient match the verified identity established during onboarding? Who may authorize use of that destination for this payment?

Tie the payment recipient back to that verified identity through the approved payment setup and change process. A stolen identity can produce plausible documents or a convincing profile while directing money to someone else. Review identity verification, representative authority, and recipient details together, including legitimate business-payee arrangements that need additional evidence.

Account validation may establish that an account exists or can receive a payment. Its exact coverage depends on the service. It should not be treated as proof that a payment-change request came from the legitimate contractor. Likewise, recognizing an email thread does not establish that the sender still controls it safely.

The FBI's business email compromise guidance recommends verifying changes to payment instructions and warns about compromised email accounts and urgent requests. Build that verification into the workflow instead of leaving it to an employee's judgment under deadline pressure.

Decide in advance which staff can view masked payment information, request a change, verify it, approve it, and release money. Where practical, separate the person processing a sensitive change from its approver. Document a backup reviewer so vacations don't create an unofficial bypass.

Control the path from request to release#

Use this recommended control matrix to assign responsibilities and define the evidence required before release.

Keep full account numbers, identity documents, and authentication codes out of the case spreadsheet. Store evidence in the restricted system your security team approves. Operational records should point to that evidence and record the decision.

Preserve the destination version associated with each payment attempt when a profile changes. Agree with the provider on how your team will retrieve that evidence during an investigation.

Verify through a route established before the request#

A callback helps only when the number itself is trustworthy. Use contact information already established through your approved process, rather than a number supplied in the change request. Treat requests to change both contact information and banking details as a linked event requiring additional review.

Direct contractors to the known authenticated portal instead of an emailed banking form. Explain how to reach it without relying on an unsolicited link. Never ask for a password or one-time authentication code as proof of identity.

Apply similar discipline to staff accounts. Require the authentication controls your security policy specifies, remove access when roles change, and review unusual administrative actions. An attacker who controls an employee account may be able to bypass a well-designed contractor experience.

The self-service portal checklist covers the contractor-facing experience. Here, the acceptance test is broader: can a fraudulent request move through support, profile administration, and payment approval without an independent check?

Decide what happens to payments already underway#

A new bank destination may apply only to future instructions. Ask the provider whether a pending payment can be canceled, whether cancellation is confirmed, and what evidence shows the original attempt can no longer complete. Don't infer that editing a profile reroutes money already sent.

If a contractor says a payment is missing, first trace that attempt. A second payment can turn a support problem into a duplicate-payment problem. Keep the original obligation, original attempt, and any replacement connected.

A suspected compromise also requires a scoped decision about upcoming payments. Restrict use of the disputed destination and involve finance and legal in how to meet existing payment obligations safely. A security concern does not create an unrestricted right to delay unrelated amounts.

Work through a bank-change tabletop#

Consider a synthetic inspection network with a $180,000 approved run. Contractor C-104 is owed $1,250. Forty minutes before cutoff, support receives an email asking to replace the destination and send the money immediately.

The verifier calls the established number. The contractor denies making the request. Payment operations checks the run and confirms that C-104's instruction has not been submitted. The team removes the unverified change, preserves the approved obligation, and routes the account for security review. The other $178,750 remains subject to normal release controls.

The $1,250 is the amount at risk in this exercise. No fraudulent payment occurred, so it is not a measured fraud saving. If the instruction had already been sent, the team would need an urgent provider investigation to establish where the funds were and whether recovery was possible.

Run a second variation in which the email is legitimate but the trusted contact is unavailable. Staff should identify the approved escalation route and update the contractor with a realistic next step. The exercise fails if the only way to meet cutoff is an undocumented exception.

Respond quickly when money may have moved#

Assign one incident owner to coordinate payment operations, security, legal, and contractor communications. Contact the financial institution or provider immediately with the payment reference and suspected destination issue. The FBI also directs businesses to report business email compromise to IC3.

Ask the provider which recovery process applies. Don't promise a recall, return, or reversal will succeed. Preserve timestamps, access events, request messages, approvals, and payment records. Record the amount potentially exposed separately from amounts confirmed recovered.

Tell the contractor what is known, what is being investigated, and when the next update will arrive. Avoid exposing another person's information or asserting who caused the incident before the evidence supports it.

Evaluate security through an actual change scenario#

Review Wingspan with the people who own contractor setup, support, and payment release. We encrypt data in transit and at rest, as described on our security page. Build your bank-change process around those data protections and clear authority for each decision.

Bring the tabletop to a Wingspan demo. Review the controls in your proposed configuration, the actions recorded in its audit history, and the support process for a payment sent before a change. Use the exception path as part of the exercise.