When you launch an embedded finance program via BaaS, the technical integration is visible. The float economics are not. Settlement timing, FBO account structure, and interest-bearing account design sit in the contract language and the bank relationship terms — not in the product spec or the BaaS dashboard.
Most programs treat float as a byproduct of how long payments take to clear. That framing costs money. For CFOs and program operators, settlement timing and float management are capital efficiency levers that directly determine the profitability of your payments division.
What float actually is — and why it's negotiable
Float is the period between when funds leave the payer and when they arrive in the payee's account and are fully cleared. During that window, funds sit somewhere. In a well-designed BaaS program, "somewhere" is an interest-bearing account that you — the program sponsor — have structured to capture the yield. In a poorly designed program, the funds sit in the bank's account and the bank keeps the interest.
This is not a fixed architectural constraint. It's a commercial term. The sponsor bank relationship determines who captures float revenue — and most programs never negotiate it because they don't know to ask.
Three decisions that determine float economics
Account structuring. FBO accounts that are designed with multiple tiers — operational, reserve, customer balance — and placed in interest-bearing structures where permissible generate yield on idle capital. Single-account FBO structures without interest designation generate zero. This is an architecture decision made at program launch, not an operational improvement that can be retrofitted easily.
Settlement velocity design. Not all payments should settle at the same speed. Standard ACH settlement (1–2 days) creates a float window. Accelerated settlement (same-day, instant) eliminates it. The design question is: which transactions benefit from speed, and which transactions benefit from the float window? Programs that default to fastest-available settlement on everything are eliminating float revenue without capturing the speed premium that would offset it.
Bank relationship terms. The commercial terms of the sponsor bank relationship determine whether float yield flows to the program sponsor or remains with the bank. "Interest on FBO balances" is a negotiable term — one that most programs don't negotiate because they enter the bank conversation without a prepared commercial framework. Entering that conversation prepared means arriving with defined float economics requirements, not accepting what's offered.
The working capital dimension
Float optimization has a second dimension beyond yield: working capital efficiency. In high-volume disbursement programs — payroll disbursement, insurance payments, contractor payments — the program may need to front capital to cover payments before settlement clears. Every day of settlement acceleration reduces the capital required to operate. Every day of unnecessary settlement delay increases the operational float requirement.
Programs that model their working capital requirement against settlement timing often find that the capital freed by settlement optimization is worth more than the float yield foregone by accelerating. The calculation is specific to each program's volume profile, payment mix, and cost of capital. It needs to be modeled as part of the program design — not figured out post-launch when the capital requirement has already been committed.
The reconciliation problem
Settlement architecture also determines reconciliation complexity. BaaS programs where every transaction has a unique identifier traceable across the internal ledger and FBO accounts can achieve near-100% automated reconciliation. Programs that lack granular data exchange between the BaaS layer and the program's internal accounting end up with manual reconciliation that costs labor and introduces error.
The data model that enables automated reconciliation — transaction-level identifiers, settlement confirmation timing, FBO balance reporting — needs to be specified in the BaaS contract and validated in implementation. It can't be added after the fact without significant rework.
What designing for float revenue looks like
A program designed for float revenue has three elements in place before launch: the FBO account structure places balances in interest-bearing accounts where permissible under regulatory guidelines; the bank relationship terms include explicit float economics language covering yield rate, calculation method, and timing of payment to the program sponsor; and the settlement velocity model has been mapped against both the working capital requirement and the speed premium revenue available at each tier.
Programs that design all three capture float as revenue from day one. Programs that don't discover the gap six months in — when renegotiating bank terms mid-program is significantly harder than negotiating before the relationship begins.