Spend the fraud budget where it can still stop a payment, not after it's too late

Put the AI/BEC security budget into controls that can actually stop or hold a payment decision before money settles: vendor bank account changes, executive payment instructions, help desk password resets tied to payment authority, and the release of payment files. Every dollar spent should buy one of four things: a named owner for the decision, a mapped-out payment path, evidence that doesn't come from the same channel making the request, and the ability to hold a transaction when something looks off.

Here's the test: if you can't point to a specific wire it would have stopped, it's not a fraud control. It's a cyber program wearing a fraud control's name tag.

The board packet will not lack numbers. In May, the share of organizations planning to increase security spending rose to 85%, up from 64% in the year from March 2025 to February 2026, according to PYMNTS coverage of an IBM release. IBM attributed the increase to organizations becoming aware of advanced frontier AI cyber capabilities.

AI-enabled attacks accounted for about 25% of malicious breaches during that period, and most of those attacks involved either deepfake impersonation or AI-enabled malware, according to the same PYMNTS report. That may justify a larger security request. It still leaves the controller with a narrower question: which payment must be stopped before cash leaves.

The AI BEC security budget has to start with the loss decision

Focus on the payment decision that can be made wrong and still look authorized.

For a CFO, that means naming the loss path in finance language. A vendor account is changed. An executive instruction is accepted outside the normal path. A help desk ticket changes access for a payment approver. A payment file is released with clean system logs but bad underlying evidence.

Each path has a different owner. Vendor master may sit in AP. Release authority may sit in treasury. Identity reset may sit in IT, but the risk lands in finance when the user can approve or transmit funds. New security money should change who can hold the transaction and what proof is required before settlement.

Federal pressure is aimed at crime groups and networks

The White House action and the ransomware advisory explain why boards feel pressure to show movement. Payment approval evidence still has to be set inside finance.

President Trump directed federal law enforcement to create a new program that partners with the private sector to target transnational criminal organizations responsible for ransomware attacks, phishing campaigns, and other cybercrimes, according to ABA Banking Journal’s account of the White House summary. The White House also said U.S. consumers reported losing more than $20.8 billion to cyber-related crime last year.

CISA’s Gunra ransomware advisory points defenders toward patching known exploited vulnerabilities in internet-facing systems, implementing and testing offline immutable backups, and segmenting networks to restrict lateral movement. It lists roles such as cybersecurity architects, defensive cybersecurity analysts, vulnerability analysts, systems administrators, and security systems managers.

Those are network controls. They can preserve operations after an intrusion and make lateral movement harder. But the AP manager still needs a different answer at the point of decision: whether a beneficiary change is valid, whether an urgent instruction belongs in the normal workflow, and whether a payment file should leave the bank portal.

Payment paths need evidence before release

Finance should write the evidence standard into the workflow. A training slide will not hold a wire.

• Vendor bank account change. The AP manager or vendor master owner should require a callback to a previously approved vendor contact. Keep bank account support with the change record. Place a hold when the request arrives through a new email thread.
• Executive payment instruction. Treasury should require approval inside the normal payment workflow, not a forwarded message. The second approver needs to see the invoice, beneficiary, and business purpose before release.
• Help desk ticket tied to payment access. The identity administrator should not reset a password, MFA method, device enrollment, or approver role until the finance application owner confirms the payment authority affected by the change.
• Payment file release. Treasury operations should match the file total, beneficiary count, release account, and approver identity to the approved batch. If the batch was rebuilt, the match starts again.

These checks do not require finance to predict the next attack method. They require finance to decide which records must exist before the bank receives an instruction. That is the difference between buying coverage for a threat category and changing the control that sits in front of cash.

Clean system logs are not proof of a clean payment

System logs can show that the right user clicked the right button. The control record also needs proof that the instruction, beneficiary, and bank account were legitimate.

A fake executive instruction demands a workflow approval tied to business purpose and beneficiary. The login record cannot carry the proof alone. A poisoned help desk ticket demands approval from the finance role owner because the reset affects payment authority.

The PYMNTS report’s reference to deepfake impersonation matters here because impersonation attacks often target the human decision around the system, not the system field alone. The CISA advisory’s focus on exposed infrastructure matters too, because a compromised environment can create clean-looking activity in places finance trusts. Treat logs as one piece of the evidence package.

Finance owns the hold, security owns the signal

The clean operating model is shared, but the hold must have a named finance owner. Security can supply the signal; finance has to own the payment consequence.

• Ask security for payment-user signals. Include account takeover indicators, suspicious device changes, risky remote access, malware findings, and identity events affecting users who can approve, change, or transmit payments.
• Tell AP and treasury which work must stop. Name the vendor changes, batches, urgent payment requests, and approver resets that go on hold when those signals appear.
• Put the hold inside the workflow. The system owner should make the stop enforceable in the payment or vendor master process, so the control does not depend on a chat message or an email warning.
• Test the record before settlement. Audit or risk should look for evidence that existed before release, not a later explanation that the exception was discussed.

The finance test is narrow. Before the next approval, ask for a control map that names the protected payments, the owner who can stop them, and the evidence that must exist before release. If that map does not exist, the new money may improve security while the same payment decision remains exposed.