Does Brex Verify Vendor Bank Account Changes?

Brex’s verification picture has three pieces, each doing a narrow job.

Vendor self-onboarding via secure link. Brex bill pay lets you send the vendor a secure link where they enter their own payee details, including account and routing numbers, instead of the bookkeeper typing them from an emailed PDF (Brex: Bill pay). That removes one class of error — a bookkeeper mistyping the numbers — and it puts the sensitive data on Brex’s form rather than in email. It does not verify who is on the other end of that link. If a criminal has already compromised the vendor’s email, they receive the secure link and enter their own bank details on the vendor’s behalf.

Micro-deposit and penny check on funding accounts. Brex uses two related verifications for external bank accounts: a micro-deposit to prove access to a funding account, and a penny pull to confirm Brex can debit that account (Brex: Bill pay). These are aimed at the funding side — the client’s own account that pays the bill — not at the vendor’s receiving account. Either way, the question they answer is narrow: does this account number plus routing number exist, and can it move money? Both answers are yes even when the account belongs to a criminal, because criminals open real bank accounts.

Multi-level payment approvals. Brex’s spend platform routes bill payments through customizable approval chains — approver by amount, vendor, department, or category — and the drafter role in Pro Access is explicitly prevented from approving payments they submit (Brex: Pro Access). Segregation of duties matters and is a real control. But every person in that approval chain is looking at the same vendor record on the same screen. If the underlying bank detail is wrong because the vendor’s email was hijacked upstream, three approvers clicking Approve does not change the answer — it just adds three names to the audit trail of the wrong decision.

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 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 usually been reading a real mailbox for weeks, mirrors the vendor’s tone and timing, and sometimes controls the vendor’s own onboarding link.

Walk it through Brex:

1. An email that looks like it came from the vendor arrives in your or your client’s inbox asking you to update their payment details before the next bill.
2. You resend the vendor onboarding link, or the impostor uses the link the real vendor forwarded them, and enters new routing and account numbers on Brex’s secure form.
3. Brex validates the account via micro-deposit or penny check. It clears — the criminal opened a real bank account in the vendor’s name and can see the small credits.
4. The bill lands in the approval queue. Two or three approvers see a normal-looking vendor with a normal-looking bank field and click Approve.
5. Brex sends the payment on schedule. Nothing in Brex’s flow required anyone on your side to call the vendor at a number pulled from a prior invoice and confirm the change before that first click.

Every Brex control did what it was designed to do. Brex 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 an independently sourced number.

When an auditor, a cyber insurer’s forensic accountant, or a client asks how you confirmed the vendor’s new bank details were real, “the payment was Approved twice in Brex” is not the answer they need. They will ask three questions in a row:

1. Who did you call to confirm the change, and what number did you dial?
2. How did you get that number — from the change request itself, or from a prior invoice or a separately verified source?
3. Where is the record?

Brex will show them approver names, timestamps, and the sync history to your ledger. It cannot show them that you dialed the vendor on a number from the March invoice, spoke to the AR clerk you have talked to before, read the last four of the new routing and account number back, and heard her confirm each digit. That is the piece cyber insurers reference in social-engineering coverage conditions, that state bar audits ask small-firm bookkeepers to produce for law-firm clients, and that NACHA Phase 2’s fraud-monitoring rule now expects every ACH originator to have written into a program. If it lives only in a Slack DM or a memory, it does not exist for the auditor. See our cyber-insurance callback requirement explainer for how coverage conditions have tightened.

The reason firms end up with a documentation gap is not that Brex is lax. It is that Brex answers “was this payment approved?” and the question the outside reviewer is asking is “was this change authenticated?” Different questions, different artifacts.

The independent control that regulators, insurers, and auditors keep converging on is the same: an out-of-band callback on a number the vendor did not supply, done by a specific person, on a specific date, with the answers written down. In practice, for a firm running client AP inside Brex, the added routine is short:

• Before you send the onboarding link — or approve a Brex-side edit — dial the vendor’s AR contact at a number from a prior invoice, a signed engagement letter, or the vendor’s official published contact. Never the number in the change-request email.
• Confirm three specific things on that call: the change is real; the last four digits of the new routing and account number match what was just entered; and the person on the phone is a name you have transacted with before.
• Log the call the same day. Vendor name, client, date, time, phone number dialed, source of that number, who you spoke to, what they confirmed, and the bookkeeper who did it. Store it where you can find it a year later without paging Brex support — and where all of your other clients’ verifications live too, whether they run on BILL, Ramp, QuickBooks Bill Pay, Melio, or paper checks. That single archive is what makes an insurance claim or an auditor’s confirmation request answerable.

If you want a policy template that already contains this language, our free vendor bank-change verification template is a one-page document you can co-brand and drop into a client-services binder. It is not a Brex-specific tool — the point is that the same procedure has to work across every platform you and your clients use, because the FBI does not care which one the money left through.

Brex’s Pro Access model is genuinely well built for the multi-client bookkeeping firm — a single login across many clients, role separation between bill-pay drafters and approvers, and syncs into QuickBooks and Xero. If your firm has adopted Brex bill pay because switching between client logins was killing your afternoons, keep using it.

The point of this article is narrower: Brex’s vendor-onboarding flow verifies that the account is a real account, and its approval chain verifies that the payment was signed off inside your firm. Neither of those steps proves that the change request was authored by the real vendor. That last step is the one the FBI, most cyber insurers, and — as of June 22, 2026 — NACHA’s Phase 2 rule all treat as the payer’s responsibility. For the shape of a written program that satisfies Phase 2 across every client, see our NACHA Phase 2 compliance checklist for bookkeeping firms.

For the small bookkeeping firm running client AP in Brex, closing the gap is not about buying a second platform. It is about writing the out-of-band-callback step into the firm’s procedure, doing it on every bank-change request without exception, and keeping the log somewhere audit-durable. Our vendor bank-change callback script is the exact wording most firms adopt for that call, and our vendor-verification routine for bookkeeping firms running client AP walks through the cross-platform fix.