The questions CFOs ask that payment teams can't always answer
When an embedded finance program lands in a CFO's budget review, the questions are not about BaaS providers or interchange rates. They are about unit economics: what does each transaction generate in revenue, what does it cost to process, what is the margin profile, and when does the architecture investment pay back?
Payment teams — who think in basis points, STP rates, and rail mix — frequently struggle to answer these questions in the language CFOs use. This creates a translation problem that slows down investment approvals and leaves embedded finance programs under-resourced relative to their revenue potential. This post is the translation guide.
Revenue per transaction — the right way to model it
The most common CFO question: "What do we earn per payment?" The honest answer is that it depends on the rail, the program model, and whether the economics have been designed deliberately or accepted by default.
A well-structured AP program with a commercial purchasing card BIN and a direct bank relationship generates: VCard payments at 175–250 bps of transaction value, monetized ACH at $0.50–$3.00 per transaction, speed premium fees at $1–$15 per eligible transaction, and float yield of 3–5% annualized on average daily balance. Blended across a typical payment mix, this produces 80–120 basis points of effective take rate.
A program on BaaS with a consumer BIN and standard ACH generates: VCard payments at 50–90 bps after middleware share, standard ACH at $0 monetization, and zero float yield. Blended take rate: 15–30 basis points.
The revenue per transaction difference between these two programs, at $10M monthly volume, is $480K–$864K annually. The CFO model needs to reflect the specific program structure being built — not a generic "payments revenue" assumption.
Cost per transaction — what actually belongs in the model
Payment program costs fall into three categories that CFOs need to see separately:
Transaction costs — what it costs to process each payment. Processing fees (0.2–0.5% + $0.05–$0.20 for interchange-plus programs), network assessments (0.08–0.14% of card volume), card issuance costs for VCard programs ($0.10–$0.50 per card issued). At scale these are predictable and directly proportional to volume.
Compliance costs — the fixed operational overhead of running a compliant program. BSA officer ($150K–$250K salary equivalent), compliance analysts ($80K–$150K each), annual independent BSA audit ($30K–$80K), bank exam support (internal time). These are largely fixed relative to volume — they don't scale proportionally with payment volume, which means the margin on incremental volume is higher than the margin on baseline volume.
Infrastructure costs — ledgering platform, card processor, reconciliation tooling. Typically $50K–$200K annually at mid-scale. These scale slowly with volume and often have step function increases at volume thresholds.
The margin profile — why it's better than SaaS margins
Captured interchange and float yield have near-zero incremental cost of revenue. A $1M increase in interchange revenue from volume growth requires no additional headcount, no additional infrastructure, and no additional compliance cost — assuming the program is already staffed for its volume tier. The incremental gross margin on transaction revenue is 85–95%.
For comparison: SaaS subscription revenue typically carries 70–80% gross margin (after customer success, support, and infrastructure costs). A CFO who understands the margin profile of payment revenue should value it higher per dollar than subscription revenue — not equal to it.
The practical implication for budget discussions: the compliance cost investment ($250K–$600K annually for a direct bank program) is a fixed overhead that unlocks a margin structure better than the core SaaS business. At $5M monthly volume generating $480K annually in net payment revenue, the compliance cost is 50–125% of revenue — which looks bad. At $20M monthly generating $1.92M annually, the compliance cost is 13–31% of revenue — which looks excellent. The argument for the compliance investment is the scale story, not the launch economics.
Payback period — the number that unlocks the investment
The CFO question that determines whether the embedded finance investment gets approved: when does it pay back? The payback model for a direct bank program from a BaaS starting point:
Investment: architecture and design ($50K–$120K), compliance program build ($80K–$200K), integration build ($150K–$400K). Total one-time investment: $280K–$720K. Timeline to revenue: 10–18 months.
Annual economics improvement (BaaS to direct at $5M monthly): $300K–$700K. Payback period: 12–24 months from investment commitment, 3–12 months from program launch.
For programs building from scratch rather than migrating: the comparison is against the BaaS path, which launches 6–9 months earlier but generates $300K–$700K less annually from the point of launch. A 12-month payback on the incremental investment to build direct rather than BaaS is standard at $3M+ monthly projected volume.
The board-ready summary
A board-ready embedded finance business case has four numbers: the annual revenue at target program maturity (modeled by rail mix, take rate, and projected volume), the annual cost at the same maturity (transaction costs + compliance overhead + infrastructure), the net margin on payment revenue (typically 60–80% at scale after all costs), and the enterprise value impact at the company's current revenue multiple. Those four numbers, with the architecture decisions that determine them, are the CFO conversation.
Want to build the CFO-ready business case for your embedded finance program? The business case framework covers the revenue model, cost model, and payback calculation, or talk with us directly.