Non-bank companies increasingly want banking capabilities inside their own products: balances, IBANs, payment initiation, statements, and card-linked accounts without becoming licensed banks themselves. That demand created Banking-as-a-Service (BaaS)—a model where technology platforms and authorized account providers combine so product companies can embed financial features in days or weeks rather than years.
Embedded finance is the customer-facing outcome: a marketplace, payroll platform, or creator app that lets users hold money, receive payouts, or pay suppliers without leaving the host experience. BaaS is often the delivery mechanism—the APIs, onboarding flows, ledger interfaces, and partner orchestration that make embedding technically and operationally feasible.
This article explains how modern BaaS and embedded finance infrastructure is structured, where regulated boundaries sit, and what product and compliance teams should evaluate before launching account features. It describes architectural patterns FinDech applies through Banking Core and related Cores, without assuming every integration or market is live or that FinDech itself holds customer funds.
This analysis connects to FinDech's Banking Core, part of the Seven Cores infrastructure model.
Embedded finance and BaaS: complementary, not interchangeable
Embedded finance describes distribution: financial capability appearing inside a non-financial product journey. A freelancer platform that pays contractors into in-app balances embeds finance. A retailer offering instalments at checkout embeds lending or credit. The user experience is native to the host brand; the regulated activity typically sits with a bank, electronic money institution (EMI), or other authorized provider.
Banking-as-a-Service describes supply: modular account, payment, and card infrastructure exposed through APIs and operational workflows. BaaS providers—often a combination of technology platform and licensed partner—handle onboarding hooks, KYC handoffs, account provisioning, transaction posting, and reconciliation against partner systems.
Confusion arises when vendors use the terms interchangeably or imply that API access alone satisfies regulatory obligations. Product teams need both lenses: embedded finance for UX and go-to-market, BaaS for integration architecture and partner governance.
- Embedded finance optimizes for user context and conversion inside an existing product.
- BaaS optimizes for reusable account rails, partner abstraction, and operational scale.
- Neither term guarantees a specific licence type; structure depends on activity, jurisdiction, and partner.
The four layers of embedded banking infrastructure
Mature embedded banking stacks separate concerns into four layers. The product layer owns branding, pricing, entitlements, and customer support. The platform layer—what FinDech describes as Banking Core—owns account models, internal ledgers, balance derivation, statements, permissions, and reconciliation workflows. The partner layer holds regulated account services: IBAN issuance, safeguarding, settlement, and scheme connectivity where applicable. The compliance layer spans KYC, AML monitoring, sanctions screening, and reporting—often shared across Cores through cross-cutting controls.
The internal ledger is the product's record of truth for what the user sees: available, pending, and reserved balances; transaction history; and fee accruals. Partner systems hold authoritative records for safeguarded funds and regulatory reporting. Continuous reconciliation between ledger and partner statements is what keeps embedded experiences trustworthy when networks delay settlement or returns arrive asynchronously.
Weak architectures collapse these layers—hard-coding partner responses into UI logic or treating partner APIs as the only ledger. That works in demos and fails in production when chargebacks, recalls, or compliance holds require balance states the partner API does not expose cleanly.
1. Product surface
Accounts, wallets, and statements presented in the host application with brand-specific UX and business rules.
2. Platform ledger
Internal records, entitlements, and reconciliation that remain consistent even when partners or corridors change.
3. Authorized providers
Banks, EMIs, and account providers that hold client funds, issue IBANs, and perform regulated settlement.
4. Compliance orchestration
Identity, monitoring, and intervention workflows applied before and after money movement.
Partner boundaries: who holds funds and who holds liability
The central regulatory question in embedded finance is not which API vendor you choose but which entity is authorized to hold customer funds, execute payment services, and file regulatory returns. Technology platforms—including FinDech—typically develop orchestration, ledger, and product integration layers. They do not replace banks or EMIs unless separately licensed for those activities.
FinDech's Banking Core boundary is explicit: FinDech is not a bank and does not hold customer funds. Accounts, IBANs, safeguarding, and settlement are provided through banks, EMIs, and other authorized account providers. Product teams must map customer disclosures, complaints handling, and deposit protection messaging to the actual holder of funds—not to the software layer.
Contractual allocation matters as much as architecture. Master service agreements should clarify data processing roles, incident notification, audit access, and wind-down procedures if a partner exits a corridor. Embedded finance launches fail quietly when partner capacity changes and products lack failover routing or customer communication templates.
IBANs, local accounts, and multi-currency design
Users expect local account details—IBANs in Europe, sort codes in the UK, ACH details in the United States—when receiving salaries or invoice payments. BaaS infrastructure abstracts partner-specific account formats behind normalized account objects while preserving the identifiers payers need.
Multi-currency embedded accounts introduce FX, cut-off times, and safeguarding rules that differ by partner and jurisdiction. Platform design should separate currency wallets at the ledger level, track pending conversion states explicitly, and surface partner-specific settlement timelines in product copy to reduce support load.
Virtual IBANs and sub-account structures enable marketplaces and platforms to assign unique references to each counterparty without provisioning full account relationships per user. These patterns depend on partner capability and scheme rules; infrastructure should treat them as configurable features, not universal defaults.
Onboarding, limits, and account lifecycle
Embedded account onboarding stitches product registration with identity verification, sanctions screening, and partner account creation. Failures at any step produce partial states—verified identity without IBAN, or IBAN without spending permissions—that require idempotent retries and clear user messaging.
Tiered KYC is standard: light verification for low limits, enhanced due diligence for higher balances or business accounts. Banking infrastructure should express tiers as policy configuration shared across brands rather than hard-coded per app.
Account lifecycle events—closure, dormancy, death of account holder, funds return—are operational requirements often neglected until the first edge case. Platform workflows should support partner-initiated blocks, user-initiated closure with balance sweep, and audit trails for compliance review.
- Idempotent onboarding prevents duplicate accounts when users retry after network errors.
- Limit engines should compose product rules with partner and scheme constraints.
- Statement and receipt generation should pull from ledger truth, reconciled to partner records.
Connecting accounts to payments and cards
Embedded banking rarely stops at balances. Users fund cards, initiate SEPA or instant payments, and connect to open banking flows from the same account surface. Banking Core connects naturally to Payments Core for money movement and Cards Core for card programme integration—each with its own partner boundaries.
Orchestration across Cores prevents inconsistent limits: a user blocked from outbound payments should not fund a card through an alternate path unless policy explicitly allows. Risk Shield-style intervention layers evaluate sensitive actions before execution across account, payment, and card domains.
Settlement timing mismatches—card authorizations versus account debits, pending inbound transfers versus available balance—require product copy and ledger states that users can understand. Infrastructure should expose pending and reserved balances as first-class concepts, not hidden implementation details.
Evaluating BaaS and embedded finance partners
Partner selection should begin with permitted activities and target corridors, not API feature checklists. Confirm passporting or local authorizations, safeguarding arrangements, scheme memberships, and historical operational track record in your segments—consumer, business, or marketplace.
Technical evaluation covers webhook reliability, sandbox fidelity, idempotency support, reconciliation file formats, and escalation paths for production incidents. Operational evaluation covers onboarding SLAs, compliance review turnaround, and change notification for scheme or regulatory updates.
Avoid single-partner dependency without a documented migration path. Embedded finance products that grow across corridors often require multiple account providers; platform abstraction pays off when the second partner integrates in weeks instead of quarters.
Practical takeaways
Banking-as-a-Service and embedded finance infrastructure let product companies offer account experiences without becoming banks—but only when architecture respects partner boundaries, ledger design, and compliance orchestration.
Successful implementations separate product surfaces from platform ledgers, connect to authorized providers for fund holding and settlement, and reconcile continuously so users see accurate balances and histories.
Teams evaluating embedded banking should map regulatory roles before UX design, invest in multi-currency and lifecycle workflows early, and treat BaaS as a long-term partner governance discipline—not a one-time integration project.
