Mercury vs Relay: Banking for a Fintech or Payments Company

Whatever banking-as-a-service or program bank relationship handles your actual customer funds, that infrastructure is separate from your company's own checking account, and it should stay separate in practice, not just in your mental model. Use Mercury or Relay strictly for company operating cash: payroll, vendor payments, your own runway, and keep any account structure your program bank requires for customer funds entirely outside either platform. Relay's free sub-accounts are a reasonable way to separate your own operating cash into tax, payroll and runway buckets; Mercury's multi-entity account structure suits a fintech running a separate legal entity for its regulated activity against its product and engineering entity.

This separation matters for reasons beyond good hygiene. A due diligence reviewer, an auditor, or a banking partner's own compliance team will ask, sooner or later, to see exactly where company funds stop and program funds start, and a founder who has to reconstruct that boundary after the fact is going to lose real time on a deal or a partnership renewal that a clean structure from day one would have avoided entirely.

Both Mercury and Relay, like most fintech banking products, operate through partner bank relationships, and a company whose own business is regulated financial activity should expect more diligence during onboarding than a typical SaaS company would: source of funds questions, more detailed business descriptions, and closer ongoing monitoring. Neither platform publishes a fast-track process for this, so budget real time, not a same-day account opening, when you're setting up operating banking as a fintech, and have your compliance documentation ready before you apply rather than scrambling once a reviewer asks for it.

Build slack into your fundraising and launch timeline for this specifically. A founder who assumes operating banking will open in an afternoon, the way it might for a plain software company, and plans a payroll run or a vendor payment around that assumption, is the one who ends up explaining a delay to a new hire or a vendor. Start the account opening process as soon as you have a formation document and a real business description ready, well before you need the account funded and working.

Fintech companies that raise larger rounds relative to team size, because regulatory and compliance buildout is expensive before revenue scales, often carry a meaningful operating cash cushion. Federal funds are currently effective at 3.63%¹, a rate Mercury's automated Treasury sweep is built to capture on operating cash sitting above your working buffer, moving it into short duration instruments without anyone logging in to do it by hand. Track your burn multiple, net burn against net new revenue, and keep it under 2x² as a working ceiling even while regulatory buildout keeps headcount cost elevated relative to revenue in the early years; investors evaluating a fintech expect that discipline just as much as they would from a pure software company.

A fintech engineering team is often already building against banking and payments APIs as its core product, which makes Mercury's own developer-facing API a more natural fit operationally: the same team comfortable integrating a program bank's API can just as easily pull the company's own operating balances and transactions programmatically. Relay's QuickBooks and Xero integrations and its options for giving a bookkeeper access matter more for the back office side of a fintech than for the product side, and many fintech companies run a simple operating account for bookkeeping while their actual product integrates with entirely separate banking infrastructure.eparate banking-as-a-service infrastructure.

A fintech's finance stack tends to sprawl faster than a typical software company's: a program bank for customer funds, a card issuing partner, a payments processor, plus the company's own operating bank. Keep a single, current document listing which vendor holds which piece, and which of your own accounts, Mercury or Relay, is the operating account of record for payroll and vendor payments, so a new finance hire or an investor doing diligence isn't piecing that structure together from memory during a data room review. Fintechs that let this map go stale are the ones that struggle most when a banking partner relationship changes and nobody's sure which downstream accounts depend on it.

Keep one current document that records each of the following:

• The program bank or banking-as-a-service partner that holds customer funds, kept entirely outside Mercury and Relay.
• The card issuing partner and the payments processor, along with what each one is responsible for.
• Which of your own accounts, Mercury or Relay, is the operating account of record for payroll and vendor payments.
• The boundary between company operating funds and program funds, so a reviewer or banking partner can see it immediately.