Introduction
Embedded banking is the reason a rideshare driver can get paid minutes after a trip, a merchant can hold a business balance inside an ecommerce dashboard, and a freelancer can spend from a debit card issued by software they already use every day. The bank is still there, but it sits in the background while a brand the customer already trusts handles the experience. This guide explains what embedded banking is, how the pieces fit together in the US, what went wrong in the Synapse collapse, and how to launch an embedded banking product without cutting corners on compliance.
Quick Answer
Embedded banking is when a non-bank company offers banking products, such as deposit accounts, debit cards, bill pay, or instant payouts, directly inside its own app or platform. A licensed partner bank holds the funds and the charter, a banking-as-a-service provider connects the two through APIs, and the brand owns the customer experience. In the US, embedded finance is projected to handle more than $7 trillion in transactions in 2026, according to Bain & Company.
At Rocketeams we build fintech products for US companies, including engineering work on a BBVA-backed digital banking platform, so this guide leans on what actually happens during a build and not only the theory.
What Is Embedded Banking?
Embedded banking is the integration of core banking services, such as accounts, cards, transfers, and payouts, into the product of a company that is not a bank. The customer never visits a bank website or downloads a separate banking app. They open an account, move money, and spend it inside the platform they were already using.
It is one slice of embedded finance. Embedded finance covers any financial product placed inside a non-financial experience, including payments at checkout, lending, and insurance. Embedded banking focuses on the core banking layer: holding money, moving it, and spending it.
The terms get mixed up constantly, even by vendors, so here is how they relate to each other.
Embedded Banking vs Embedded Finance vs Banking as a Service vs Open Banking
| Term | What it means | Who uses it | Example |
|---|---|---|---|
| Embedded banking | Banking products such as accounts, cards, and transfers offered inside a non-bank brand’s product | The brand’s end users | A gig app paying drivers into an in-app account with a debit card |
| Embedded finance | Any financial service inside a non-financial product, including payments, lending, and insurance | Consumers and businesses | Buy now, pay later offered at checkout |
| Banking as a service (BaaS) | The infrastructure and bank partnerships that make embedded banking possible, usually delivered through APIs | Brands and fintechs building financial products | A platform exposing account and card APIs from a sponsor bank |
| Open banking | Consumers sharing their existing bank data with third parties through secure APIs, with consent | Apps that need account data or pay-by-bank | A budgeting app reading checking transactions with the user’s permission |
A simple way to keep it straight: banking as a service is the engine, embedded banking is the product you build with it, and open banking is about data moving between accounts people already hold. When a platform like Square offers checking accounts to its sellers, people call it embedded banking from the customer’s side and BaaS from the infrastructure side. Both are correct.
How Does Embedded Banking Work?
Embedded banking works through a partnership between a chartered bank, a technology layer, and the brand that owns the customer relationship. Each party has a defined job, and most of the serious failures in this industry happened when those jobs blurred.
Who Does What in an Embedded Banking Program
| Player | Role | What it is responsible for |
|---|---|---|
| Sponsor bank (partner bank) | Holds the charter and the deposits | Deposit insurance eligibility, BSA and AML oversight, approving the program and its marketing |
| BaaS or middleware provider | Connects the brand to the bank through APIs | Account and card APIs, ledgering, and often KYC and compliance tooling |
| Card issuer processor | Issues and processes debit or prepaid cards | Authorizations, card controls, and card network connections |
| The brand (you) | Owns the product and the customer | User experience, customer support, complaints, fraud monitoring, and meeting the bank’s program requirements |
| Compliance and data vendors | Specialist services that plug into the stack | Identity verification, sanctions screening, and transaction monitoring |
Here is what happens when a user opens an account inside an app. The brand collects identity details, and a KYC vendor checks them against identity databases and watchlists. If the person passes, the BaaS provider creates an account record tied to the partner bank. In many programs, customer money sits in a pooled for-benefit-of (FBO) account at the bank, and a ledger tracks exactly how much of that pool belongs to each person. When the user taps their debit card, the card processor authorizes the purchase against their ledger balance and the bank settles it.
That ledger is the part most people never think about, and it is the part that matters most. If the brand’s records, the middleware provider’s records, and the bank’s records ever disagree, real customers can lose access to their money. We come back to this in the risks section, because it is exactly what happened in 2024.
Types of Embedded Banking, With Real US Examples
The most common embedded banking products in the US are in-app accounts, branded debit cards, instant payouts, and embedded bill pay, with embedded lending often added once the core account is live. Here is how each one shows up in products people already use.
Common Embedded Banking Products and US Examples
| Product | What users get | Real-world example |
|---|---|---|
| In-app business or personal accounts | A balance held inside the platform they already use | Shopify Balance for online merchants, Square Checking for sellers |
| Branded debit and prepaid cards | A card to spend their balance or earnings right away | Lyft Direct debit card for drivers |
| Instant payouts | Earnings available right after a job, shift, or sale | Uber Pro Card, which deposits driver earnings after each trip |
| Embedded bill pay and B2B payments | Pay vendors and reconcile accounts inside accounting or ERP software | TD Embedded Banking plugin for QuickBooks Online, NetSuite, and Sage Intacct |
| Embedded lending (a close cousin) | Working capital offered based on platform sales data | Shopify Capital, Square Loans |
Consumer products get most of the attention, but some of the best opportunities sit in business software. Vertical SaaS platforms for restaurants, construction, property management, and healthcare billing already see their customers’ cash flow every day. Adding an operating account or a payables feature inside that software solves a real problem for the business owner and gives the platform a new revenue line.
The pattern behind the strongest embedded banking examples is the same. The financial feature makes the core product more useful, instead of feeling like a bank account bolted onto an unrelated app.
Why Embedded Banking Matters in 2026
Embedded finance has moved from an experiment to a real share of US money movement. Bain & Company projected that embedded finance would handle more than $7 trillion in US transactions in 2026, over 10 percent of all US financial transaction value, and that revenue for the software platforms and enablers behind it would more than double to $51 billion.
Embedded Finance and Embedded Banking by the Numbers
| Metric | Figure | Source |
|---|---|---|
| US embedded finance transaction value, 2026 | More than $7 trillion, over 10% of US financial transactions | Bain & Company and Bain Capital |
| US platform and enabler revenue | $21 billion in 2021, projected $51 billion in 2026 | Bain & Company and Bain Capital |
| US embedded consumer payments, 2026 | About $3.5 trillion | Bain & Company and Bain Capital |
| US embedded banking and cards revenue, 2026 | About $11 billion | Bain & Company |
| Global embedded finance market, 2026 | About $156 billion, projected $454 billion by 2031 (23.8% CAGR) | Mordor Intelligence |
| Embedded banking share of the embedded finance market | 47.3%, the largest single segment | Future Market Insights |
Market size estimates vary widely because research firms define embedded finance differently, so treat any single number as a direction rather than a fact. What every estimate agrees on is the trend: more of the money people and businesses move now runs through software companies, not bank apps.
For a US platform, that shift raises a practical question. If your customers already manage their work, sales, or payroll inside your product, are they also going to want to hold and spend money there? For a growing number of platforms, the answer is yes, and the ones that move carefully now will have a head start on the ones that wait.
Benefits of Embedded Banking for Businesses and Customers
Embedded banking gives platforms a new revenue line and stickier customers, and it gives users faster access to their money with fewer apps to juggle. Partner banks win too, because they gain deposits and distribution without building a consumer brand.
For the platform
- New revenue. Card interchange is the main source for most programs. Banks under $10 billion in assets are exempt from the federal cap on debit interchange, which is one reason so many sponsor banks are community banks. Account fees, instant payout fees, and premium tiers can add to it.
- Better retention. A customer who keeps their operating balance inside your software is far less likely to switch to a competitor.
- Richer data. Seeing cash flow helps you understand customers, spot churn risk early, and later offer products like working capital.
- Faster payouts. For marketplaces and gig platforms, paying people instantly into an in-app account is cheaper and quicker than pushing funds to outside banks.
For the customer
- Money lands where the work happens, often minutes after a sale or a shift.
- Fewer logins, fewer transfers, and less manual reconciliation for small businesses.
- Access to accounts and cards for people who find traditional banks slow or hard to reach.
None of this happens automatically. The revenue depends on card volume, and the retention depends on the feature actually solving a problem your users have today.
Embedded Banking Risks and US Regulation After Synapse
The biggest risk in embedded banking is not a hack or a bad feature. It is records that do not match. The collapse of Synapse in 2024 showed what happens when the brand, the middleware provider, and the bank each keep their own version of who owns what.
Synapse was a BaaS middleware company that connected fintech apps to several partner banks. When it filed for bankruptcy in April 2024, more than 100,000 consumers were locked out of roughly $265 million in deposits. The court-appointed trustee, former FDIC Chair Jelena McWilliams, later found a gap of $65 million to $95 million between what Synapse said customers were owed and what the banks held. Many people who believed their money was FDIC insured learned that pass-through insurance only protects you if a bank fails, not if a fintech middleman loses track of balances.
Regulators responded quickly. Several sponsor banks came under enforcement actions, including a Federal Reserve cease-and-desist order against Evolve Bank & Trust in June 2024. In September 2024, the FDIC proposed a rule that would require banks holding custodial accounts with transactional features to keep records of each beneficial owner and reconcile balances at least daily. This builds on the 2023 interagency guidance on third-party risk, which makes banks responsible for overseeing the fintechs and vendors they partner with.
What this means for anyone launching an embedded banking product today:
- Keep a ledger you can reconcile every day. Assume your bank partner will ask for daily, transaction-level data, because many already do.
- Describe deposit insurance accurately. Say that funds are held at a named FDIC-insured partner bank, and never imply that your company is a bank. FDIC rules on misrepresenting deposit insurance now apply to digital and mobile channels.
- Do real due diligence on partners. Look at your sponsor bank’s regulatory history and your BaaS provider’s financial health, not just their API docs.
- Plan your exit before you need it. Know how customer accounts would move to another bank or provider if a partner relationship ends.
- Budget for compliance people, not just code. BSA and AML monitoring, complaint handling, and Regulation E dispute processes are part of the product.
How to Launch Embedded Banking: A Step-by-Step Guide
To launch embedded banking, start with a clear customer problem, choose a sponsor bank and BaaS partner you can trust, design compliance and ledgering in from the start, then build, test with a small pilot group, and grow carefully. Here is the process we see work for US platforms.
- Start with the customer problem. Decide exactly who the product is for and what pain it removes, such as slow payouts, scattered business balances, or manual vendor payments. A feature that solves a real problem earns adoption, while a generic bank account inside an app usually does not.
- Pick the first product and keep it narrow. Most programs launch with one thing, such as an account with a debit card or instant payouts, and add bill pay or lending later. A narrow launch shortens bank approval and keeps compliance manageable.
- Choose your sponsor bank and BaaS partner. Compare pricing and APIs, but spend more time on the bank’s regulatory standing, the provider’s financial stability, and who keeps the system-of-record ledger. Ask directly how they reconcile balances and how often.
- Map out compliance before you write code. Work with the bank on KYC and KYB requirements, AML monitoring, customer disclosures, complaint handling, and Regulation E disputes. Get marketing language, including anything about FDIC insurance, approved early.
- Design the ledger and reconciliation. Decide whether you, the provider, or the bank holds the master ledger, and build daily reconciliation into the system from the first sprint. This is the piece that protects your customers if anything goes wrong.
- Build and integrate. Connect account, card, and payment APIs, build onboarding and in-app money flows, set up webhooks and fraud rules, and design support tools for your team. Security testing and audit logging belong in this phase, not after launch.
- Pilot, then expand. Launch to a small group of customers, watch reconciliation, fraud, and support tickets closely, and fix what breaks. Widen access only when the bank and your team are comfortable with the numbers.
Most teams underestimate steps 4 and 5. The code for an account screen is quick to build, while the controls behind it are what the bank, and eventually the regulator, will examine.
Build vs Partner: Choosing the Right Embedded Banking Setup
Most US platforms build embedded banking on top of a BaaS provider rather than connecting directly to a bank, then bring in an experienced fintech engineering team to build the product layer. The right mix depends on your volume, timeline, and how much control you need.
There are three common setups:
- A full-stack BaaS platform with ready-made components. This is the fastest route to launch, with pre-built onboarding and account screens. The trade-off is less control over the experience and higher per-account costs as you grow.
- An API-first BaaS provider plus a custom product build. This is the most common path. The provider handles the bank connection and core ledger, while your team builds a custom experience that fits your platform.
- A direct sponsor bank integration. This gives you the most control and the best economics at high volume, but it also brings the heaviest compliance load. It usually makes sense only once a program is large and proven.
Whichever setup you choose, someone still has to build the product: onboarding flows, in-app money movement, card controls, admin tools, reconciliation jobs, and the monitoring behind them. Here is how the main options compare for US teams.
Table 5: Best ways to staff an embedded banking build
| Option | Time to start | Relative cost | Fintech and compliance experience | Management | Best for |
|---|---|---|---|---|---|
| Rocketeams (managed fintech engineering team) AFFORDABLE & RELIABLE |
Profiles in 48 to 72 hours, engineers active in about 2 weeks | About 1/3 of US rates, 2-week trial with no upfront payment | Engineers experienced with KYC, AML, and PCI DSS work, including a BBVA-backed digital banking platform | Dedicated project lead, sprint governance, code reviews, payroll | Affordable, reliable teams working inside your roadmap |
| US in-house team | 45 to 60+ days per hire | Highest, about $170,000 to $190,000 per engineer with benefits | Depends on who you hire | You manage everything | Long-term ownership of core banking IP |
| US fintech development agency | 2 to 6 weeks | High, project-based pricing | Usually strong | Agency-led | Fixed-scope builds with a large budget |
| General offshore agency | 2 to 4 weeks | Low to medium | Often limited in regulated finance | Agency-led, less visibility | Non-regulated parts of the product |
| Freelancers | A few days | Varies widely | Rarely deep | You manage everything | Small UI tasks, not core money movement |
We have seen what regulated delivery takes firsthand. On Azlo, a BBVA-backed digital bank for small businesses, our engineers worked under KYC, AML, and PCI DSS constraints to improve CI/CD, migrate data from MongoDB to PostgreSQL, and ship features such as online credit and invoice automation. If you are planning an embedded banking product, our fintech engineering teams can join your roadmap in days, or we can own the build end to end through our product development services. For a broader look at evaluating vendors, see our guide to choosing a fintech software development company in the USA.
Frequently Asked Questions
What is embedded banking in simple terms?
Embedded banking means getting banking features, like an account, a debit card, or instant payouts, inside an app or platform that is not a bank. A licensed partner bank holds the money behind the scenes, while the brand you already use handles the experience.
What is an example of embedded banking?
Shopify Balance is a well-known example. Merchants hold their sales revenue in an account inside Shopify and can spend it with a card, without opening a separate business bank account. Lyft Direct, which gives drivers a debit card for their earnings, is another.
What is the difference between embedded banking and embedded finance?
Embedded banking is a subset of embedded finance. Embedded finance covers any financial product inside a non-financial platform, including payments, lending, and insurance, while embedded banking focuses on core banking features such as accounts, cards, and money transfers.
What is the difference between embedded banking and banking as a service?
Banking as a service is the infrastructure, meaning the bank partnerships and APIs that make banking features available to other companies. Embedded banking is the product a brand builds on top of that infrastructure and offers to its own customers.
How is embedded banking different from open banking?
Open banking is about sharing data from accounts people already hold at their bank with other apps, with their consent. Embedded banking creates new accounts and cards inside a non-bank platform. One moves data between existing accounts, the other delivers banking products in a new place.
Is money in an embedded banking account FDIC insured?
It can be, through pass-through insurance, when funds are held at an FDIC-insured partner bank and the records correctly show who owns each balance. That insurance protects against the bank failing, not against a fintech or middleware provider failing, which is why accurate ledgers matter so much.
Do I need a banking license to offer embedded banking?
No. Most US companies partner with a chartered sponsor bank, usually through a BaaS provider, so they do not need their own charter. You still have to meet the bank’s compliance requirements, and some products, such as money transmission, can bring state licensing obligations.
How do companies make money from embedded banking?
The main revenue source is card interchange, the fee a merchant pays each time a customer uses the card. Platforms can also earn from instant payout fees, premium account tiers, and lending products built on top of the account.
How long does it take to launch an embedded banking product?
Timelines usually run from a few months to a year. Bank approval, compliance reviews, and partner onboarding tend to take longer than the engineering itself, so starting those conversations early is the best way to shorten the schedule.
How much does it cost to build embedded banking?
Costs depend on BaaS platform fees and minimums, sponsor bank program fees, KYC and card issuing costs, compliance staff, and engineering. Engineering is often the largest controllable cost, and managed teams like Rocketeams cost about a third of US rates for comparable seniority. Early-stage teams can follow our playbook on IT staff augmentation for startups to keep the build lean.
Conclusion
The platforms that do well with banking features are the ones that treat them as part of their core product, not a side project. They pick a narrow first use case, choose partners with a clean regulatory record, and build reconciliation and compliance in from the first sprint instead of patching it in after launch.
If you are planning an embedded banking product for US customers, Rocketeams can help you build it properly. Our fintech engineers have shipped regulated banking features under KYC, AML, and PCI DSS requirements, and they join your team in under 100 hours at about a third of US rates, with a two-week zero-risk trial. Talk to our fintech team to plan your embedded banking launch and get vetted engineer profiles within 72 hours.
