How to Stop Vendor Bank Account Fraud in Dynamics 365 (F&O and BC)
An invoice can pass every approval and still pay a fraudster. How to verify vendors and bank accounts in Dynamics 365, with a 10-step playbook.
The short answer
To stop vendor bank account fraud in Dynamics 365, verify the vendor and the bank account before a payment is ever proposed, not at the moment money leaves. That means checking four things on every new vendor and every bank detail change: is the vendor who they claim to be, are they on a sanctions list, does the account exist, and does it belong to that vendor. Then make the result enforce something: a hold, a lock, a second approver.
TL;DR
- Approvals check the invoice, not the payee. An invoice can pass every workflow step in D365 and still send money to a fraudster’s account.
- Fraudsters are patient. The modern scam starts with a “trusted” contact months before the bank change request arrives.
- Four checks close the gap: vendor identity, sanctions screening, bank account validity and bank account ownership.
- A signal is not a control. What happens after a failed check, such as a payment hold or an account lock, is what protects you.
- Bank-side name checks help but are not enough. EU Verification of Payee and UK Confirmation of Payee warn at payment time, and don’t cover every payment route.
The fraud your approval workflow can’t see
Finance teams on Dynamics 365 have spent years getting invoice controls right: three-way matching, approval hierarchies, segregation of duties. Every one of those controls assumes the vendor record behind the invoice is legitimate. Vendor bank account fraud attacks that assumption directly.
Here is how it typically unfolds today.
- Month one. Someone emails your AP team as a new contact at a real supplier. Nothing is asked for. They answer a query, confirm a delivery, become familiar.
- Month six or later. The same “trusted” contact writes: the supplier has changed banks, please update the details before the next run.
- The update. Your team does what it was trained to do and calls to confirm, using the contact details in the email thread. The fraudster confirms.
- The payment. The next invoice is matched, approved and paid on schedule. Every control worked. The money is gone.
The real supplier finds out when they chase an unpaid invoice weeks later.
This is not a rare edge case. The FBI’s Internet Crime Complaint Center recorded $3.05 billion in business email compromise losses in 2025, from about 24,800 complaints, with wire transfers the main way money was moved. In Truvio’s 2026 survey of 1,000 finance professionals, 44% reported an increase in attempted invoice fraud, yet only 31% had vendor verification and onboarding controls in place.
At the moment of release, the question nobody can easily answer in standard D365 is: did this vendor’s bank account change last week, and has anyone verified who owns it?
The four questions every vendor record must answer
Every vendor in your ERP should be able to answer four questions, checked against independent data rather than the vendor’s own email.
|
Check |
The question it answers |
What it catches |
|---|---|---|
|
Vendor validation |
Is this vendor who they say they are? Name, address and tax ID are checked against an external data source. |
Fake or impersonated suppliers, typos that hide a lookalike company |
|
Sanctions screening |
Are we legally allowed to pay them? |
Vendors on US (OFAC), EU, UK or UN sanctions lists |
|
Bank account validation |
Does the account exist and is it open? Covers account and routing numbers, IBAN and SWIFT/BIC. |
Mistyped or closed accounts, invented account details |
|
Bank account ownership |
Does the account belong to this vendor? |
A real, open account that belongs to someone else, including an insider or a fraudster |
The last two are often confused. A valid account is not the same as the right account. A fraudster’s account is perfectly valid. Only an ownership check tells you the money will reach the supplier you think you are paying.
Why sanctions screening belongs in AP
Sanctions screening is often treated as a banking or trade-compliance task, but the payment leaves from your ERP. Paying a sanctioned party can bring serious penalties, and in the US, OFAC extended its record-keeping requirement from five to 10 years in March 2025. You should be able to prove, years later, that you screened a vendor before paying it. For global companies, that means screening against several lists (US, EU, UK and UN) and keeping a dated record of every result.
Doesn’t my bank already check this?
Partly, and in some regions only. Bank-side name checks are a welcome new layer, but they were not designed to protect your vendor master.
- EU Verification of Payee (VoP). Since 9 October 2025, payment providers in the euro area must check that the payee name matches the IBAN before a euro credit transfer is authorized. Non-euro EU countries follow by July 2027. The result is a match, close match or no match, and it is a warning, not a block: the payer can still choose to send. Business customers sending payments in bulk files, which is how most ERPs pay, can opt out.
- UK Confirmation of Payee (CoP). It does a similar name check for UK payments, with similar limits.
- United States. There is no universal equivalent for ACH and wire payments. Verification depends on your bank and the services you buy.
The bigger issue is timing. A bank check happens at the last second, on one payment, often in a bulk file nobody reviews line by line. By then, the fraudulent details have sat in your vendor master for days or weeks, and every system downstream has trusted them. The cheapest place to stop vendor fraud is at the moment the bank details change, not when the payment file is already at the bank.
A risk signal isn’t a control
A verification result on its own protects nobody. A red flag in a report that nobody reads before the payment run is just a record of what went wrong. What happens because of the signal is the control. Design the response before you switch on the checks.
|
If this fails… |
The right response |
Why |
|---|---|---|
|
Vendor identity or sanctions check |
Put the vendor on payment hold |
You may not be allowed to pay this party at all |
|
Bank account validity or ownership |
Lock that bank account only; keep the vendor payable |
The vendor may be legitimate and payable by check or another verified account; don’t stop the supply chain |
|
A key field changes (bank details, tax ID, legal name) |
Re-verify automatically before the next payment |
This is the moment fraud enters; payment terms or contact changes don’t need the same treatment |
|
Someone wants to release a hold |
Require a second person to approve it |
The person who requested the change can never approve it |
Three design choices matter most:
- Set your own risk tolerance. Name matching returns a confidence score, not a yes or no. A business with high-risk payees might want a warning at 86% similarity; another might set it at 90%.
- Decide how often to re-check. Sanctions lists change constantly, so re-screen on a schedule. Verified bank accounts rarely need re-checking unless the details change.
- Keep the evidence. Log every check, result, hold and release with a timestamp and a user. That log is what an auditor or regulator will ask for.
A 10-step playbook you can start in D365 today
You don’t need new software to start. These steps close the most common gaps with process and standard D365 features.
- Clean up first. Screen your existing vendor base against sanctions lists and verify the bank accounts of your top-spend and most-paid vendors. This one-time clean-up is where most hidden risk sits.
- Treat every bank change as high-risk. No exceptions for “urgent” or “trusted” requests.
- Never verify through the channel the request came from. Call back on a number you already hold for the supplier, not one in the email or its signature.
- Route vendor master changes through approval. Both Finance & Operations and Business Central can send changes to vendor records through an approval workflow. Use it for bank details and tax IDs.
- Separate the requester from the approver. The person who enters a bank change should never approve it or release the payment.
- Hold the first payment. For a new or changed bank account, hold the first payment until the account is verified, or send a small test payment and have the supplier confirm the amount.
- Flag recent changes at payment release. Give approvers a simple view of any vendor whose bank details changed in the last 30–90 days.
- Screen against every list that applies. Cover the US, EU, UK and UN lists if you pay internationally, and re-screen on a schedule.
- Log everything. Keep the who, what and when of every check and change, for at least the 10 years OFAC now expects.
- Train AP on the patient fraudster. Show the team the months-long version of the scam, not just the obvious phishing email.
The problem with a manual playbook is that it depends on people doing it perfectly, every time, under month-end pressure. That is why the next step is to make the checks automatic and the controls enforced by the system.
Automating it inside D365: Truvio Trust & Control
Trust & Control is Truvio’s vendor verification module for Dynamics 365 Finance & Operations and Business Central, targeted for Q4 2026. It runs the four checks above inside D365 and turns each result into an enforced control.
- Four verification services: vendor validation, sanctions screening, bank account validation and bank account ownership, connected to third-party data providers through Truvio BankFabric. Service and country coverage depend on the provider chosen, and you can use more than one, for example a US provider alongside a global one.
- Controls, not just flags. A failed vendor or sanctions check places a payment hold. A failed bank check locks only that account, which then can’t be used in a payment journal, while the vendor stays payable another way. Releasing either needs a second approver.
- Automatic re-verification. Changes to the fields you choose, such as bank details or tax ID, trigger fresh checks. You set how often sanctions screening re-runs.
- Your thresholds. You decide what match score triggers a warning or a review.
- A full history. Every check, result and decision is logged against the vendor.
- Works with any payment method. The lock applies whether you pay through standard D365 payments or Truvio’s payment automation.
No other Truvio product is required. Any D365 organization with vendors and bank accounts can use Trust & Control on its own. If you already use Truvio AP Automation (ExFlow), it adds the payee check that invoice approval was never designed to do.
What it looks like: the Tuesday bank change
An email asks AP to update Apex Industrial’s bank account. The clerk enters the new details in D365.
- Both bank checks queue automatically.
- Bank account validation comes back Verified: the account exists and is open.
- Bank account ownership comes back At Risk: the account doesn’t belong to Apex.
- The new account is locked. It can’t be selected for payment, and the lock can’t be removed by editing the record.
- Apex stays payable through its previously verified account.
- Every step is logged in the vendor’s validation history.
Nobody had to spot anything. The invoice approvals ran exactly as normal; the money simply could not go to the wrong place.
Frequently asked questions
What is vendor bank account fraud?
Vendor bank account fraud is when a criminal gets a company to change a supplier’s bank details to an account they control, usually by impersonating the supplier by email. Later payments to that supplier go to the fraudster instead. It is a form of business email compromise.
How do I verify a vendor bank account change?
Verify it independently of the request. Call the supplier on a number you already hold, check that the account exists, and confirm through an ownership check that it belongs to that supplier. Route the change through an approval by someone other than the requester, and hold or test the first payment.
Does Verification of Payee stop vendor fraud?
It helps but does not stop it. Verification of Payee checks the payee name against the IBAN on euro transfers and returns a warning, not a block. Bulk payment files can be opted out, and the check happens only at payment time, after the fraudulent details are already in your vendor master.
What is the difference between bank account validation and ownership verification?
Validation confirms an account exists and is open. Ownership verification confirms it belongs to the named vendor. A fraudster’s account passes validation; only an ownership check catches it.
Do companies need to screen vendors against sanctions lists?
Companies are legally prohibited from paying sanctioned parties, and screening is how they show they took reasonable steps. In the US, OFAC requires relevant records to be kept for 10 years. International companies typically screen against US, EU, UK and UN lists.
Can Dynamics 365 detect vendor bank account fraud on its own?
Standard D365 can route vendor changes through approval and log them, but it does not verify identity, sanctions status or account ownership against external data. Those checks need an add-on such as Truvio Trust & Control, or a manual process.
When is Truvio Trust & Control available?
Trust & Control is targeted for Q4 2026 for both Finance & Operations and Business Central.
The bottom line
Your approval workflow proves an invoice should be paid. It doesn’t prove who you are paying. Vendor bank account fraud lives in that gap, and the patient version of the scam is built to pass every human check. Close it where it starts: verify the vendor and the account when the details change, and let the system enforce the response.
Find out where your vendor master is exposed. Book a 20-minute vendor fraud risk review. We’ll walk through how bank changes are handled in your D365 today and show Trust & Control in action. Or start with the data: download the 2026 AP Automation Report.
Sources
- FBI Internet Crime Complaint Center, 2025 Internet Crime Report, released April 2026.
- US Treasury, OFAC, final rule extending record-keeping to 10 years, Federal Register, 21 March 2025.
- Regulation (EU) 2024/886 (Instant Payments Regulation): Verification of Payee requirements; see Deutsche Bank’s overview.
- Truvio, 2026 AP Automation Report, conducted by Sapio Research, April 2026; 1,000 finance professionals in 14 countries.
This article is for general information and isn’t legal advice. Check your sanctions and record-keeping obligations with your compliance advisors.
Stay up to date on Truvio
Sign up to receive news, product updates, and insights for customers and partners on how Truvio helps realize more value from ERP investments.
You might also like this
The Best AP Automation for Dynamics 365 in 2027: F&O and BC
For organizations standardizing on Microsoft Dynamics 365, the best AP automation in 2027 is one that runs inside the ERP rather than beside it. On th...
Your Payment Was Properly Approved. So Why Was It Still Fraudulent?
Finance teams running Dynamics 365 have spent years getting approval right. Workflow hierarchies mirror the org chart. Spending limits are enforced by...
The Only Comprehensive Guide to Accounts Payable (AP) Automation That You Need Right Now
When it comes to most business operations, you already know that efficiency is king. One of the most critical areas where your company can (and should...