Does Ramp Verify Vendor Bank Account Changes?

Ramp’s verification has three useful pieces, each narrowly scoped.

Micro-deposit debit check. When a bank account is added manually, Ramp sends two small deposits under $1 and one offsetting withdrawal to confirm the routing and account number resolve to a real, debitable account. The customer enters the deposit amounts to complete verification (Ramp: Bank account confirmation). This is the same penny-test pattern Bill.com, QuickBooks Bill Pay, and Melio use. The question it answers is narrow: does this account number plus routing number exist, and can it move money?

Plaid-linked accounts. Vendors can connect a bank account through Plaid instead, which uses the bank’s own credentials to import account details. Stronger than a manual entry, but it still verifies the account, not the identity of whoever asked you to swap to it.

Vendor Portal payer-approval banner. When a vendor with a Ramp Vendor Portal updates their bank details, Ramp shows a banner on the vendor profile telling the payer the vendor has changed their account, and requires the payer to open the profile and click Approve before any future payment is redirected (Ramp: Vendor management on Ramp). This is the most important control in the set, and it is genuinely useful — but the approval click sits with whoever is logged in to Ramp. It does not require that person to call the vendor on a number from a prior invoice and confirm the change before clicking.

Each of these closes a real attack path. None of them closes the path criminals actually use.

Business email compromise — the “our bank has changed, please update before the next invoice” email or vendor-portal message — 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 this exact vendor-bank swap (FBI 2024 Internet Crime Report). The attacker has often been reading a real mailbox for weeks, mirrors the vendor’s tone and timing, and sometimes already controls the Vendor Portal login.

Walk it through Ramp:

1. An email that looks like it came from the vendor arrives in your or your client’s inbox asking you to update their bank account before the next payment.
2. You log in to Ramp and edit the vendor’s account, or the impostor logs in to the Vendor Portal as the vendor and changes it themselves.
3. Ramp runs the micro-deposit debit check on the new account. It clears — because the criminal opened a real bank account in the vendor’s name and can read the deposits.
4. If the change came from the Vendor Portal, Ramp shows you the payer-approval banner. You see “Vendor updated their bank account” and a button.
5. You click Approve, because you already believed the email. There is nothing on that screen that forces you to dial the vendor first.

Every Ramp control did exactly what it was designed to do. The platform never claimed to authenticate the change request itself, and from its position it cannot — only a human on your side can hear the vendor’s voice on a number from a prior invoice.

Even when the bookkeeper does the right thing — pauses, calls the vendor on a known-good number, confirms it was really them — clicking Approve in Ramp records that the approval happened, not what the bookkeeper did to earn it. The audit trail says “User X approved this update on Date Y.” It does not say:

• Who was called, on what number, sourced from where (a prior invoice scan, the master file, not the email signature)
• What the vendor confirmed: full account number, routing number, the timing of the change, whether anyone else at the vendor was authorized to request it
• Who at the vendor answered, and whether you reached them directly or were transferred
• Whether the request was refused, what the red flags were, and what was sent back to the client

That gap is what fails an engagement audit, a SOC 1 confirmation, and a cyber-insurance funds-transfer-fraud claim. Insurers have increasingly tied coverage to whether the policyholder followed a documented out-of-band callback procedure for the specific change in question. “We approved it in Ramp” is not the artifact they ask for; “here is the call log, the number we dialed, the prior-invoice scan it came from, and the bookkeeper who signed it” is.

Ramp Stack, launched June 3, 2026 as an AI operating system built for accounting firms, makes this gap more acute, not less. Stack covers reconciliations, journal entries, depreciation, and close work across many client books — but Ramp’s vendor-verification controls only see vendors and changes inside Ramp. A bookkeeping firm partnering with Ramp (Ramp now lists more than 4,500 firm partners) typically does not pay every client’s bills from inside Ramp. The same firm runs other clients on Bill.com, QuickBooks Bill Pay, Melio, ACH from a client bank login, wire, or a IOLTA/trust account — each with its own verification flow, its own approval log, its own audit trail.

When the engagement auditor or insurer asks “show me how you verified the last six vendor bank-account changes across your book of clients,” the firm has to pull screenshots from four platforms, none of which prove a callback happened. Our vendor-verification routine for bookkeeping firms running client AP walks through the cross-platform fix in detail.

Don’t turn off Ramp’s controls — they’re the strongest of the SMB AP set. Layer on the human callback artifact they don’t produce:

1. Treat the Vendor Portal approval banner as a stop, not a checkbox. When it appears, do not click Approve until someone on your side has called the vendor on a number from a prior invoice and confirmed the change. Our callback script for bookkeepers gives you the exact words.
2. Use the verification policy your client signs. Our free vendor bank-change verification procedure template is the artifact that satisfies the auditor and insurer questions Ramp’s approval log cannot.
3. Document one log across every platform. A hashed, append-only callback log — covering Ramp, Bill.com, QuickBooks Bill Pay, Melio, ACH-from-bank, and trust account changes — gives one record you can hand to an auditor in five minutes. That is what CallbackProof is built to maintain.
4. Confirm before NACHA Phase 2 enforcement bites. The rule has been in effect since Monday June 22, 2026; every ACH originator, with no volume floor, is now expected to apply commercially reasonable risk management to vendor bank-account changes. See our NACHA Phase 2 explainer for small firms.

This is not legal, insurance, or compliance advice. It is what bookkeeping firms running client AP have started doing as platforms, auditors, and insurers all converge on the same question.