---
title: "How to Build Embedded Finance Features in Your SaaS Product"
author: "Nate Laquis"
author_role: "Founder & CEO"
date: "2026-05-01"
category: "How to Build"
tags:
  - embedded finance SaaS
  - banking as a service
  - BaaS integration
  - fintech SaaS platform
  - embedded payments
excerpt: "Your SaaS platform is already where your customers manage their business. Adding financial services directly into that workflow can unlock 2-5x more revenue per user. Here is how to build it."
reading_time: "15 min read"
canonical_url: "https://kanopylabs.com/blog/how-to-build-embedded-finance-for-saas"
---

# How to Build Embedded Finance Features in Your SaaS Product

## The $7.2 Trillion Embedded Finance Opportunity

Embedded finance is not a buzzword. It is a $7.2 trillion market opportunity that is reshaping how software companies generate revenue. The core idea is simple: instead of sending your users to a separate bank, payment processor, or insurance provider, you bring those financial services directly into your platform.

Think about it from your user's perspective. They already live inside your SaaS product to manage their operations. Every time you force them to leave your platform to handle a payment, apply for a loan, or manage their cash flow, you create friction. That friction costs you engagement, retention, and revenue.

The shift is already well underway. Shopify earns more from Shopify Payments and Shopify Capital than from its core subscription fees. Toast generates significant revenue from payment processing on top of its restaurant management software. Mindbody, ServiceTitan, and Jobber have all layered financial products into their vertical SaaS platforms.

The reason this works is distribution. You already own the customer relationship and the data. A standalone fintech company has to spend heavily on customer acquisition, then fight to prove creditworthiness and build trust. As a SaaS platform, you already have transaction history, customer behavior data, and daily engagement. That is an enormous advantage when underwriting loans, pricing insurance, or managing payment risk.

According to Bain and Bain Capital, embedded finance revenue in the US alone will exceed $50 billion by 2026, growing at 25% annually. For SaaS founders, the question is no longer "should we add financial features?" It is "which financial features should we add first, and how do we architect them correctly?"

## Types of Embedded Finance: Picking What Fits Your Platform

Not every financial product makes sense for every SaaS platform. The right choice depends on your vertical, your users' pain points, and the data you already have. Here is a breakdown of the five major categories and where they fit best.

![team collaborating on embedded finance product strategy in a planning session](https://images.unsplash.com/photo-1531482615713-2afd69097998?w=800&q=80)

**Embedded Payments**

This is the most common starting point. You process payments directly within your platform instead of redirecting users to a third-party checkout. Examples include Shopify Payments, Squarespace Commerce, and Wix Payments. Revenue comes from taking a percentage of each transaction (typically 0.5% to 1.0% on top of processor costs). If your platform facilitates any kind of commerce, invoicing, or B2B transactions, embedded payments should be your first move.

**Embedded Lending**

You offer loans or cash advances to your users based on data you already have about their business. Shopify Capital, Square Loans, and Amazon Lending are prime examples. Because you can see a merchant's real-time sales data, you can underwrite faster and more accurately than a traditional bank. Revenue comes from interest, fees, or a fixed repayment percentage on future sales. This works best for platforms serving small and mid-sized businesses with recurring revenue you can observe.

**Embedded Insurance**

You bundle relevant insurance products directly into your platform's workflow. Tesla offering car insurance at the point of vehicle purchase. Gusto offering workers' comp insurance to its payroll customers. Shopify offering shipping insurance at checkout. Revenue comes from commissions on premiums, typically 10% to 20%. This fits well if your users face clear, quantifiable risks that you can detect through platform data.

**Embedded Banking**

You offer bank accounts, debit cards, and cash management directly within your platform. Shopify Balance, Lyft Direct, and DoorDash's DasherDirect are examples. Users get a branded bank account and debit card tied to their earnings or business revenue. Revenue comes from interchange fees (typically $0.50 to $2.00 per debit card transaction) and interest earned on deposits. This is powerful for platforms where users receive payouts, because you become the place where that money lands and gets spent.

**Embedded Investment and Wealth**

You offer savings, investment, or wealth management features within your platform. Acorns embedding round-up investing into banking. Betterment offering 401(k) management through employer platforms. This is the most complex category from a regulatory standpoint, requiring broker-dealer relationships and SEC/FINRA compliance. It fits best for HR, payroll, or personal finance platforms.

## BaaS Providers Compared: Stripe Treasury vs. Unit vs. Treasury Prime vs. Moov

You do not need a banking license to offer financial products. Banking-as-a-Service (BaaS) providers handle the regulated infrastructure while you build the user experience. But choosing the wrong provider can cost you months of rework. Here is an honest comparison of the major players.

**Stripe Treasury**

Stripe Treasury lets you embed FDIC-insured bank accounts and money movement into your platform through Stripe's existing API ecosystem. If you already use Stripe for payments, adding Treasury is a natural extension. Stripe partners with banks like Evolve Bank & Trust and Goldman Sachs to provide the underlying accounts. The API is clean and well-documented, which is typical of Stripe. Pricing is competitive, and you earn a revenue share on interchange and interest. The limitation is flexibility. Stripe Treasury works great for standard use cases (hold funds, issue cards, move money), but if you need highly customized banking products, you may find the guardrails too tight.

**Unit**

Unit is purpose-built for embedding banking features into software platforms. They offer checking accounts, debit and credit cards, ACH transfers, wires, and lending products. Unit partners with banks like Blue Ridge Bank and Piermont Bank. What sets Unit apart is the depth of their product. You get granular control over card programs, transaction rules, fee structures, and account types. Their dashboard and webhooks are solid. Unit charges a monthly platform fee plus per-account and per-transaction fees. They tend to work best for platforms that need a full-stack banking solution with heavy customization.

**Treasury Prime**

Treasury Prime takes a slightly different approach. Instead of partnering with one or two banks, they maintain a network of bank partners. This gives you more flexibility to choose a bank that fits your specific compliance needs, risk appetite, and product requirements. Treasury Prime's API covers accounts, cards, payments, and lending. They position themselves as more "bank-friendly," meaning they help you build a genuine banking relationship rather than abstracting the bank away entirely. This matters for regulatory purposes, especially as regulators increase scrutiny on BaaS arrangements. The tradeoff is that Treasury Prime's API can be less polished than Stripe's or Unit's, and onboarding takes longer because you are building a direct relationship with the partner bank.

**Moov**

Moov is an open-source-first financial infrastructure company. Their core platform handles money movement (ACH, card processing, wallets) and is designed to be modular. You can use Moov for just payment facilitation, or layer on accounts and card issuing. What makes Moov interesting is transparency. Their pricing is straightforward, their documentation is developer-friendly, and their open-source components let you inspect exactly what is happening under the hood. Moov is a strong choice if your primary need is payment facilitation and money movement rather than full banking products.

**How to Choose**

If you are already on Stripe and want to add accounts and cards with minimal friction, start with Stripe Treasury. If you need a full-stack banking platform with deep customization, Unit is the strongest option. If regulatory relationships and bank network flexibility matter most, Treasury Prime is worth the longer onboarding. If you want modular money movement with transparent pricing, Moov is compelling. In all cases, budget 2 to 4 months for integration and compliance onboarding before you can go live.

## Regulatory Requirements and Compliance Costs

This is where most SaaS founders underestimate the work involved. Embedded finance does not make compliance optional. It changes who is responsible for what, and it adds new obligations you may not have encountered before.

![secure payment checkout interface on laptop screen for embedded finance transaction](https://images.unsplash.com/photo-1556742049-0cfed4f6a45d?w=800&q=80)

**Money Transmitter Licenses (MTLs)**

If you hold, transfer, or facilitate the movement of funds, you may need money transmitter licenses. In the US, that means applying in each state individually. The full process across all 50 states can cost $500,000 to $2 million and take 12 to 24 months. The good news: if you use a BaaS provider, their partner bank's license typically covers your activities. But you need to structure the relationship correctly. Regulators have started cracking down on "rent-a-charter" arrangements where the technology company operates too independently from the bank. Make sure your BaaS provider has a clean regulatory track record.

**KYC and AML Requirements**

Know Your Customer (KYC) and Anti-Money Laundering (AML) compliance are mandatory for any financial product. You need to verify user identities, screen against sanctions lists (OFAC, EU sanctions), and monitor transactions for suspicious activity. Services like [Plaid Identity, Persona, and Onfido](/blog/how-to-build-a-fintech-app) handle KYC verification at $1 to $5 per check. Transaction monitoring tools like Sardine, Unit21, and Alloy run $5,000 to $25,000 per month depending on volume. Do not try to build this in-house. The regulatory surface area is massive, and the penalties for getting it wrong include criminal liability.

**PCI DSS Compliance**

If you process or store payment card data, PCI DSS compliance is required. For most SaaS platforms, the simplest path is using tokenized payment methods through Stripe or Adyen, which keeps you at PCI SAQ-A (the lightest compliance level). Never store raw card numbers on your servers. Ever. A PCI Level 1 audit runs $50,000 to $200,000 annually, and that is a cost you can avoid entirely by using the right architecture.

**State and Federal Lending Regulations**

If you offer lending products, you enter a separate regulatory universe. The Truth in Lending Act (TILA), Equal Credit Opportunity Act (ECOA), Fair Credit Reporting Act (FCRA), and various state lending laws all apply. Usury limits vary by state. Disclosure requirements are specific and enforceable. Your BaaS lending partner should handle most of this, but you need a fintech-savvy attorney to review your program. Budget $50,000 to $150,000 for initial legal and compliance setup, plus $10,000 to $30,000 per month for ongoing compliance management.

**Data Privacy and Security**

Financial data is among the most regulated categories of personal information. GLBA (Gramm-Leach-Bliley Act) requires you to protect customer financial information and provide privacy notices. State laws like CCPA and emerging state privacy regulations add further requirements. SOC 2 Type II certification is effectively mandatory for any SaaS platform handling financial data. A SOC 2 audit costs $30,000 to $100,000 and takes 3 to 6 months to complete.

## Integration Architecture: How to Build It Right

Getting the architecture right from the start saves you months of painful refactoring later. Here is how to structure an embedded finance integration that scales.

**The Middleware Layer**

Never connect your application directly to your BaaS provider's API without an abstraction layer in between. Build a middleware service (we call it the "finance orchestration layer") that sits between your core application and external financial providers. This layer handles API translation, retry logic, webhook processing, and provider switching. If you ever need to swap from Unit to Treasury Prime, or add Stripe Treasury alongside your existing provider, the middleware makes that possible without rewriting your application code.

**Event-Driven Transaction Processing**

Financial transactions require eventual consistency and robust event handling. Use an event-driven architecture with a message queue (AWS SQS, Google Pub/Sub, or Kafka for high volume). Every financial operation should publish events: account.created, payment.initiated, payment.completed, payment.failed, card.authorized, card.settled. Your application subscribes to these events and updates state accordingly. This pattern gives you auditability (every event is logged), resilience (failed processors can retry), and decoupling (your UI does not block on settlement).

**Webhook Reliability**

Your BaaS provider will send webhooks for account status changes, transaction updates, card authorizations, and compliance events. Webhook delivery is not guaranteed to be exactly-once. Build your handlers to be idempotent. Store a hash of each processed webhook and skip duplicates. Implement exponential backoff for failed processing. Log every incoming webhook payload for debugging and audit purposes. We have seen platforms lose thousands of dollars because a webhook handler crashed silently and transactions were never reconciled.

**Ledger Design**

You need your own internal ledger that mirrors the state of accounts at your BaaS provider. This is not optional. Network delays, webhook ordering issues, and provider outages mean you cannot rely solely on API calls to your BaaS provider for real-time balance information. Your internal ledger should use double-entry accounting principles: every transaction has a debit and a credit. Reconcile your ledger against the provider's ledger daily (at minimum). Discrepancies should trigger alerts. For the ledger database, use PostgreSQL with serializable transaction isolation. Do not use eventually consistent databases for financial records.

**Security Architecture**

Encrypt all financial data at rest (AES-256) and in transit (TLS 1.3). Use field-level encryption for sensitive data like account numbers and SSNs, not just database-level encryption. Implement strict role-based access control. Your customer support team should see masked account numbers, not full ones. Log every data access event. Use a secrets manager (AWS Secrets Manager, HashiCorp Vault) for API keys and credentials. Rotate keys on a regular schedule, not just when someone leaves the company.

**Sample Integration Flow**

Here is a typical flow for embedded account creation:

- User clicks "Open Business Account" in your SaaS dashboard

- Your app collects required KYC information (name, DOB, SSN, address)

- Middleware sends KYC data to identity verification provider (Plaid Identity or Persona)

- On verification success, middleware calls BaaS provider API to create an account

- BaaS provider returns account details, middleware stores them in your encrypted database

- Webhook confirms account is active, your app updates the user's dashboard

- User can now hold funds, send payments, and receive a debit card

The entire flow should take under 60 seconds for a user with clean KYC. Budget 6 to 10 weeks of engineering time to build and test this properly.

## Revenue Models: How Embedded Finance Pays Off

The financial case for embedded finance is compelling. Platforms that successfully add financial products see 2 to 5 times more revenue per user compared to SaaS subscriptions alone. Here is how the revenue math works across each product type.

![startup team reviewing embedded finance revenue metrics in a modern office](https://images.unsplash.com/photo-1504384308090-c894fdcc538d?w=800&q=80)

**Interchange Revenue (Cards)**

When your users spend with a platform-issued debit or credit card, you earn interchange fees on every transaction. Debit interchange is typically 0.5% to 1.0% of the transaction amount (plus a fixed fee of $0.15 to $0.25). Credit interchange is higher, at 1.5% to 2.5%. For a platform with 10,000 active cardholders spending an average of $2,000 per month, debit interchange alone generates $100,000 to $200,000 in monthly revenue. Most BaaS providers share 70% to 90% of interchange with you.

**Interest Spread (Deposits)**

When users hold funds in platform-issued bank accounts, the partner bank earns interest on those deposits. You receive a share of that interest income, typically 50 to 100 basis points on the deposit balance. If your platform holds $50 million in aggregate deposits, that is $250,000 to $500,000 per year in passive revenue. This revenue stream scales directly with your user base and is highly profitable because there is virtually zero marginal cost.

**Lending Fees and Interest**

Embedded lending is the highest-margin financial product you can offer. Merchant cash advances typically charge factor rates of 1.1x to 1.4x (meaning a $10,000 advance is repaid as $11,000 to $14,000). Term loans carry APRs of 10% to 36% depending on risk profile. Shopify Capital has deployed over $5 billion in merchant financing with loss rates well below traditional lending, because they can see merchant sales data in real time and adjust repayment automatically. If you serve SMBs and have access to their revenue data, [lending is where the largest revenue opportunity sits](/blog/how-to-implement-subscription-billing).

**Insurance Commissions**

Embedded insurance generates commissions of 10% to 20% on each premium sold. This sounds modest, but insurance is a recurring revenue stream with high attach rates when offered at the right moment. A property management SaaS platform offering renters insurance at lease signing can see 30% to 50% attach rates. At an average annual premium of $200 and a 15% commission, that is $30 per tenant per year in pure margin. Across 100,000 tenants, that is $3 million annually from a product that takes minimal engineering effort to embed.

**Payment Processing Margins**

When you become a payment facilitator (PayFac), you earn the spread between your processor's wholesale rate and the rate you charge merchants. For card-present transactions, this spread is typically 0.3% to 0.7%. For card-not-present, it is 0.5% to 1.0%. A vertical SaaS platform processing $500 million in annual payment volume at a 0.5% spread earns $2.5 million per year from payments alone. That is often more than the total SaaS subscription revenue.

**Blended Revenue Impact**

The real power of embedded finance comes from stacking multiple revenue streams. A platform charging $100 per month in SaaS fees might generate an additional $50 to $200 per user per month from payments, interchange, lending, and insurance combined. That is a 2x to 5x increase in total revenue per user without acquiring a single new customer. This is why investors are paying premium multiples for SaaS companies with embedded finance strategies.

## Implementation Timeline and Budget

Let us be direct about what this costs and how long it takes. Embedded finance is not a weekend hackathon project. But it does not need to take years or cost millions either, if you sequence it correctly.

**Phase 1: Embedded Payments (8 to 12 weeks, $50K to $150K)**

Start here. Payment facilitation has the fastest time to revenue and the lowest regulatory complexity. Integrate Stripe Connect or Adyen for Platforms. Build a split payment flow that lets your platform take a percentage of each transaction. Add payout management so your users can see and control their earnings. This phase requires a payment integration engineer, a backend developer, and a frontend developer. Include 2 to 3 weeks for PCI compliance documentation and testing.

**Phase 2: Embedded Accounts and Cards (12 to 20 weeks, $150K to $400K)**

Once payments are flowing, add bank accounts and debit cards. Choose your BaaS provider (Stripe Treasury, Unit, or Treasury Prime). Build KYC onboarding flows with identity verification. Integrate card issuing and management (virtual and physical cards). Build the internal ledger and reconciliation system. This phase requires your BaaS provider's compliance onboarding (4 to 8 weeks alone), plus engineering for the middleware layer, webhook handling, and user interface.

**Phase 3: Embedded Lending (16 to 24 weeks, $200K to $500K)**

Lending is the highest-value but most complex addition. Build underwriting models using your platform data. Integrate with a lending partner or BaaS provider's lending product. Build loan application, approval, disbursement, and repayment flows. Implement servicing dashboards for both borrowers and your operations team. Legal review for lending disclosures and state compliance adds 4 to 8 weeks. You also need capital, either from your own balance sheet, a lending partner, or a credit facility.

**Phase 4: Embedded Insurance (6 to 10 weeks, $30K to $80K)**

Insurance is surprisingly quick to implement. Partner with an embedded insurance platform like Boost, Cover Genius, or Ascend. Integrate their API into your relevant workflow moments (checkout, onboarding, renewal). Build quote and bind flows into your existing UI. Insurance requires less engineering than banking or lending, but you need a licensed insurance agent or broker relationship in each state where you operate.

**Total Investment for Full Stack**

Building all four pillars takes 12 to 18 months and costs $400K to $1.1M in total development investment. That sounds significant, but compare it to the revenue potential. A platform with 20,000 active users generating an additional $100 per user per month from embedded finance earns $24 million per year in incremental revenue. The payback period on your development investment is typically 3 to 6 months after launch.

Our recommendation: do not try to build everything at once. Start with payments, prove the revenue model, then layer on accounts, cards, lending, and insurance sequentially. Each phase funds the next. If you want help mapping this to your specific platform and user base, [book a free strategy call](/get-started) and we will build a phased roadmap together.

---

*Originally published on [Kanopy Labs](https://kanopylabs.com/blog/how-to-build-embedded-finance-for-saas)*