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 system, not by memory. Segregation of duties is configured, tested, and audited. When a vendor payment goes out, there is a complete record of who approved it, when, and under what authority.

And then the money lands in a criminal's account anyway.

This is not hypothetical. More than three-quarters of U.S. organizations experienced attempted or actual payments fraud in 2025, and 74% were hit by business email compromise (BEC), up sharply from 63% the year before. The FBI's Internet Crime Complaint Center put 2025 BEC losses at just over $3 billion, second only to investment fraud across every category it tracks. A meaningful share of that money moved through approval workflows that functioned exactly as designed.

Here is the answer, up front: an approval workflow proves that a payment was authorized. It does not prove where the payment is going. Those are two different controls answering two different questions, and closing the gap between them requires validating the payee's identity, the ownership of the destination account, and the risk profile of the transaction before release, not after.

Everything below supports that claim.

What an approval workflow actually proves

An approval workflow is a control over authority. When it works, it establishes four things with real evidentiary weight:

1. The obligation passed the organizations' payment controls. An invoice exists, it matches a purchase order and a receipt, and the amount is what was agreed.

    

2. The approver had the right to approve it. The workflow routed to someone whose spending limit covers the amount and whose position in the hierarchy is appropriate to the spend category.

    

3. No single person controlled the whole transaction. Whoever entered the invoice did not also release the payment.

    

4. The decision is re-constructable. There is a durable audit trail showing the sequence of approvals and the state of the record at each step.

That is a genuinely valuable set of guarantees. It defends against duplicate payments, unauthorized spend, over-limit purchases, and internal collusion. Most organizations that get audited on payment controls are being audited on precisely this.

It is also, on its own, insufficient.

What it doesn't prove

Read that list again. Every item is about the internal decision to pay. Not one of them says anything about the external party receiving the money.

An approval workflow does not verify:

• That the vendor is who the vendor master says it is. The record was created once, possibly years ago, possibly from a scanned form emailed to AP.
• That the bank account on file belongs to that vendor. In most ERP configurations, a vendor's bank account is a data field. It is trusted because it is stored, and it is stored because someone typed it in. Just because it is stored or ‘known’ does not mean it’s verified. A bank account can be stored in the ERP without being verified as belonging to the intended vendor.
• That the bank details haven't changed since the invoice was raised. Approval evaluates the invoice. The remittance details are resolved separately, often at payment-run time.
• That the destination account carries acceptable risk. Sanctions exposure, account age, geography, and whether this vendor has ever been paid at this account before are all outside the workflow's field of view.

Approval asks: should we pay this? By itself, it does not answer: who are we actually paying?

That distinction is the whole problem, and it is worth seeing laid out:

The top-left quadrant is not an edge case. It is where the losses are.

How the gap gets exploited

Attackers do not need to break an approval workflow. They need to make a fraudulent payment look like an ordinary one, and the cleanest way to do that is to change the destination while leaving the transaction itself untouched.

Vendor impersonation starts with reconnaissance, not intrusion. An attacker studies a real supplier relationship often through a compromised mailbox at the vendor. Then the impersonator sends a routine-looking message from a lookalike domain. It can be one transposed letter, a .co where a .com should be. The message is polite, references a real invoice number, and asks AP to update banking details before the next run. More than half of the organizations surveyed by the AFP reported receiving emails from domains built to be almost indistinguishable from legitimate ones.

The fraudulent bank change is the payload. Once the vendor bank account record is updated, every subsequent control behaves correctly. The invoice is real. The goods were received. The approver has authority. The three-way match succeeds. The workflow routes, approves, and releases. The audit trail will be clean, because nothing improper happened inside the workflow.

The fraud happened upstream of it, in a master data change that no approval step was ever designed to interrogate.

This is exactly why Nacha's 2026 risk management rules explicitly address payments made under ‘false pretenses’, a transaction the originator genuinely authorized, but that was induced by someone misrepresenting their identity, their authority, or their ownership of the receiving account. Phase 1 fraud monitoring requirements took effect on March 20, 2026, with the remaining originators and third parties following on June 19. The regulatory framing has caught up with what practitioners already knew: authorized and legitimate are not the same word.

The three questions your controls need to address

If approval covers authority, validation must cover the counterparty. In practice that decomposes into three questions, and they have to be answered separately because a "yes" to one does not imply a "yes" to the others.

Identity. Is this a real operating business? Verification against authoritative registries at onboarding, not a self-attested form. Tax ID, legal entity status, registered address, and beneficial ownership where the relationship warrants it. This is the layer that keeps fictitious and shell vendors out of the master file in the first place.

Ownership. Does this specific account belong to that specific vendor? This is the one most often skipped, and it is the one that can stop the attack described above. Confirming that the routing and account number resolved to the legal entity on the invoice is a different check from confirming the vendor exists. Bank account validation services and network-based verification exist precisely for this; so, does the FBI's long-standing and much simpler recommendation confirm every change to payment instructions through a secondary channel, using a phone number you already had on file, never one supplied in the request itself.

Risk. What does this destination look like? Sanctions and watchlist screenings on the payee. Anomaly checks at release: a brand-new account, a first-time payment to a vendor of long standing, a change made within days of a large invoice, a destination geography that doesn't match the vendor's operating footprint. Individually, none of these are proof of fraud. Together, they are the signal that something deserves a human's attention before funds move. And a risk signal is not a control. What happens because of that signal is the control.

Why layered controls, not a better approver

The instinctive response to a misdirected payment is to add another approver. It rarely helps, because the second approver reviews the same screen the first one did — and that screen does not display the thing that was wrong.

Layered controls work differently. Each layer is scoped to a question the others cannot answer, so an attacker has to defeat all of them rather than find the one weak reviewer.

Note where approval sits. It is the fourth layer, and it is the one nearly every organization already runs well. The exposure is almost never in the approval layer. It is in the three layers that come before it and the one that comes after. Those layers live in vendor master data and payment release, where governance is thinner, and ownership is often ambiguous between AP, treasury, procurement, and IT.

There is a practical reason this matters more than it used to. Treasury teams are the ones catching this: AFP respondents identified treasury as the function most likely to discover attempted fraud, at 83%. But only 17% of organizations are using AI-assisted tooling for fraud mitigation at all. The detection burden is landing on a small number of people reviewing a growing volume of payments, largely by eye.

That does not scale. Controls embedded in the payment process do.

Where to start

If you want to know how exposed you are right now, three questions will tell you most of it:

1. Who can change a vendor's bank account in your environment, and what happens when they do? If the answer is "AP, and it saves," you have found the gap. Bank detail changes should require independent confirmation and should be logged as a distinct, reviewable event, not buried in a general master data change history.

    

2. When was the last time a payment was blocked or esclated because the destination account couldn't be confirmed? If the answer is "never," it is worth checking whether the control exists or whether it has simply never fired.

    

3. Can you produce a list of every payment released in the last quarter to an account that was added or modified within 30 days of release? If that query is hard to run, it is hard to monitor, and that is the population an attacker is trying to hide in.

None of this replaces your approval workflow. The workflow is doing its job. The point is that its job was never to answer the question an attacker is actually exploiting.

At Truvio, this is the problem class our treasury automation work keeps circling back to: not whether the payment was approved, but whether the organization can prove, at the moment of release, in the system of record that the money is going where it is supposed to go.

Approval tells you that the payment was authorized. Validation helps prove you are paying who you intended, where you intended. You need both.

Sources

1. Federal Bureau of Investigation, Internet Crime Complaint Center — 2025 Internet Crime Report (April 2026). https://www.ic3.gov/AnnualReport/Reports/2025_IC3Report.pdf

2. Association for Financial Professionals — 2026 AFP Payments Fraud and Control Survey Report, underwritten by Truist (April 14, 2026). https://www.financialprofessionals.org/training-resources/resources/survey-research-economic-data/details/payments-fraud

    

3. Nacha — Credit-Push Fraud Monitoring Resource Center and 2026 Risk Management Rule amendments (effective March 20 and June 19, 2026). https://www.nacha.org/content/credit-push-fraud-monitoring-resource-center

    

4. Nacha — Business Email Compromise Attempts Rose Sharply in 2025, Report Finds (April 2026). https://www.nacha.org/news/business-email-compromise-attempts-rose-sharply-2025-report-finds

    

5. Federal Bureau of Investigation, Internet Crime Complaint Center — Business Email Compromise guidance on secondary-channel verification of account changes. https://www.ic3.gov/CrimeInfo/BEC

Tina Ash

Product Manager - Solution Architect

With more than 10+ years of experience in the D365 community, Tina leads the banking and treasury product team while designing cutting edge solutions along the way. Her latest project revolves around trust and control, helping customers continue to scale payment operations without scaling risk.