A misdirected supplier payment can pass through a legitimate approval process and still land in the wrong bank account. The invoice may be real. The supplier may be real. Every required approval may have happened. But if the banking information on the supplier record is fraudulent or incorrect, the payment can still go to the wrong recipient.

This is now the most common way large companies lose money to payment fraud. In the 2026 AFP Payments Fraud and Control Survey, 76% of organizations reported attempted or actual payment fraud in 2025, and business email compromise hit 74% of them. BEC is the delivery mechanism for most misdirected payments. Someone impersonates a supplier, asks to update banking details, and waits for the next invoice to come due.

The challenge is that validation cannot be treated as a one-time onboarding event. Supplier banking information changes over time, and fraudulent change requests can exploit the gap between the original onboarding checks and the controls applied to later updates. Preventing misdirected payments requires controls that validate banking information when it is first provided and apply appropriate verification when that information changes.

Table of contents

• What is a misdirected supplier payment?
• How the fraud actually works
• Eight controls that prevent misdirected payments
• Control coverage at a glance
• What SAP, Coupa, and Workday already do, and where they stop
• What Nacha’s 2026 fraud monitoring rules require
• What to do if a payment has already gone out
• How Relish Data Assure helps prevent misdirected payments
• Frequently asked questions
• Validate the account, then keep validating it

What is a misdirected supplier payment?

A misdirected supplier payment is a legitimate, approved payment sent to a bank account that does not belong to the supplier it was intended for. It is different from invoice fraud, where the invoice itself may be fraudulent, and from a duplicate payment, where the same obligation is paid more than once.

That distinction matters because the controls are different. Invoice controls such as purchase-order and receipt matching can help identify discrepancies in the invoice itself. But those controls may not identify a fraudulent change to otherwise legitimate supplier banking information. If the invoice and supplier are valid, the payment can still pass standard matching and approval checks.

Preventing that scenario requires controls focused specifically on the supplier’s payment information, including independent bank-account verification, stronger controls around banking changes, and additional review when the data does not match trusted sources.

How the fraud actually works

Four paths account for nearly all of it. They end in the same place, which is a changed bank account on a real supplier record.

The bank change request

A fraudster compromises or spoofs a supplier’s email domain, emails AP with new banking details, and asks that future payments go there. This is the most common path by a wide margin. The request arrives with a reasonable explanation attached, usually a bank merger, an account consolidation, or a move to a new treasury provider, and it is often timed to a real invoice the fraudster already knows about.

The onboarding capture

A fraudster poses as a new supplier and provides their own account from the very beginning. Nothing is ever changed, so every change detection control you own stays silent.

The internal record edit

Someone with access to the supplier master edits the banking details directly, either through a compromised internal account or deliberately. No email is involved, which means email security tooling never sees it.

The intercepted document

A real supplier sends a genuine bank letter or voided check and it gets altered in transit, or swapped for a forgery before AP ever receives it.

What these share is more useful than what separates them. In all four, the supplier record looks normal, the invoice is real, and the approval workflow behaves exactly as designed. The only detectable signal lives in the bank account data and in the history of how that data changed.

Eight controls that prevent misdirected payments

These controls work together across onboarding, supplier changes, and payment preparation. Some can run in parallel, while others address risks that only become visible later in the supplier lifecycle.

1. Validate the bank account before the first payment

Validate supplier banking information before the account becomes eligible to receive payment. Format and routing checks are useful, but they do not establish that the account is active or associated with the intended supplier.

A stronger validation process asks two separate questions: Is the account valid and active? And does the account belong to the supplier you intend to pay?

2. Verify bank account ownership

Account-status validation and ownership verification address different risks. Confirming that an account is active does not establish that it belongs to the intended supplier.

Ownership verification compares available bank-account ownership information with the supplier identity in your system. If the account-holder information does not align with the supplier record, the discrepancy should trigger additional review.

Coverage and available validation methods vary by country, institution, and account type. Where automated ownership data is unavailable, additional methods may include document verification, supplier-authenticated open banking, or independently sourced callback verification.

3. Apply full verification to banking changes

A banking change should receive the same level of scrutiny as the banking information provided during initial onboarding.

Revalidate the new account before it becomes eligible for payment and apply independent confirmation where appropriate. Callback verification should use contact information obtained from a trusted source already on file rather than contact details supplied in the change request itself.

4. Monitor the history of banking changes

The current supplier record tells you what the banking information is now. Change history can reveal how it got there.

Useful indicators can include:

• A change to the account-holder name
• Removal of one account and addition of another in the same change event
• A new account in a different country from the account it replaced
• Multiple banking changes within a defined period

These signals do not prove fraud, but they can identify activity that warrants additional review.

5. Screen sanctions and high-risk geography

Screen relevant supplier and banking information against applicable sanctions and watchlists. Organizations may also incorporate geography-based risk indicators, including FATF and other high-risk jurisdiction lists.

A mismatch between the supplier’s registered location and the location of its bank account may also warrant additional review, particularly when there is no clear business reason for the difference.

6. Integrate controls into the supplier and payment workflow

Validation is easier to apply consistently when results are available within the workflow where supplier information is reviewed and payment decisions are made.

Integrating validation with systems such as SAP, Coupa, Workday, or SAP Ariba can reduce manual handoffs, duplicate entry, and the risk that required checks are missed during supplier onboarding or banking changes.

7. Revalidate after onboarding

A successful validation at onboarding does not mean supplier data will remain unchanged indefinitely. Accounts close, suppliers change banks, organizations are acquired, and sanctions status can change.

Use scheduled or event-based revalidation where appropriate so critical supplier information is checked again after onboarding rather than relying indefinitely on an earlier result.

8. Route exceptions for human review

Automated controls are most effective when reviewers can focus on the records that need judgment.

Records that meet configured requirements can continue through the workflow, while warnings, failed validations, or unusual change patterns are routed to the appropriate reviewer with enough context to investigate and make a decision.

This exception-based approach helps organizations apply stronger controls without requiring the same level of manual effort on every supplier record.

Control coverage at a glance

Control	Catches	Does not catch
Format and routing checks	Typos, malformed account numbers, banks that do not exist	Any real account, including the fraudster’s
Account status check	Closed and dormant accounts	Open accounts in the wrong name
Ownership verification	Accounts not registered to the supplier	Accounts opened under a deliberately matching business name, and countries where ownership data is thin
Callback verification	Email originated change requests	Internal edits, and anything where the caller accepts the number in the email
Change history monitoring	Account switches, rapid changes, cross border moves	First payment fraud, since there is no history yet
Sanctions and watchlist screening	Sanctioned parties and banks	Fraudsters who are not on any list, which is most of them
Continuous revalidation	Accounts that went stale after onboarding	Fraud that happens between cycles
Exception based review	Everything the automated checks flag	Everything the automated checks miss

No single row solves this. Rows one through three plus change history monitoring stop the large majority.

What SAP, Coupa, and Workday already do, and where they stop

These platforms provide important controls around supplier data. They can govern who creates or changes supplier records, route sensitive updates for approval, maintain change history, and apply controls around payment information. Those capabilities help ensure that supplier-data changes follow the organization’s required process.

What those workflow controls do not necessarily establish is whether the underlying banking information belongs to the intended supplier. Native bank-data checks vary by platform and jurisdiction, but independent bank-account ownership verification generally relies on external banking or verification data.

That distinction matters because a fraudulent banking change can still pass through a properly configured approval workflow if the people reviewing it do not have independent evidence that the new account belongs to the supplier. The workflow may prove that the required process was followed without proving that the banking information itself is trustworthy.

External validation tools are designed to add that additional layer of evidence. For SAP, Coupa, and Workday teams, the important questions are what the provider can verify, where validation results appear in the existing workflow, how banking changes trigger new checks, and how exceptions are handled before payment.

What Nacha’s 2026 fraud monitoring rules require

Nacha added explicit fraud monitoring obligations for ACH participants in 2026, in two phases.

Phase 1 took effect March 20, 2026. It covers all ODFIs, plus Originators, Third-Party Senders, and Third-Party Service Providers whose 2023 origination volume topped 6 million entries, and RDFIs whose 2023 ACH receipt volume topped 10 million.

Phase 2 took effect June 19, 2026. Because that date was a federal holiday, the practical date was Monday, June 22, 2026. Phase 2 dropped the volume threshold, so the same requirements now reach every remaining Originator, Third-Party Sender, Third-Party Service Provider, and RDFI regardless of size.

The rules cover ACH entries that are unauthorized or authorized under false pretenses, which is precisely what a misdirected supplier payment is. Nacha allows a risk based approach rather than naming a required method, so what counts as compliant depends on your volume and risk profile. Documented bank account validation at onboarding and at every change is the control that maps most directly to the requirement.

Relish is a Nacha Preferred Partner for Account Validation, Fraud Monitoring, and Risk and Fraud Prevention.

What to do if a payment has already gone out

Recovery is almost entirely a function of speed. The window is short and then it closes.

1. Call your bank now and request a recall or reversal. Ask for the fraud team by name, not general servicing. ACH reversal windows are measured in days.
2. File with the FBI’s Internet Crime Complaint Center at ic3.gov. Their Recovery Asset Team can work with the receiving bank to freeze funds, and it works best inside 72 hours.
3. Freeze the supplier record so nothing else releases against that account.
4. Reach the real supplier on a known good number and confirm they never sent the request.
5. Pull the change history on the record. Find out when the account changed, who approved it, and whether the same pattern shows up on other suppliers, because a fraudster who succeeded once almost always tried more than one.
6. Preserve the original email headers before anyone deletes anything. They tell you whether the domain was spoofed or genuinely compromised, and those two situations require completely different remediation.

How Relish Data Assure helps prevent misdirected payments

Relish Data Assure validates supplier information within supported enterprise workflows, including SAP, Coupa, Workday, and SAP Ariba. Validation results are returned to the systems where supplier data is being reviewed and approved, helping teams act on issues without creating a separate manual validation process. For example, in SAP S/4HANA, supplier creation or updates can trigger Data Assure validation and return results and validation history back into SAP.

For misdirected-payment risk, several capabilities are especially relevant.

Bank account status and ownership. Standard Data Assure bank validation checks banking information, while the separately licensed Bank Account Ownership add-on extends that process by verifying whether the account is open and whether the account owner matches the intended supplier.

BAO supports multiple validation methods, including bank data, Bank Document Automation, Open Banking, and Relish Call Center verification. Customers can configure which methods are enabled and the order in which they are used.

When the primary bank-data method returns no usable data, configured fallback methods can be used to extend coverage. Bank Document Automation can compare submitted bank letters or voided checks with supplier-provided information, Open Banking can allow supported suppliers to authenticate directly with their bank, and Call Center verification can provide a manual fallback where automated coverage is unavailable.

Bank Fraud Insights. Bank Fraud Insights adds three risk checks to supplier banking validation: a bank sanctions check, a location mismatch check comparing bank location with the supplier’s registered location, and a name consistency check comparing the account name with the supplier identity in systems such as SAP Ariba, Coupa, or Workday Financials.

High-risk country screening. Relish can compare supplier bank country and address country against the FATF black list, FATF grey list, and the EU list of high-risk third countries to identify geographic risk indicators that may warrant further review.

Historical bank-account change tracking. Relish can track additions, removals, and replacements in supplier banking information and surface risk indicators such as account-owner name changes, account switches, cross-border bank changes, and multiple banking changes within a defined period. These indicators do not prove fraud, but they can help identify changes that deserve additional investigation.

Exception-based review. Validation results can be returned as pass, caution, failure, or bypass outcomes, helping organizations route higher-risk or unresolved records for additional review rather than requiring the same level of manual attention on every supplier.

Data Assure is an SAP Endorsed App on SAP Store, a certified Coupa Business Spend Management Platform Ready application, and a qualified Account Validation Services provider on the Pennsylvania Treasury Department’s qualified provider list.

Relish combines supplier-data validation, bank account ownership verification, multiple verification methods, bank-fraud signals, and workflow integration in the systems customers already use.

Evaluating options? We compared the top supplier bank account verification tools for 2026, including Trustpair, Eftsure, PaymentWorks, apexanalytix, GraphiteConnect, and Trustmi.

Frequently asked questions

How do enterprises prevent paying a fraudulent supplier?

Enterprises reduce supplier-payment fraud risk by combining several controls: validating supplier banking information before payment, verifying bank-account ownership where appropriate, applying stronger controls to banking changes, screening relevant sanctions and watchlists, and maintaining approval and exception-review processes. No single control eliminates payment fraud, but layered verification reduces the chance that fraudulent banking information reaches payment.

How do you detect fraudulent supplier bank-account changes before releasing payment?

Treat a banking change as a new risk event rather than a routine master-data update. Revalidate the new banking information where your process supports it, review historical change patterns, and investigate indicators such as account-owner changes, account replacements, cross-border changes, or repeated banking updates within a short period. Relish documents these as historical bank-account change signals within its BAO capabilities.

How can finance teams reduce misdirected-payment risk when a supplier’s bank account changes?

Apply verification before the new account becomes eligible for payment. Depending on the organization’s controls, that may include bank-account ownership verification, independent callback confirmation using trusted contact information, additional approval, and a temporary payment hold until the change is resolved.

How do you verify supplier bank-account ownership before sending payment?

Bank-account ownership verification compares available account-owner information with the supplier identity in your system. Relish BAO can use bank data, Bank Document Automation, Open Banking, and Call Center verification, depending on configuration and coverage.

What are the best vendor fraud-prevention tools?

Commonly evaluated providers include Relish Data Assure, Trustpair, Eftsure, PaymentWorks, apexanalytix, GraphiteConnect, and Trustmi. They differ in bank-account ownership coverage, broader supplier-data validation, monitoring capabilities, workflow integration, and supplier-onboarding model. For enterprise buyers, the better comparison is not simply “embedded versus standalone,” but how each provider fits into existing supplier and payment workflows.

Which bank-account validation providers help prevent payment fraud?

It is useful to distinguish underlying data sources from application platforms. Relish documentation confirms GIACT as one connected bank-validation source, and Data Assure can also use multiple bank-account ownership providers and methods.

What are the alternatives to PaymentWorks for supplier payment validation?

Alternatives include Relish Data Assure, Trustpair, Eftsure, apexanalytix, GraphiteConnect, and Trustmi. The important differences include supplier onboarding model, breadth of validation, bank-account ownership methods, geographic coverage, monitoring, and how validation results integrate with systems such as SAP, Coupa, and Workday.

How do enterprises prevent supplier payment fraud without slowing down onboarding?

Use automation for routine validations and route exceptions for human review. When records meet configured requirements, they can continue through the workflow. Unresolved or higher-risk results can be directed to reviewers. This helps concentrate manual effort where it is most useful rather than applying the same review process to every supplier.

What tools help companies comply with Nacha fraud-monitoring requirements?

Nacha permits a risk-based approach rather than mandating a specific software product. Account-validation and fraud-monitoring platforms can support compliance programs by helping organizations document validation activity, results, and controls. Relish is a Nacha Preferred Partner for Account Validation, Fraud Monitoring, and Risk and Fraud Prevention.

Validate the account, then keep validating it

Misdirected payments are not an approval failure. They pass approval cleanly, every time. They are a data failure, and the data in question is one field on the supplier record that almost no procurement workflow independently checks.

Verify bank account ownership before the first payment. Run it again at every change. Keep the history so the patterns have somewhere to show up. Then move the whole thing inside the system where payments actually get released, so it runs whether or not anyone remembers it exists.

Learn more about Relish Data Assure, or get started with a short walkthrough.