Embedded finance providers operate the API infrastructure that lets non-financial software platforms offer banking, payments, lending, cards, and insurance to their own customers. The customer is a platform (vertical SaaS, marketplace, gig economy app, e-commerce platform) that wants to integrate financial products without becoming a regulated financial institution itself. The embedded finance provider supplies the APIs, the compliance infrastructure, the partner bank or charter relationships, and the operational stack that makes financial product delivery possible. The model differs from neobanks serving consumers directly and from payment processors serving merchants. The accounting and finance work centers on platform partner economics, multi-tenant operations at scale, three-party compliance allocation, and the API-driven revenue mechanics that come with operating a B2B2B or B2B2C infrastructure business. This page covers what makes embedded finance accounting distinct, and the services available to address it.
Executive Summary
- Embedded finance providers sell financial product APIs to non-financial software platforms, operating as the BaaS or infrastructure layer rather than as a consumer-facing or merchant-facing business directly.
- Platform partner revenue share is the central economic mechanic, with partners receiving negotiated portions of interchange, fees, or spread in exchange for distribution and customer relationships.
- Compliance responsibility is allocated across a three-party structure (partner bank, embedded finance provider, platform partner), with the embedded finance provider typically running KYC, AML, and transaction monitoring on behalf of all platform partners.
- Multi-tenant operations at scale create accounting infrastructure requirements unique to embedded finance: thousands of sub-accounts under platform partner master relationships, separate ledgers per platform, and consolidated reporting across the entire platform partner book.
- Concentration risk on top-tier platform partners is structurally significant, with the loss of one major integration potentially affecting material revenue.
What Embedded Finance Platforms Look Like as a Business
Embedded finance providers offer financial product infrastructure through APIs. The category includes:
- Banking-as-a-Service (BaaS) providers offering deposit accounts, ACH, wire, and core banking functionality through APIs
- Card issuing platforms providing infrastructure for clients to launch debit, credit, or prepaid card programs
- Payment infrastructure providers exposing card processing, ACH, and instant payment rails through developer-friendly APIs
- Embedded lending platforms providing credit underwriting and loan origination infrastructure to non-financial platforms
- Embedded insurance distribution through APIs for travel, retail, lending, or other vertical contexts
- Treasury and account management infrastructure for platforms moving customer funds at scale
- Compliance-as-a-service providers offering KYC, AML, and identity verification as standalone API services
- Vertical-specific embedded finance solutions tailored to specific industries (gig work, healthcare, real estate, hospitality)
What distinguishes embedded finance from other fintech is the B2B2X model: the embedded finance provider sells to a platform partner (a software company), and the platform partner delivers the financial product to its own end customers under its own brand. The end customer often doesn’t know the embedded finance provider exists. Revenue flows through a contractual structure where the embedded finance provider, the platform partner, and underlying partner banks each capture a portion of the economics. Operations require API reliability, compliance infrastructure that handles thousands of platform partners simultaneously, and the developer experience that drives platform partner adoption.
What Makes Embedded Finance Accounting Distinct
Platform partner revenue share economics
The platform partner revenue share is the most significant economic relationship in embedded finance. Partners typically receive negotiated portions of interchange (when end customers spend), fees (when end customers incur charges), spread (on lending or yield products), and other monetization streams. Revenue share terms vary by partner based on volume commitments, exclusivity, vertical focus, and strategic value. The accounting captures gross revenue at the source, partner revenue share owed under each contract, and net economics retained by the embedded finance provider. Partner-level profitability analysis becomes essential because some partners produce strong economics while others may operate at a loss for strategic reasons. Tiered structures with volume-based step changes add complexity to the accounting.
Multi-tenant operations and sub-account architecture
A vertical SaaS platform serving thousands of restaurants, an e-commerce platform with hundreds of thousands of merchants, or a gig economy app with millions of workers all bring sub-account scale that creates accounting infrastructure requirements unique to embedded finance. The platform may have one master relationship with the embedded finance provider while operating thousands of sub-accounts underneath. The accounting captures activity at multiple levels: end-customer level (transactions, balances), sub-account level (per restaurant, per merchant, per worker), platform-partner level (consolidated platform reporting), and embedded finance provider level (overall financial statements). Reconciliation across these levels has to be continuous and automated; manual approaches don’t scale to embedded finance volumes.
Three-party compliance allocation
Embedded finance operates in a three-party structure: the partner bank holds legal regulatory responsibility, the embedded finance provider operates the day-to-day compliance infrastructure (KYC, AML, transaction monitoring, sanctions screening), and the platform partner provides the customer relationship and brand. Compliance responsibility allocation across these three parties requires explicit contractual and operational documentation. The embedded finance provider typically runs compliance on behalf of dozens or hundreds of platform partners simultaneously, requiring infrastructure that scales while maintaining quality. BSA/AML programs have to satisfy partner bank oversight while serving the operational needs of the platform ecosystem. Recent regulatory enforcement has tightened expectations on the compliance allocation between parties.
API monetization and pricing model accounting
Embedded finance pricing typically combines multiple components: per-API-call fees for technical usage, per-transaction fees for specific events, percentage-based fees on transaction volume, monthly platform subscription fees, and revenue share on monetization the platform partner generates. Each component has different revenue recognition mechanics. Per-call fees recognize as calls occur. Per-transaction fees recognize at the transaction event. Subscription fees recognize over the contract period. Revenue share recognizes alongside the underlying revenue events. Bundled contracts that combine multiple components require allocation between performance obligations under ASC 606. The accounting infrastructure handles each pricing component appropriately, with per-platform-partner reporting that supports both internal management and the partner-facing analytics platforms expect.
Concentration risk and platform partner stability
Embedded finance providers often have concentrated platform partner bases where a small number of large partners represent disproportionate revenue. Loss of one major platform integration can materially affect financial performance. The accounting infrastructure tracks revenue concentration explicitly, with disclosure that flags partners above defined thresholds (typically 10 percent of revenue triggers explicit reporting). Concentration risk affects valuation discussions during fundraising and acquisition diligence, with concentrated revenue typically receiving valuation discounts relative to diversified comparable companies. Recent disruption in the BaaS sector has highlighted both partner concentration risk on the embedded finance provider side and dependency risk on the platform partner side.
Implementation and integration revenue
Embedded finance integrations typically involve substantial technical work before revenue begins: API integration, compliance review, security assessment, sub-account architecture design, and operational testing. Implementation timelines run weeks to months for sophisticated integrations. The accounting captures implementation work separately from ongoing platform revenue, with appropriate treatment of implementation fees (one-time charges if standalone value, amortized over contract period otherwise). Integration costs incurred by the embedded finance provider may need capitalization treatment if they represent costs of obtaining a contract under ASC 606. The gap between contract signing and revenue recognition affects bookings reporting and the relationship between sales activity and recognized revenue.
Customer fund accounting across platforms
Customer funds flowing through embedded finance infrastructure typically sit in FBO accounts at partner banks, with multiple platform partners’ end customers commingled in segregated accounts under the embedded finance provider’s master relationship. The accounting captures balances at multiple levels (end customer, platform partner, aggregate), with daily reconciliation across the structure. Float income earned on aggregate customer balances flows to the embedded finance provider, the partner bank, or sometimes the platform partner depending on contractual arrangement. Customer fund segregation requirements have tightened in recent regulatory guidance, with operational evidence supporting segregation becoming a routine examination focus.
SOC 2 and enterprise trust requirements
Enterprise platform partners require extensive security and operational evidence before integrating with embedded finance providers. SOC 2 Type II reports covering security, availability, processing integrity, confidentiality, and privacy are typically baseline requirements. ISO 27001, PCI DSS for card-related products, and other certifications may be required depending on the product mix. Annual or more frequent security questionnaires, vendor risk assessments, and contractual security commitments add ongoing operational obligations. The accounting captures certification costs, ongoing compliance infrastructure, and the operational evidence required to support partner due diligence. SOX compliance readiness becomes relevant as embedded finance providers approach public-company status or work with public-company platform partners.
Multi-product platform economics
Many embedded finance providers offer multiple product categories (banking, cards, ACH, lending, insurance) through one unified platform. Product mix decisions affect overall economics: cards are typically high-margin due to interchange; ACH is volume-driven and lower-margin; lending generates interest income but carries credit risk; insurance has its own specific economics. The accounting captures revenue and unit economics by product category, with platform partner-level analysis showing which products each partner uses and the resulting per-partner profitability. Product profitability analysis often shows that some products operate at a loss but support overall platform economics by enabling broader partner integrations.
Services for Embedded Finance Platforms
Fractional CFO leadership
Senior finance leadership for embedded finance operations. Platform partner revenue share strategy, multi-tenant operational economics, partner concentration management, partner bank relationship oversight, capital planning, fundraising support, M&A diligence response, and the institutional readiness work that scaled embedded finance providers need. For broader fintech context, see the CFO role in fintech guide. For our general fractional CFO services, see the fractional CFO services page.
Accounting and bookkeeping
Day-to-day accounting work for embedded finance operations. Platform partner revenue share recognition, multi-tenant sub-account reconciliation, API and per-transaction revenue tracking, customer fund FBO accounting across platforms, implementation revenue recognition, partner-level profitability tracking, and consolidated financial reporting that supports both internal management and partner-facing analytics. See startup accounting services for broader scope.
Consulting and advisory
Project-based engagements for specific embedded finance challenges. Platform partner revenue share contract analysis. Sub-account architecture financial modeling. Three-party compliance allocation framework. ASC 606 analysis for multi-component pricing models. Concentration risk analysis and revenue diversification strategy. Implementation revenue framework design. Partner bank relationship analysis. BSA/AML compliance program support. MTL readiness support. Audit readiness for providers preparing for first audit, IPO, or institutional partnership diligence. SOC 2 readiness preparation. See accounting consulting services for additional detail.
Frequently Asked Questions
How is embedded finance different from neobanks or payment processors?
Neobanks serve end consumers directly with their own banking products. Payment processors serve merchants directly with card processing. Embedded finance providers serve other software platforms (their customers are companies that build products), supplying the API infrastructure that lets those platforms offer financial features under their own brand. The end customer often doesn’t know the embedded finance provider exists. Revenue flows through a contractual structure that includes the embedded finance provider, the platform partner, and underlying partner banks.
How does platform partner revenue share work?
Partners receive negotiated portions of interchange, fees, spread, and other monetization in exchange for distribution and customer relationships. Revenue share terms vary by partner based on volume commitments, exclusivity, vertical focus, and strategic value. The accounting captures gross revenue at the source, partner revenue share owed under each contract, and net economics retained by the embedded finance provider. Partner-level profitability analysis becomes essential because economics vary substantially across the platform partner base.
How does compliance allocation work in embedded finance?
Through a three-party structure: the partner bank holds legal regulatory responsibility, the embedded finance provider operates day-to-day compliance infrastructure (KYC, AML, transaction monitoring, sanctions screening), and the platform partner provides customer relationship and brand. Compliance responsibility allocation requires explicit contractual and operational documentation. The embedded finance provider typically runs compliance on behalf of dozens or hundreds of platform partners simultaneously. Recent regulatory enforcement has tightened expectations on the allocation between parties.
How do multi-tenant sub-accounts affect accounting?
Platform partners often have thousands of sub-accounts under their master relationship with the embedded finance provider. The accounting captures activity at multiple levels: end-customer (transactions, balances), sub-account (per restaurant, per merchant, per worker), platform-partner (consolidated platform reporting), and embedded finance provider (overall financial statements). Reconciliation across these levels has to be continuous and automated; manual approaches don’t scale to typical embedded finance volumes.
How is API and per-transaction revenue recognized?
Different pricing components have different recognition mechanics. Per-API-call fees recognize as calls occur. Per-transaction fees recognize at the transaction event. Subscription fees recognize over the contract period. Revenue share recognizes alongside the underlying revenue events. Bundled contracts combining multiple components require allocation between performance obligations under ASC 606. Per-platform-partner reporting supports both internal management and partner-facing analytics.
Why is platform partner concentration a structural risk?
Embedded finance providers often have concentrated partner bases where a small number of large partners represent disproportionate revenue. Loss of one major integration can materially affect performance. The accounting tracks revenue concentration explicitly with disclosure flagging partners above defined thresholds. Concentrated revenue typically receives valuation discounts relative to diversified comparables. Recent disruption in the BaaS sector has highlighted concentration risk in both directions.
What certifications do embedded finance providers need?
SOC 2 Type II reports covering security, availability, processing integrity, confidentiality, and privacy are typically baseline. ISO 27001, PCI DSS for card-related products, and other certifications may be required depending on product mix. Annual security questionnaires, vendor risk assessments, and contractual security commitments add ongoing operational obligations. The accounting captures certification costs, ongoing compliance infrastructure, and operational evidence supporting partner due diligence.
Reviewed by YR, CPA
Senior Financial Advisor