Fintech and Payments: Cube vs Mosaic for Take Rate Modeling

Take rate, the net percentage of processed volume you keep after interchange, sponsor bank fees, and network costs, compresses over time as you sign larger merchants who negotiate better terms. A model that uses a single blended take rate assumption across your whole book will overstate revenue the moment your mix shifts toward larger accounts.

Cube lets you build a tiered take-rate model directly in the spreadsheet, segmenting by merchant size or vertical so a shift in mix shows up as a mix effect rather than getting buried in an average. Mosaic can track transaction volume and revenue as connected metrics, but the take-rate tiering logic itself is something you'd configure as a custom calculation rather than pull from a built-in SaaS template, since take rate isn't a standard SaaS metric.

Interest earned on customer balances held before settlement is real revenue, but it depends on the interest rate environment, not on anything your product team did, and it can swing your margin story quarter to quarter for reasons unrelated to the business you're actually building. Keep float income on its own line, separate from take-rate revenue, so a rate cut doesn't get mistaken for a pricing problem in your core transaction business.

This is one area where Cube's flexibility to build a custom line item without waiting on a vendor's roadmap tends to matter more than Mosaic's automation, since float income modeling isn't a common SaaS use case either platform ships pre-built.

Sponsor bank fees, card network costs, and compliance overhead (licensing, audits, a dedicated compliance team) don't map neatly onto a standard SaaS cost-of-goods-sold versus operating-expense split. A compliance headcount that exists because you move regulated money is a real cost of doing business, arguably closer to cost of revenue than G&A, but most out-of-the-box department spend benchmarks assume a SaaS company's department mix, sales, marketing, R&D, G&A, without a distinct compliance category¹.

Build compliance as its own department line in whichever tool you use, rather than folding it into G&A, so you can actually see how compliance cost scales with transaction volume over time.

Fintech headcount planning usually splits into two very different hiring motions: product engineering, which scales with roadmap, and compliance and risk, which scales with transaction volume and regulatory exposure rather than feature velocity. Wage growth across the broader labor market has been running at 3.4% year over year according to the Employment Cost Index², though compliance and risk specialists in regulated fintech typically command a premium above that baseline given how thin the talent pool is.

Model these as two separate headcount tracks with different triggers, engineering against roadmap milestones, compliance against transaction volume and new state licenses, rather than one blended engineering headcount number.

• If subscription or platform fees are still your largest revenue line, Mosaic's SaaS-focused metrics may cover much of your model with light adjustment, so confirm that in a demo.
• If transaction revenue and take rate dominate, Cube's flexibility to build custom take-rate tiering and float-income logic will likely save you fighting a template not built for it.
• If you're early and still proving unit economics per transaction type, the spreadsheet transparency of Cube makes it easier to defend your assumptions to an investor asking pointed questions about how you actually make money on each transaction.

Whichever you pick, keep take-rate revenue, float income, and subscription revenue as three distinct lines from the start, and revisit the split at least quarterly as your merchant mix and product bundle continue to shift.