Written Fraud Monitoring Program for Bookkeeping Firms

Phase 1 of the NACHA fraud-monitoring expansion, effective March 2026, applied to larger participants — ODFIs, Third-Party Senders, and Originators above a volume threshold. Phase 2, effective June 22, 2026, removed the threshold. Any Originator sending credit ACH entries is now inside the requirement, whether the firm sends one payment a week or one thousand.

That change matters most for firms that never had a compliance department. A big enterprise AP shop already had a written procedure, a control matrix, and a fraud-monitoring team. A two-person bookkeeping firm running client AP through BILL, Melio, or QuickBooks Bill Pay usually did not. Under Phase 2, both are expected to have a documented program on file. The compliance burden — as sources tracking the rule change have put it plainly — is documentation: verifying vendor and payroll bank-detail changes, and being able to tie each payment back to a real invoice with defensible oversight.

The other important word in the rule is risk-based. NACHA is not asking for line-by-line transaction review on every payment. It is asking you to assess where your firm’s payment fraud risk is highest, apply reasonable controls to those points, and be able to explain your logic in writing.

There is no single mandated template. But if you read the guidance from NACHA, from bank compliance teams, and from AP-fraud practitioners together, the same sections keep appearing. For a small bookkeeping firm running client AP, a workable written program covers:

• Scope. Which clients’ ACH payments you originate, which platforms you use for each, and where the payment leaves the client’s bank (client’s ODFI directly, a Third-Party Sender like BILL, an accountant-of-record model like Ramp).
• Roles. Who at the firm can initiate a payment, who can approve one, and who can update a vendor’s payment details. In a solo or two-person firm, this is short — but the fact that it is short is exactly why it needs to be written.
• Vendor onboarding and change controls. How a new vendor’s bank details are captured, and how a change to an existing vendor’s bank details is verified before you act on it. This section is where the callback lives.
• Payment monitoring. How you review payment activity for anomalies — velocity, dollar thresholds, first-time payees, payments to new banks, unusual timing. What triggers a hold. Who reviews holds and how quickly.
• Incident response. What the firm does when something is caught, when something is missed, and when a client asks whether a fraudulent payment went out. Who calls the bank. Who notifies the client. Who documents what happened.
• Recordkeeping. How long verifications, approvals, and monitoring logs are retained, and where. NACHA’s audit rules generally look for evidence, not just a policy statement — so this section is about producing artifacts, not describing them.
• Annual review. Who reviews the program, when, and how changes are recorded. NACHA expects periodic review.

None of these sections needs to be long. A four- to eight-page document that a bookkeeper can read in twenty minutes and actually follow is more defensible than a thirty-page template no one at the firm has opened.

Across every version of this rule — NACHA’s fraud-monitoring text, cyber insurers’ social-engineering conditions, and the guidance auditors give small firms — the same concrete control keeps surfacing: verify vendor bank-detail changes out of band, using an independently sourced contact, and document that you did.

BEC losses tied to payee-redirect requests were $2.77 billion in 2024 alone, per the FBI Internet Crime Complaint Center report (IC3 2024 Report). The pattern is not exotic: a legitimate-looking email arrives from a vendor announcing new banking details, the firm updates the record, the payment goes out, and the money is gone. The single most reliable control is a phone call to a number the firm already had from an earlier source — not a number in the request itself — followed by a written record of the call. See also the NACHA Phase 2 rule page and our independent-contact rule explainer.

In a written program, this control usually sits inside the vendor-change section and reads roughly:

That paragraph, written down, is the difference between a firm that meets the control and a firm that thinks it does.

The realistic path for a small firm is:

1. Start with the outline above and fill each section with what your firm does today — not what you wish it did. If a control is inconsistent, write that down and add a target date to make it consistent.
2. Attach the artifacts. The program document should reference the templates, checklists, and logs it depends on. Our free vendor bank-change verification template covers the vendor-change section end to end — the independent-contact rule, a callback script, dual-approval step, and the log sheet — and you can link to it directly rather than re-drafting from scratch.
3. Have one person sign it. Someone at the firm — usually the owner in a small shop — puts a date and a signature on the front page. That is not a legal requirement so much as an operational one: it tells you when the current version took effect.
4. Put a review date on the calendar. The rule expects annual review. Put it in the calendar now, with the document owner named. If nothing has changed in a year, the review takes ten minutes and the record shows you did it.
5. Store the evidence, not just the policy. The program document itself is one artifact. The verification logs, approval trails, and monitoring holds that show the program running are the others. NACHA audits — like most audits — care more about the second set than the first.

For firms running AP across multiple clients, the recordkeeping section is where the wheels usually come off. Verification records live in whichever platform touched the payment, edits to a paper log are trivial, and pulling a coherent trail across BILL, QuickBooks Bill Pay, and a client’s bank feed is manual and slow. That is the specific gap CallbackProof is built to fill: an enforced verification checklist with a tamper-evident, SHA-256 hash-chained audit log across all clients, so the record is one place, is dated at the moment of the callback, and cannot be quietly edited later. It does not run monitoring or write your program for you — but it makes the vendor-change control produce the artifact the program needs. See also vendor verification for bookkeeping firms and the compliance checklist for Phase 2.

The Phase 2 rule did not invent a new control. It made the paperwork obligation universal. A small bookkeeping firm that runs client AP is now expected to have a written, risk-based fraud-monitoring program, reviewed at least once a year, with the vendor bank-detail change control clearly documented and evidence that the control is actually being run. Most of that document is describing what a careful firm already does. The part that catches firms out is the evidence side — being able to hand an auditor or a client a coherent record, not just a policy.

If your firm has been running the verifications correctly but the record is scattered across email threads and platform screenshots, that is the immediate gap to close. The program itself can be drafted in an afternoon. The evidence trail is the year-round work.