Payment Fraud Isn’t Just Finance’s Problem Anymore

A vendor sends an email to your finance department asking to update their banking information. The email looks legitimate, the request seems routine, and someone makes the change. A few weeks later, you find out the payments have been going to a criminal instead of your vendor.

Finance handled the payment change. IT handled the email security. Both departments were doing their jobs, but somewhere between the two, a control failed.

One of the challenges of being in business, especially now, is how fast we have to pivot. Then there’s the challenge of recognizing when it’s time to take a deeper look at the relationships between departments, because the dynamics have changed.

The days of IT working behind the scenes, keeping everything connected while staying out of sight and out of mind, are gone. Payment fraud is a good place to see why.

How the work used to split

Traditionally, payment changes were finance’s job. IT’s part was basic email security, meaning how mail was set up, Defender and filtering.

That’s how it worked when I was an IT director for a mid-market organization. How fiscal dealt with payment changes was entirely on them and had nothing to do with IT. IT was relied on to keep email clean enough that nobody could slip in the kind of messages we see in business email compromise attacks.

When something slipped through those cracks, the hope was that finance had controls.

A good policy says that when a vendor asks to update their bank details, you don’t reply to the email and you don’t call the number in it. You reach out through the business’s established contact information, ask to speak with an authorized person and independently verify the request before making any changes.

That’s a sound financial control, and it remains one of the most important steps in preventing payment fraud.

Controls in silos

The problem is that controls sitting in separate silos can each work as intended and still leave the business exposed.

IT filters the mail without knowing what finance does with it, and finance verifies the request without knowing what IT saw on the way in.

You may run a layered team with a controller, department accountants and a dedicated AP person, which is exactly what good financial control calls for. That structure still leaves the person approving the payment a few steps away from anyone who’d notice a vendor’s email reads a little off.

Now picture a business without those controls. A normal-looking email that appears to come from one of your vendors asks you to send future ACH payments to a new account, and someone updates the record.

Maybe the person making the change has dealt with this vendor for years. Maybe the email is part of an existing conversation. Maybe the attacker has access to the vendor’s actual mailbox.

IT may see nothing obviously wrong, and finance may have no reason to question the request.

That’s the gap I’m talking about.

Once it’s sent

Once that payment goes out, it’s much harder to pull back than a credit card charge.

For consumer credit cards, the Fair Credit Billing Act, through Regulation Z, provides a billing-error resolution process. Generally, a consumer must send written notice within 60 days after the first statement showing the error. Business card disputes depend on the issuer’s agreement and applicable card network rules rather than those consumer protections.

An ACH credit your business authorized and sent to a fraudster doesn’t carry that same consumer credit-card dispute process.

Your bank can request the funds back, but recovery isn’t guaranteed.

Nacha’s reversal rules are intended for specific processing errors, including duplicate payments, incorrect amounts, incorrect receivers and certain date errors. Reversals generally must reach the receiving bank within five banking days of settlement. Being tricked into authorizing a payment to a criminal isn’t, by itself, one of the permitted reversal reasons.

Wires aren’t any easier. Under UCC 4A-211, once a receiving bank accepts a payment order, cancellation generally requires the bank’s agreement or an applicable funds transfer system rule.

The FBI’s Recovery Asset Team does real work here. In 2025, its Financial Fraud Kill Chain handled 3,900 incidents involving approximately $1.164 billion in attempted theft and helped freeze $679 million, about 58%.

That’s an impressive effort, but frozen isn’t the same as returned, and roughly 42% of those attempted funds weren’t frozen through that process.

If your business discovers a fraudulent transfer, time matters. Contact your bank immediately, request a recall and report the incident to the FBI’s Internet Crime Complaint Center.

What the banks expect

Financial institutions see these attacks regularly, and businesses are increasingly expected to participate in identifying fraudulent transactions.

The numbers explain why.

The FBI’s Internet Crime Complaint Center logged 24,768 business email compromise complaints in 2025, with $3,046,598,558 in reported losses, up from approximately $2.77 billion in 2024.

The ACH network has written additional fraud-monitoring expectations into its rules.

Under Nacha’s fraud monitoring requirements, the second phase of which took effect in June 2026, all non-consumer ACH originators, including businesses sending ACH payments through their banks, must establish risk-based processes reasonably intended to identify transactions that are unauthorized or authorized under what Nacha calls False Pretenses.

Those processes must be reviewed at least annually, and Nacha specifically identifies business email compromise and vendor impersonation among the fraud scenarios the rules address.

The requirements are risk-based. They don’t mandate that every transaction receive an individual manual review, and they don’t prescribe one specific technology or procedure.

Nacha also makes an important distinction. These new monitoring rules don’t change how liability is allocated under UCC Article 4A.

The court in Choice Escrow v. BancorpSouth showed why that’s important.

A small Missouri title and escrow firm lost $440,000 in a fraudulent wire transfer after malware captured an employee’s banking credentials. The bank had offered dual control, requiring a second authorized person to approve transfers, but Choice declined it and signed a waiver.

The Eighth Circuit found the bank’s security procedures commercially reasonable. It also found that the bank acted in good faith and complied with the applicable instructions, leaving the loss with Choice.

That case involved stolen credentials rather than a fraudulent vendor bank-change request, but the lesson is relevant.

Declining a security control can have consequences beyond increasing your exposure to fraud. Depending on the agreements and circumstances, it may also affect who ultimately bears the financial loss.

Where insurance stops

Some cyber liability and commercial crime insurance policies provide coverage for social engineering, fraudulent payment instructions or computer fraud.

The problem is that those coverages aren’t necessarily interchangeable, and they don’t all carry the same limits or conditions.

In policies I’ve reviewed, I’ve seen social engineering coverage limited to around $100,000. That’s not a universal limit, and it’s exactly why businesses need to understand what their own policies actually cover.

So what happens when the ACH payment you sent is bigger than that?

What if you’ve been paying a “vendor” for months, only to find out the real vendor never got the money?

Even determining whether a loss is covered can become complicated.

In Medidata Solutions v. Federal Insurance, employees transferred approximately $4.8 million after receiving emails spoofing a company executive. The insurer disputed coverage, but the Second Circuit upheld coverage under the policy’s computer-fraud provision in 2018.

In Apache v. Great American, an attacker impersonated a vendor requesting a banking change. Apache called the number printed on the fraudulent letterhead, believed it had verified the request and subsequently transferred approximately $7 million before discovering the fraud. Apache later recovered a substantial portion of the funds, but its remaining insurance claim under the computer-fraud provision was unsuccessful in the Fifth Circuit.

Neither case establishes how every social engineering endorsement works. They demonstrate why policy wording, the mechanics of the attack and the actions taken by the business matter.

And there’s another point I think business owners should consider.

If you’re completing an insurance application and answering yes to questions about financial controls, dual authorization or payment verification, you should know exactly why you’re answering yes.

Having a written policy and consistently following it are two different things.

Why IT belongs in the process

If your policy says any change to payment instructions triggers due diligence, and the request came in by email, IT should have a defined role in reviewing that request too.

IT can examine the sender’s domain, authentication results, message headers, message history and other warning signs that might indicate impersonation or compromise.

But there’s an important limitation.

An email passing SPF, DKIM and DMARC authentication doesn’t prove the person who sent it was authorized to change payment instructions.

A criminal using a compromised vendor mailbox may be sending completely authenticated messages.

That’s why IT’s review should support, not replace, finance’s independent verification with the vendor through an established contact.

Both checks should be documented, along with who approved the change and when.

We don’t do this by gut feeling.

IT can carry more of this load in a few other ways.

• Your own domain gets protected against spoofing. DMARC enforcement helps receiving mail systems identify messages falsely claiming to come from your business’s domain. Inbound filtering can also evaluate the authentication policies of outside senders. Red Sift’s December 2025 analysis of 73.3 million domains found that only 2.5% enforced the strictest reject policy, while 83.9% had no visible DMARC record. DMARC matters, but it doesn’t prevent an attacker from using a legitimately registered lookalike domain or a compromised mailbox.
• Lookalike domains get flagged before AP acts on them. Microsoft Defender for Office 365 includes impersonation protection that can identify senders and domains resembling trusted contacts. Microsoft specifically warns that a lookalike domain can pass SPF, DKIM and DMARC because the criminal controls that domain. The FBI also recommends identifying email from outside the organization with an external sender banner.
• Compromised mailboxes can be caught earlier. The FBI has documented attackers creating forwarding rules inside compromised mailboxes to watch payment conversations and redirect future transactions. IT can monitor suspicious mailbox rule changes, alert on abnormal sign-ins and restrict automatic forwarding to external addresses. Those controls can help interrupt an attack before the next payment goes out.
• A stolen password stops being enough. CISA recommends phishing-resistant multifactor authentication because traditional passwords and weaker MFA methods can still be defeated through phishing. Properly implemented phishing-resistant MFA makes it significantly harder for a criminal to take over a mailbox using credentials stolen through a fake sign-in page.
• An investigation has something to work with. The FBI recommends retaining mailbox sign-in and settings-change logs for at least 90 days. Microsoft’s default Audit (Standard) retention is now 180 days for supported records, although actual availability depends on licensing, configuration and the events being logged. When a payment goes wrong, those records help reconstruct what happened, identify compromised accounts and understand whether other payment conversations may have been affected.

None of these controls replaces a properly managed finance department.

And no amount of email filtering makes a business immune to fraud.

The point is that IT has information and capabilities that finance doesn’t, while finance understands the payment relationships, approval authority and business context that IT doesn’t.

When those departments work together, you have a much better opportunity to identify a problem before the money leaves.

What you walk away with

What I offer is a payment-focused IT assessment that reaches into your finance process.

It’s scoped to the controls that follow the money, from the email that arrives to the payment that leaves, and it rests on your business impact analysis and risk assessment, or on a snapshot we build together when those don’t exist yet.

I’m looking at where the technical controls and financial procedures meet, whether the responsibilities are clear, and whether the business has evidence that those controls are actually being followed.

You come out knowing where IT is covering you, where finance is covering you and where neither one is.

One boundary worth stating. I assess controls, and I don’t interpret insurance policies, advise on coverage or predict whether a claim gets paid. Nothing here is legal advice, and those calls belong to your broker, your carrier and your attorney.

The days of IT and finance working independently on something as important as payment security need to be behind us.

You can have good people, good policies and good technology and still have a gap between them. The time to find that gap is before someone sends the money.

If you want to know whether your payment controls would hold up the day that email lands, let’s talk.

If you want a second set of eyes on how your business verifies payment changes, that is what the Payment Integrity & BEC Controls Review is for.

Sources

• Nacha, Risk Management Topics (Fraud Monitoring Phase 2) (https://www.nacha.org/rules/risk-management-topics-fraud-monitoring-phase-2)
• Nacha, Risk Management Topics, October 1, 2024 (https://www.nacha.org/rules/risk-management-topics-october-1-2024)
• Nacha, Reversals and Enforcement (https://www.nacha.org/rules/reversals-and-enforcement)
• Consumer Financial Protection Bureau, Regulation Z, 12 CFR 1026.13, Billing Error Resolution (https://www.consumerfinance.gov/rules-policy/regulations/1026/13/)
• Uniform Commercial Code 4A-211, Cancellation and Amendment of Payment Order (https://www.law.cornell.edu/ucc/4A/4A-211)
• FBI Internet Crime Complaint Center, 2025 Internet Crime Report (https://www.ic3.gov/AnnualReport/Reports/2025_IC3Report.pdf)
• FBI, Cyber Criminals Conduct Business Email Compromise through Exploitation of Cloud Based Email Services, July 2020 (https://www.ic3.gov/CSA/2020/200707-4.pdf)
• FBI, Cyber Criminals Exploit Email Rule Vulnerability to Increase the Likelihood of Business Email Compromise, December 2020 (https://www.ic3.gov/CSA/2020/201204.pdf)
• CISA, More than a Password (https://www.cisa.gov/MFA)
• Microsoft Learn, Anti-phishing Policies in Microsoft 365 (https://learn.microsoft.com/en-us/defender-office-365/anti-phishing-policies-about)
• Microsoft Learn, Manage Audit Log Retention Policies (https://learn.microsoft.com/en-us/purview/audit-log-retention-policies)
• Red Sift, Guide to Global DMARC Adoption (https://redsift.com/guides/red-sifts-guide-to-global-dmarc-adoption)
• Choice Escrow & Land Title, LLC v. BancorpSouth Bank, 754 F.3d 611 (8th Cir. 2014) (https://www.govinfo.gov/content/pkg/USCOURTS-ca8-13-01879/pdf/USCOURTS-ca8-13-01879-0.pdf)
• Medidata Solutions, Inc. v. Federal Insurance Co. (2d Cir. July 6, 2018) (https://www.insurancejournal.com/app/uploads/2018/07/Medidata-v-Federal-Insurance.pdf)
• Apache Corp. v. Great American Insurance Co., 662 F. App’x 252 (5th Cir. 2016) (https://caselaw.findlaw.com/court/us-5th-circuit/1751539.html)