The Finance Layer Is Moving Inside Your Product
In 2020, a construction management company called Procore added the ability for contractors to get paid directly through its platform. Not through a link to a bank. Not through a third-party invoice tool. Through Procore itself, which had built payment rails directly into its workflow software. Within two years, Procore's payment volume had become a material revenue line. The contractors were not using Procore because it had payments. They were using payments because they were already in Procore.
This is what embedded finance looks like in practice. It is not a fintech company building a banking app. It is an ERP, a vertical SaaS, a marketplace, or an operations platform embedding financial services - payments, lending, insurance, wallets - directly into the product experience. The user never leaves the primary workflow to handle money. The money handling is part of the workflow.
The business model implications are significant. But before discussing revenue and strategy, it is worth understanding the technical architecture that makes this possible - because the architecture determines what you can build, how quickly, and at what compliance cost.
What Embedded Finance Actually Means
The term "embedded finance" covers a range of products that are meaningfully different from each other in terms of technical complexity, regulatory burden, and business model.
Embedded payments are the most common starting point. This means accepting payments, disbursing funds, or both, through your platform rather than redirecting users to a payment provider's hosted page. Stripe, Adyen, and Braintree have made this accessible to most companies for consumer-facing flows. The more interesting development is Stripe Connect and similar "platform" APIs that allow marketplaces and SaaS platforms to move money between sellers, service providers, and buyers while managing split payments, fee collection, and tax reporting in a single integration.
Embedded lending is the next layer. Shopify Capital is the clearest example: Shopify analyzes merchant revenue data it already holds and offers working capital advances repaid automatically as a percentage of future sales. The merchant never goes to a bank. They receive a funding offer in their Shopify dashboard, accept it in two clicks, and repayment happens automatically. Shopify can underwrite this accurately because it has better data about the merchant's business than any traditional lender. The data advantage is the moat.
Embedded banking - issuing debit cards, providing business bank accounts, holding funds - is more complex because it requires either a banking license or a partnership with a chartered bank willing to act as the licensed entity behind your platform. Companies like Unit and Treasury Prime exist specifically to provide this "bank-as-a-service" infrastructure, allowing non-bank companies to offer banking products under their own brand while the licensed bank handles regulatory compliance.
Embedded insurance is the least mature but growing quickly. IKEA offering furniture protection at checkout. Uber offering on-trip accident coverage. The economics work when the distribution cost of insurance drops close to zero because the sale happens within an existing high-frequency product.
The API Stack That Makes It Work
Ten years ago, building any of this would have required either obtaining financial licenses yourself or negotiating bespoke arrangements with banks that had no interest in working with non-bank companies at API-first terms. The infrastructure layer has changed completely.
For payments and money movement: Stripe Treasury provides bank account-as-a-service via API, allowing platforms to hold funds, issue cards, and wire money without a banking license. Marqeta offers card issuance infrastructure used by companies like DoorDash and Klarna to issue their own branded cards with programmable spend controls. Modern Treasury provides a payment operations layer that abstracts across ACH, wire, RTP, and other rails.
For lending: Cross River Bank and WebBank are the licensed partners behind most embedded lending products - they originate loans, and the non-bank partner handles the customer relationship and underwriting data. Unit and Piermont provide the infrastructure to connect these relationships via API. The technical integration is manageable; the commercial and legal arrangement to establish the bank partnership is the harder part.
For identity and compliance: the KYC (Know Your Customer) and AML (Anti-Money Laundering) requirements that come with financial services can be satisfied through API providers like Persona, Alloy, or Sardine, which handle identity verification, document checks, and transaction monitoring. This does not eliminate your compliance obligations - it just automates the most labor-intensive parts of meeting them.
The Revenue Model: Where the Money Actually Comes From
For executives evaluating whether embedded finance is worth the investment, the revenue mechanics need to be understood clearly. There are four main revenue streams, and they have very different economics.
Interchange: When you issue debit or credit cards and cardholders use them, the issuing bank (or you, if you have the right arrangement) earns a percentage of each transaction from the merchant's bank. Interchange rates on business debit cards typically run 1.5-2% in the US. At significant volume, this becomes material. Brex and Ramp built substantial businesses partly on interchange economics from corporate card programs.
Float: Funds held in platform wallets or accounts can be invested in short-term instruments, generating interest income. At low interest rates this was negligible. At 5%+ rates, platforms holding significant customer balances earn meaningful float revenue. A platform holding $50 million in merchant balances earns $2.5 million annually at 5% - before doing anything else.
Loan economics: For embedded lending, the spread between funding cost and lending rate is the revenue. Shopify Capital charges effective APRs in the 15-25% range for merchant cash advances. The underwriting advantage from transaction data means default rates are low relative to traditional SMB lending. Shopify reported $393 million in merchant cash advances in Q2 2023 alone.
Premium features: Some platforms charge for access to embedded financial features - faster payouts, higher credit limits, advanced treasury management tools. This is a simpler model but typically generates lower revenue than the economics above.
The Compliance Reality: What You Are Actually Taking On
Embedded finance is not a pure software play. The moment you are holding customer funds, issuing loans, or facilitating regulated financial transactions, you are operating in a regulated environment with real legal exposure. Technology leaders who underestimate this part of the build are the ones who end up with expensive remediation projects six months post-launch.
The compliance requirements vary by product type and jurisdiction, but the consistent themes are: Know Your Customer verification (identity checks before onboarding), Bank Secrecy Act compliance (transaction monitoring and suspicious activity reporting), state money transmitter licenses if you are moving funds (in the US, required in most states separately), and consumer financial protection requirements if your product touches consumer rather than business customers.
The good news is that working through a licensed banking partner via a BaaS arrangement shifts much of the regulatory burden to the bank, which has compliance infrastructure already in place. The less good news is that "the bank handles compliance" is not entirely accurate - you are responsible for ensuring your implementation of the bank's infrastructure meets their compliance requirements, and the bank has audit rights over your platform. Building the technical infrastructure to satisfy those audit requirements is non-trivial.
Technical Integration Patterns That Hold Up at Scale
The architecture choices you make at the start of an embedded finance integration determine how well the system performs and how maintainable it is as your financial product complexity grows.
The most important structural decision is whether to treat your financial services layer as a first-class internal service or to build it as a thin wrapper around your BaaS provider. Thin wrappers are faster to build but create tight coupling to a specific vendor's data model and API design. If you need to change providers - because of pricing, reliability, or capability gaps - a thin wrapper means rebuilding from scratch. A proper internal financial service layer abstracts the provider behind your own domain model, making provider substitution possible without upstream changes.
For event handling: financial events must be idempotent. A payment webhook delivered twice should not result in two credits. A payout instruction submitted twice should not result in two payouts. Building idempotency keys into every financial operation from day one is not optional - it is the difference between a system that behaves correctly under failure conditions and one that creates financial discrepancies that take weeks to reconcile.
For reconciliation: build the reconciliation layer before you need it, not after you discover discrepancies. This means daily automated matching of your internal ledger against the BaaS provider's reported balances, alerting on differences above a threshold, and a clear process for investigating and resolving exceptions. Financial reconciliation is boring infrastructure that every organization running embedded finance eventually builds - the ones who build it early avoid the regulatory and reputational risk of discovering errors at scale.
Is Embedded Finance Right for Your Platform?
Not every vertical SaaS or ERP should build embedded financial products. The value is highest when three conditions are met: you have high transaction frequency and volume flowing through your platform (the data advantage only matters if there is data); you have strong customer retention (embedded financial products increase switching costs, but they require customers to trust you with financial relationships, which requires an existing strong relationship); and your customers have an unmet financial need that your data position lets you serve better than traditional banks.
The companies that have built successful embedded finance offerings share a common pattern: they started with the financial pain point that their customers mentioned most often, built the simplest possible version of the solution, and expanded from there. Shopify started with payments before moving to capital. Toast (restaurant SaaS) started with payment processing before adding business banking. The expansion into adjacent financial products was credible because the foundation was trusted.
Building with GTEMAS
GTEMAS has experience designing and implementing embedded finance integrations for enterprise clients across ERP, marketplace, and vertical SaaS contexts. This includes BaaS provider evaluation and integration architecture, compliance infrastructure design, reconciliation systems, and ongoing financial data engineering.
The regulatory landscape for embedded finance changes quickly, and the technical implementation complexity is higher than a typical software feature build. If you are evaluating whether and how to add financial capabilities to your platform, we can help you scope the build realistically and design an architecture that will hold up as the product grows.