Embedded-finance architecture: from regulated partner to customer experience

Embedded finance means offering financial functionality — accounts, payments, cards — inside a non-financial product, so the customer experiences it as part of your brand. Architecturally, it separates three roles: the distributor who owns the customer relationship, the regulated entity that holds the permissions and carries regulated responsibility, and the technology platform that connects them. The common mistake is to treat the embedded experience as if it removed the underlying obligations. It does not: safeguarding, disclosures, complaints and compliance still apply, and each layer needs an explicit owner. This guide gives a layered view so you can assign ownership before you build.

Legal and regulatory status was reviewed on 7 July 2026.

Embedded-finance definition

Embedded finance is the delivery of regulated or near-regulated financial services within another company’s product. The customer sees your brand; behind it, a regulated entity provides the permissions and a platform provides the connectivity. Defining the model precisely — who does what — is the foundation for everything below, and it is why choosing an EMI or BaaS provider is a prerequisite rather than a detail.

Customer-facing distributor

The distributor owns the customer relationship, the interface and the brand. It typically operates as an agent, distributor or programme partner rather than holding an authorisation itself. Owning the experience does not transfer regulated responsibility to the distributor, but it does create obligations around fair presentation, disclosures, support and complaints.

Regulated entity

The regulated entity — a bank, EMI or PI — holds the permissions and carries the regulated responsibility for the financial activities 1 2. Identify this entity precisely: which legal entity, in which country, authorised for which activities. The brand on the app is rarely the regulated entity, so this must be established in writing.

Technology platform

The technology platform connects the distributor to the regulated entity, providing APIs, orchestration, dashboards and tooling. A platform may or may not itself be regulated; often it is a technical service provider outside the regulated perimeter for the financial activities. Knowing whether the platform is regulated for a given activity is essential to mapping responsibility.

Accounts

Accounts determine how customer funds are held and presented. The choice between named accounts, virtual IBANs and pooled accounts drives reconciliation, presentation and safeguarding, and should be decided deliberately — see named accounts, virtual IBANs and pooled accounts and the add accounts and IBANs stack.

Ledger

The ledger records entitlements — who is owed what — independently of where funds physically sit. In pooled models the ledger is the source of truth for customer balances, so its accuracy and reconciliation are critical. The relationship between core systems, ledgers and payment hubs is explored in core banking vs ledger vs payment hub.

Payments

Payments cover which rails and schemes are reachable, in which currencies, and with what cut-offs and value dates. Confirm how each rail is accessed — directly by the regulated entity or indirectly through another institution — because indirect access adds dependencies and constraints.

Cards

If the product issues cards, establish which entity is the card issuer, which scheme is used, and how the programme is managed. Card issuing typically involves an issuer, a processor and a programme arrangement, and the regulated responsibility sits with the licensed issuer rather than the distributor.

KYC and KYB

Know-your-customer and know-your-business processes verify individual and business identities at onboarding. Using the platform’s or regulated entity’s tools does not transfer the regulated entity’s legal responsibility. Document who performs each step and who is accountable, and align this with your compliance framework.

Transaction monitoring

Transaction monitoring watches activity for suspicious patterns after onboarding. As with KYC and KYB, the tooling can be provided by a platform, but accountability rests with the regulated entity. Define what alerts you handle, what the regulated entity handles, and how cases are escalated.

Fraud

Fraud controls overlap with, but are distinct from, financial-crime monitoring: they focus on preventing unauthorised or fraudulent transactions. Decide where fraud rules live, who tunes them, and how the distributor and regulated entity coordinate during incidents.

Customer support

Customer support is usually delivered by the distributor because it owns the relationship, but some issues — disputes, regulated complaints, account restrictions — must route to the regulated entity. Map which queries you handle and which must be escalated, with agreed timelines.

Complaints

Regulated complaints often carry specific handling and record-keeping expectations that sit with the regulated entity. The embedded experience does not remove these; it makes routing and record-keeping between distributor and regulated entity more important. Agree the complaints process explicitly.

Disclosures

Customers must receive accurate disclosures about who provides the service, how funds are protected, and the terms that apply. Embedding the experience does not remove disclosure obligations — for example, funds should not be described as deposit-insured when they are safeguarded. Get disclosure wording reviewed.

Reconciliation

Reconciliation ties the ledger of entitlements to the funds held in legal accounts. In embedded models with pooled accounts, daily reconciliation is essential to demonstrate what is owed to each customer and to catch shortfalls early. Define the reconciliation cadence and exception process before launch.

Safeguarding

Where the regulated entity is an EMI or PI, relevant customer funds must be safeguarded 1 2. Safeguarding does not disappear because the experience is embedded, and it is not a deposit-guarantee scheme. Understand where funds are safeguarded and how — see how safeguarding works.

Data ownership

Establish who controls customer and transaction data, on what legal basis it is processed, and what each party may do with it. Personal-data processing is governed by the GDPR, and roles such as controller and processor should be defined in the contract 4. Data ownership also affects portability at exit.

Outsourcing and DORA

Relying on a platform and a regulated partner is a form of outsourcing, which brings digital operational resilience into scope. DORA has applied since 17 January 2025 and covers ICT risk management, incident management and reporting, resilience testing, ICT third-party risk and information-sharing 3. Critically, DORA does not make outsourcing responsibility disappear: the regulated financial entity remains responsible for its obligations even when functions are delegated to a provider. Assess DORA implications across the whole chain, not just your own systems.

Responsibility matrix

Function	Distributor	Regulated entity	Technology platform
Customer relationship and brand	Owns	—	—
Regulated permissions	—	Holds	—
Accounts and ledger	Configures use	Accountable	Provides tooling
Payments and cards	Uses	Accountable	Provides connectivity
KYC, KYB, monitoring	Supports	Accountable	Provides tooling
Safeguarding	—	Accountable	—
Complaints and disclosures	Routes/presents	Accountable	—
Data protection	Controller/processor as agreed	Controller/processor as agreed	Processor as agreed

Populate this matrix with the specific entities in your chain; the table is a template, not a legal allocation.

Modular versus bundled model

A bundled model sources most layers from one provider, simplifying integration but concentrating dependency and exit risk. A modular model assembles best-fit providers per layer, increasing flexibility and reducing single-vendor lock-in at the cost of more integration and coordination. Neither is universally better; choose based on your scale, roadmap and risk appetite.

Launch sequence

• Regulated entity and its permissions identified and verified in an official register
• Responsibility matrix completed and signed off across all three roles
• Account and ledger model chosen with reconciliation designed
• Compliance split (KYC, KYB, monitoring, fraud) documented and aligned
• Safeguarding arrangement understood and disclosed accurately to customers
• DORA and ICT third-party risk assessed across the chain
• Data-protection roles and bases agreed in the contract
• Exit and data-portability terms negotiated before go-live

Unit economics

Model the all-in cost across setup, monthly minimums, per-transaction, per-account and card fees, FX, and charges for returns or investigations, alongside any reserve or prefunding requirements. Embedded models can hide costs in minimums and liquidity terms, so model expected and stressed volumes. See fintech provider due diligence and RFP for a structured approach.

Exit and migration

Negotiate exit before launch: what data you can export, in what format and over what period, and how customer balances, mandates and card programmes migrate. Providers rarely offer favourable exit terms once you are live and dependent. Exit planning is easier in modular models but must be explicit in either case. The launch an embedded-finance product stack sets out the build in sequence.

Questions to ask providers

• Which legal entity is the regulated provider for each activity, and where can we verify it?
• Which layers are provided by a technology platform outside the regulated perimeter?
• How are customer funds held (account model) and safeguarded?
• How is the compliance split defined, and what remains our responsibility?
• How do complaints, disclosures and support route between us and the regulated entity?
• How are DORA and ICT third-party risk addressed across the chain 3?
• Who is controller and who is processor for personal data 4?
• What are the exit, data-portability and migration terms?

Common failure modes

• Assuming the embedded experience removes safeguarding, disclosure or complaints obligations.
• Failing to identify the specific regulated entity behind each activity.
• Leaving compliance responsibilities vague or assuming they transfer to the platform.
• Treating DORA as the provider’s problem when the regulated entity remains responsible 3.
• Neglecting reconciliation between the ledger and safeguarded funds.
• Discovering exit and data-portability terms only after go-live.

What this does not cover

This guide describes an architecture and how to allocate responsibility; it does not confirm which entity or model you need, and it does not conclude that any structure is compliant. It is general information, not legal, regulatory or tax advice, and it does not assess or rank any provider. Specific obligations depend on jurisdiction, the entities involved and the activities performed.

FAQ

Does embedded finance remove regulated obligations?

No. Embedding the experience changes who the customer sees, not whether obligations apply. Safeguarding, disclosures, complaints and compliance still apply and must have an explicit owner 1.

Who is responsible under DORA in an embedded model?

DORA has applied since 17 January 2025 and covers ICT and third-party risk, but it does not make outsourcing responsibility disappear. The regulated financial entity remains responsible for its obligations even when functions are delegated 3.

Is the technology platform the regulated entity?

Often not. The platform frequently acts as a technical service provider outside the regulated perimeter, while a separate bank, EMI or PI holds the permissions. Confirm which entity is regulated for each activity.

Should I choose a bundled or modular architecture?

It depends on your scale and risk appetite. Bundled simplifies integration but concentrates dependency; modular adds flexibility and reduces lock-in at the cost of more integration work. Neither is universally better.

When should we plan data ownership and exit?

Before launch. Data-protection roles under the GDPR and exit and portability terms are far harder to negotiate once you are live and dependent on the providers 4.