NACHA Phase 2: Vendor Verification for Bookkeeping Firms

Phase 1 of the Risk Management Topics — Fraud Monitoring rule hit large originators (6M+ transactions per year) on March 20, 2026. Phase 2 removes the volume threshold entirely. Whether you originate 6 million ACH credits a year or six, on June 22 you take on the same set of duties: establish and implement risk-based processes and procedures reasonably intended to identify ACH credits originated due to fraud.

Three obligations sit underneath that sentence:

• A risk-based fraud-monitoring process. Written. Tailored to the size and risk profile of your originations. Not “we'll figure it out if something looks weird.”
• Verification of payment information before originating an ACH credit. Explicit guidance focuses on first-time recipients and — the part that lands hardest on bookkeeping firms — changes to existing vendor bank details.
• An auditable trail. Procedures, verification records, vendor-change logs, and approval-workflow records that you can hand to your ODFI, an auditor, or an insurer.

JPMorgan's treasury guide on the 2026 rule changes states it bluntly: “compliance is your responsibility as the Originator and cannot be fully outsourced to your bank.” Your bank can decline a payment that looks wrong. It cannot keep your records for you.

If your firm runs AP for clients entirely inside a closed platform like Ramp or Bill.com, those platforms now publish their own NACHA-aligned controls — vendor-verification flags, fraud-signal scoring, audit log exports. You still own the procedure, but the platform produces a lot of the evidence.

The harder case — and the case most small bookkeeping firms actually live in — is when clients pay vendors outside those platforms: wire transfers, ACH initiated through the client's own bank portal, QuickBooks Bill Pay, IOLTA/trust disbursements. In those flows, there is no embedded vendor-verification engine. Nothing is logging the callback you made before changing a vendor's routing number. After June 22, the absence of that log is a finding waiting to happen.

A 2025 Association for Financial Professionals survey reported that 80% of organizations were targeted by payments fraud activity, and business email compromise — the exact attack vector NACHA Phase 2 targets at the vendor-bank-change step — was the most common method. The rule is responding to a fraud pattern that is already well documented; it is not theoretical.

You do not need a new platform to comply. You need a written procedure, applied consistently, with an evidence trail. The control set most ICP firms can adopt without changing their core tools:

• Independent-contact callback on every vendor bank-detail change. Call the vendor back on a number from a source you already had — a prior signed contract, an earlier invoice, your vendor master file — never the number in the change request itself.
• A two-person sign-off. One person initiates the change in the system; a second person confirms the callback was made and approves the change. In a two-person firm, this is still possible — see vendor verification for bookkeeping firms running client AP for the practical setup.
• A vendor-change log entry per event. Date and time of the callback; who you spoke to and their role; the number you called and where it came from; what you confirmed in their words; the second-approver name; the resulting payment ID once it ran. Date-stamped and tamper-evident — a back-datable spreadsheet is weak evidence in an examination.
• A written firm-wide procedure. Two to three pages. Names the rule, defines “out-of-band callback,” lists the log fields, and describes the no-log-no-payment escalation path. This is the document an examiner asks for first.

If you want a ready-made version, our free vendor bank-change verification template covers all of this — the independent-contact rule, a word-for-word callback script, the dual-approval step, and the log sheet — with no signup.

Walk this list before Friday, June 19, so Monday June 22 is uneventful:

• Pull every client engagement letter and confirm it allows you to apply your firm's vendor verification procedure (callback, dual approval, log retention). Most do implicitly under “perform accounts payable services in accordance with reasonable professional standards.” If yours is silent, add one sentence.
• Reach out to your ODFI / treasury contact at each client's bank. Ask what their post-Phase 2 expectation is for documented vendor verification on ACH credit origination, and whether they want a copy of your firm's written procedure on file. Some banks are sending checklists; some are quiet. Both answers matter.
• Audit your last 90 days of vendor bank-detail changes across all clients. For each, confirm there is a callback record (who, when, number called, source of number). Where there is none, do a make-good entry now while the facts are fresh — a paper trail that starts on June 22 with nothing behind it is a red flag in itself.
• Brief every team member who initiates payments. The single biggest reason callbacks get skipped is urgency in the moment — the wire feels “ready to go” and a phone call feels like friction. Make “no log, no payment” a written rule.
• Pick where the log lives. A shared spreadsheet is the floor; a tool that time-stamps and hash-chains entries is harder for a future bad actor (internal or external) to backdate. What auditors ask about vendor verification walks through the artifacts examiners expect.

CallbackProof is a documentation and workflow tool. It enforces the callback-and-approval sequence at the moment a vendor bank-detail change is requested, captures the log entry in a standard shape across every client, and writes each entry into a SHA-256 hash-chained audit log so the records cannot be silently edited or back-dated after the fact. When your ODFI, an auditor, or an insurer asks for the verification trail Phase 2 expects, you hand them the export instead of trying to reconstruct it.

It does not stop a bad actor from sending a convincing email and it does not absolve you of judgment in the callback itself. It makes the verification you performed provable — which is the part of the rule that is hardest to produce after the fact.