Does Melio Verify Vendor Bank Account Changes?

Melio’s bank verification has two flavors, both narrowly scoped.

Micro-deposit verification. Plaid (Melio’s bank-link partner) or Melio itself sends two small deposits (each under $1) to the bank account. The account holder reads the amounts off the bank statement, enters them in Melio, and the account is marked verified. The deposits are debited back a few days later. This is the same penny-test pattern used by Bill.com and QuickBooks Bill Pay; the question it answers is narrow: does this account number plus routing number exist, and can it accept an ACH credit? (Melio Help Center: Verifying your bank account with micro-deposits).

Melio “verified vendor” status. Once a vendor confirms their business and bank details with Melio’s risk and compliance team, the payment delivery method on that vendor is locked: only the vendor can change it from their own Melio login, not the business paying them (Melio Help Center: Becoming a Melio verified vendor). That is more restrictive than BILL or QuickBooks Bill Pay, and it does close one specific attack path: a stranger walking into your Melio dashboard and silently rewriting a verified vendor’s account.

Both checks are useful. Neither answers the question that matters for payment-diversion fraud: who sent the change request, and is it really the vendor?

Business email compromise — the “our bank has changed, please update before the next invoice” email — is the dominant way firms lose client money. The FBI Internet Crime Complaint Center reported $2.77 billion in BEC losses in 2024, with a large share traced to exactly this vendor-bank swap (FBI 2024 Internet Crime Report). The attack is patient — the criminal has often been reading a real mailbox for weeks, mirrors the vendor’s branding, and times the request around a real payment cycle.

Walk it through Melio:

1. You receive an email that looks like it came from a vendor, asking you to update their bank account before the next payment.
2. If the vendor was already “verified” in Melio, the email tells you to log into Melio and request a change, or to add a brand-new vendor with the same business name and the new account.
3. If the vendor was not a Melio-verified one — most small-business vendors are not — you (the business or the bookkeeper) can edit the bank details directly. Melio fires micro-deposits to the new account, the deposits clear (the fraudster’s account is real), and the next ACH posts to the criminal.

The micro-deposit did its job. Validity was confirmed. Validity was just never the question.

The “verified vendor” lock helps when an attacker is trying to change a verified vendor’s account from your side of Melio — they can’t. But the attacker’s playbook adapts. They send the same email asking you to mark the old vendor as inactive and add a “new vendor” record with the same name and the fraudulent account, or they ask you to switch the payment method to check and re-mail to a different address, or they target a vendor that was never verified in the first place. The dashboard ends up looking clean. The control that catches this is not inside Melio.

Melio’s own security guidance is direct: if you get an unusual email or text asking to transfer funds or change payment details, confirm the message actually came from the sender — by another channel — before you act (Melio: How to protect your SMB). That control has a name: an out-of-band callback. You call the vendor on a number from a prior invoice, a signed engagement letter, or your vendor file — not the number, link, or reply address attached to the change request — and you confirm the new account details verbally before you update Melio.

Two more pieces make the control hold up under an audit or insurance claim:

• Maker–checker (dual control). The person who entered the new bank details in Melio is not the one who approves the change. Melio’s accountant role permissions support this — the platform gives you six permission levels and a per-client audit trail precisely so you can separate entry from approval (Melio: Team management for accountants). Most cyber insurers ask whether you do this after an incident.
• A documented audit trail outside the platform. Record who you called, the number you dialed and where that number came from, what was confirmed on the call, who approved it, and when. Save the entry against the vendor — and the client — so an auditor or insurer can see the verification happened before the change.

None of those three pieces — the out-of-band callback, the dual-control approval, the verification log — live inside Melio’s verification flow. The platform handles the payment plumbing. The verification-and-documentation layer is something you add on top of it.

Melio is heavily used by bookkeeping and accounting firms because it has no per-client subscription fee, supports a single dashboard across many clients, and offers an accountant-firm role structure. That same surface area is also why a firm’s exposure compounds: every client’s vendor list is a separate landing zone for “we changed banks” emails, and the firm is the party that has to prove the verification was done if a payment goes wrong on any of them.

NACHA’s Phase 2 ACH risk-management rule takes effect Monday, June 22, 2026, and it applies to every business that originates ACH payments — no volume floor, including ACH initiated through Melio. The rule requires each ACH originator to implement a risk-based process to detect fraud (read: a documented vendor verification routine) and, in particular, to verify vendor bank-account changes received outside the closed payment platform. A bookkeeping firm that pays clients’ vendors through Melio is squarely in scope.

Two practical patterns help:

1. Treat every payment-detail change as unverified until someone has called the vendor back on a known number, gotten a second person’s approval, and logged it. Then — and only then — update Melio (or add the new vendor record, or switch delivery method). No log, no change.
2. Standardize the same procedure across every client. What auditors, ODFIs, and insurers look for is consistency: the same verification step, the same documentation, across all vendors and all clients. Ad-hoc Slack messages, post-its, or “we usually call” don’t survive a claims review.

If you want a ready-made version of that procedure, our free vendor bank-change verification template lays out the independent-contact rule, a word-for-word callback script, a dual-approval step, and a one-page log sheet — no signup, nothing to buy. For the full mechanics see how to verify a vendor bank account change. For the NACHA Phase 2 specifics for firms running client AP, see NACHA Phase 2: vendor verification for bookkeeping firms. And for the audit angle, what auditors ask about vendor verification covers the artifacts a reviewer will actually ask you to produce.

CallbackProof exists to make this routine across every client on Melio: it enforces the callback-and-approval sequence and keeps a tamper-evident, hash-chained log you can hand to an auditor, ODFI, or insurer. It is a documentation and workflow tool — it does not replace Melio and does not move money; it records that the change was verified before it was made.

Melio’s micro-deposits confirm a vendor’s bank account is valid and can receive ACH. Melio’s “verified vendor” status further locks a verified vendor’s payment method against changes from your side. Neither confirms that a bank-change request is legitimate — and Melio itself tells you to verify unusual payment-detail requests through another channel before acting. The control that actually catches payment-diversion fraud is an out-of-band callback to a known number, with dual approval and a documented record, performed before you make any change in Melio. Under NACHA Phase 2, that documentation isn’t optional anymore.