Embedded Finance and BaaS Security Guide

In embedded finance a customer opens an account or makes a payment inside a brand that is not a bank, while the regulated bank behind it may never see the customer directly, and security fails in the gaps between the parties. Banking as a service (BaaS) arrangements split the work between a sponsor bank, often a middleware platform, and the brand that owns the customer relationship, connected by APIs, API keys and shared ledgers. When the split of responsibilities for identity checks, fraud monitoring, records and credentials is unclear, money and data go missing. This guide is for security, fraud and risk teams at sponsor banks, BaaS platforms and fintech brands. It covers the responsibility split, the machine credentials that bind the parties, KYC and fraud controls across the chain, records and reconciliation, and what US supervisors said after the 2024 enforcement actions. General fintech security is in the Cybersecurity for Fintech Guide; this page covers only the multi-party BaaS model.

Key takeaways

The bank stays responsible. US agencies stated in July 2024 that using third parties "does not diminish" a bank's responsibility to comply with the law, even when compliance functions are shared.
Write the responsibility split down, control by control. KYC, sanctions screening, transaction monitoring, disputes, records and incident response each need one owner, one evidence source and a right of access for the bank.
API credentials are the trust boundary. The keys and certificates the fintech uses to call the bank or platform can move money. Treat them as privileged machine identities with mutual TLS or sender-constrained tokens, narrow scopes and fast revocation.
The ledger of record must be reconcilable. When a middleware platform keeps the end-user ledger, the bank must be able to rebuild who owns which funds without it.
Plan for a partner's failure. Contracts and technical designs should allow accounts, data and activity to move if a fintech or platform fails, as agencies recommended after 2024.

How the BaaS model is put together

Embedded finance places financial products (accounts, cards, payments, lending) inside a non-financial or fintech customer experience. BaaS is the supply side: a licensed bank exposes its products through APIs, sometimes directly and sometimes through a middleware platform that aggregates many fintech brands. The three common shapes have different security consequences.

Model	Parties	Who usually holds the end-user ledger	Main security exposure
Direct sponsor bank	Bank and fintech brand	Bank core or a bank-controlled sub-ledger	Fintech API credentials with broad scope; KYC done by the fintech under bank policy
Middleware platform	Bank, platform, many fintech brands	Platform, often with omnibus (for-benefit-of) accounts at the bank	Platform holds keys for many brands; records split across three parties; concentration on one platform
Fintech-led multi-bank	Fintech brand with several partner banks	Fintech ledger with accounts across banks	Many integrations, inconsistent controls between banks, complex reconciliation

The joint statement published by the Federal Reserve, FDIC and OCC on 25 July 2024 (Federal Reserve SR 24-5) lists the risks of these arrangements: reduced bank control where third parties run significant operations, fragmented operations across several third parties, limited bank access to records, third parties performing compliance functions such as customer identification, due diligence, suspicious activity monitoring and sanctions screening, multiple layers of subcontractors without direct contracts, and misaligned incentives that put growth ahead of compliance. The statement says it does not create new supervisory expectations, but it shows what examiners look for.

The responsibility split, control by control

Most failures start with an assumption that "the other party does that". The fix is a written responsibility matrix, attached to the contract, with evidence and access rights for each line. The example below shows a common allocation; your own will differ, but every row needs an owner.

Control	Typical performer	Bank must have	Evidence
Customer identification and due diligence (CIP/CDD)	Fintech or platform, using the bank's policy	Approval of the method, sample testing, direct access to identity records	Verification results per customer, exception logs
Sanctions screening	Platform or bank	Screening lists and thresholds it has approved	Screening logs, alert dispositions
Transaction monitoring and suspicious activity reporting	Shared: fintech flags, bank decides and files	Alert data in near real time, authority to freeze	Alert queues, case records
Fraud prevention (account takeover, mule accounts, first-party fraud)	Fintech front end, platform rules	Fraud loss and typology reporting	Fraud rule changes, loss data
Disputes and error resolution	Fintech customer service	Timeline monitoring against regulatory deadlines	Case ageing reports
Ledger and reconciliation	Platform or fintech	Daily reconciliation it can perform or verify independently	Reconciliation breaks and resolution
Security incident response	Each party for its own systems	Notification within agreed hours, joint playbook	Incident reports, post-incident reviews
API credential lifecycle	Issuer (bank or platform) and holder (fintech)	Inventory of every credential that can move funds	Credential register, rotation records

The same statement lists effective practices: governance and third-party risk management, recordkeeping, reconciliation with dual control and separation of duties, end-user identification, controls over deposit insurance representations, BSA/AML and sanctions programmes, operational resilience, contract terms defining roles, and contingency and exit plans. The underlying life cycle (planning, due diligence, contract negotiation, ongoing monitoring, termination) comes from the agencies' June 2023 interagency guidance on third-party relationships. See the Third-Party Risk Management Guide.

Where identity fits: the machine credentials that move money

In BaaS, the parties trust each other through machine identities. A fintech's backend calls the platform or bank API to open accounts, issue cards and initiate payments; the platform calls the bank core; webhooks flow back. Anyone who holds those credentials can act as the fintech for all of its customers.

Prefer sender-constrained credentials: Use mutual TLS client certificates or OAuth 2.0 with certificate-bound or DPoP tokens rather than static bearer API keys, so a stolen token cannot be replayed from elsewhere. The FAPI 2.0 profile used in open banking is a sound reference. See the mTLS Guide and the FAPI 2.0 Security Profile Implementation Guide.
Scope by capability and by programme: Separate credentials for read, account opening and money movement, and separate credentials per fintech programme, so one compromised key cannot touch every brand on a platform.
Bind money movement to limits enforced at the bank side: Per-credential velocity and value limits, allow-listed destination types and source IP restrictions are enforced where the fintech cannot change them.
Sign and verify webhooks: Webhooks that confirm payments or KYC results must be signed with a key the receiver verifies, with replay protection, or an attacker can forge status changes.
Own the inventory: Keep a register of every key, certificate and service account across the arrangement, with an owner on each side, expiry and a tested revocation path. See the Payment Service Provider NHI and Key Security Guide and the payment API keys leak response guide.

The OWASP API Security Top 10 2023 risks most relevant here are API1 Broken Object Level Authorization (one fintech reading another's accounts through a shared platform), API2 Broken Authentication, API5 Broken Function Level Authorization and API10 Unsafe Consumption of APIs (trusting partner responses without validation).

KYC and fraud across the chain

One standard, many front ends: The bank should set the identity verification standard and test samples from each fintech. Differences in onboarding strength between brands become the path mule networks choose. See the Identity Proofing and KYC Guide.
Share signals, not just alerts: Device, behavioural and account opening signals collected at the fintech front end are what the bank needs to judge an alert. Agree the data fields up front.
Watch for programme-level patterns: Clusters of new accounts receiving and forwarding funds quickly, or many accounts sharing devices or addresses, often show up only when the bank looks across a whole programme. See the Money Mule Detection Guide and the Account Opening and Application Fraud Guide.
Freeze authority: The bank must be able to block an account or a programme immediately without waiting for the fintech.

Records, reconciliation and partner failure

The joint statement notes that limited access to records can impair a bank's ability to determine its deposit obligations and delay end users' access to funds. This was the central problem in 2024, when the collapse of a middleware platform left end users unable to reach funds held at partner banks while ledgers were reconciled. The Federal Reserve's enforcement action against Evolve Bank & Trust on 14 June 2024 cited the lack of an effective risk management framework for fintech partnerships and insufficient BSA/AML and consumer compliance controls, and required stronger oversight, recordkeeping and consumer compliance procedures.

Daily independent reconciliation: The bank reconciles omnibus account balances against the end-user ledger every day, with breaks escalated and aged.
Bank-side copy of ownership records: A current extract of end-user identities and balances held by the bank, not only by the platform.
Tested transfer plan: Contract terms and a technical runbook for moving accounts, data and activity to another provider if a fintech or platform fails, as the statement recommends.
Accurate deposit insurance statements: The statement warns that misleading or incomplete marketing about deposit insurance, including pass-through coverage, can breach 12 CFR Part 328.

How to implement: a phased approach

Map the arrangement: List every party, subcontractor, API, credential, data flow and ledger. Identify where the system of record for end-user balances lives.
Agree the responsibility matrix: Use the table above as a starting point, attach it to each contract and give the bank access rights for every line.
Harden credentials first: Move money-movement APIs to mutual TLS or sender-constrained tokens, split credentials by capability and programme, and add bank-side limits. Run old and new credentials in parallel, then revoke the old ones; keep the old path available only for a defined rollback window.
Stand up shared monitoring: Feed fintech onboarding and transaction signals to the bank's monitoring, with agreed alert service levels.
Prove reconciliation and exit: Run daily reconciliation for a full cycle, then a tabletop and a technical test of moving one programme to a new provider.
Review continuously: Reassess each partner on growth milestones, product changes and incidents, not only annually.

Decision guidance

Direct integration or middleware: Middleware speeds launch for small banks but concentrates credentials and records. Choose it only if the bank keeps an independent ledger view and can switch platforms.
Who runs KYC: Letting the fintech run KYC gives better customer experience; the bank should then own the standard, the vendor approval and the testing.
Growth limits: The statement flags that operational capability can lag rapid growth. Banks can set account or balance caps per programme until controls are proven.
Small fintech, large bank: Expect the bank's requirements to drive your security programme. Build the credential inventory and incident plan before due diligence starts.

Detection and measurement

Reconciliation breaks: count and value of unreconciled items older than one business day.
Credential hygiene: percentage of money-movement credentials that are sender-constrained and rotated within policy.
KYC quality: exception rate in bank sample testing, by fintech programme.
Fraud and mule rate: confirmed mule or fraudulent accounts per thousand opened, by programme.
Alert latency: time from fintech signal to bank decision on high-risk alerts.
Exit readiness: date of the last tested transfer of a programme.

Log and alert on API calls from new IP ranges or certificates, money-movement requests above per-credential limits, bulk account reads across programmes, and webhook signature failures.

Framework mapping

Area	NIST CSF 2.0	NIST SP 800-53 Rev. 5	Other
Partner due diligence and contracts	GV.SC-05, GV.SC-06	SA-9, SR-6	Interagency TPRM guidance (June 2023)
Ongoing partner oversight	GV.SC-07	SA-9	Joint statement SR 24-5
API credentials and authentication	PR.AA-01	IA-9, SC-8	OWASP API Top 10 2023 API2
Authorisation between programmes	PR.AA-05	AC-3, AC-6	OWASP API Top 10 2023 API1, API5
Partner failure and exit	GV.SC-08	CP-2	Joint statement contingency practices

Common failure patterns

Shared compliance with no owner: Both sides assume the other is reviewing alerts, and suspicious activity goes unreported.
Platform-wide keys: One credential set used for every fintech on a platform, so a single leak exposes all programmes.
Ledger held only by the middleware: When the platform fails, the bank cannot say who owns the funds.
Static API keys in fintech code and CI: Long-lived keys that can move money end up in repositories and logs. See the API Key Management Guide.
Growth before controls: Programmes scale faster than monitoring and dispute handling, which the 2024 statement and enforcement actions both highlight.

Practitioner checklist

Attach a control-by-control responsibility matrix with bank access rights to every BaaS contract.
Keep a register of every credential that can read data or move money, with an owner on each side.
Use mutual TLS or sender-constrained tokens for money-movement APIs, scoped by capability and programme.
Enforce value and velocity limits per credential at the bank or platform side.
Sign and verify all webhooks, with replay protection.
Reconcile end-user ledgers against bank balances daily and hold a bank-side ownership extract.
Sample-test KYC by programme and share onboarding signals with bank monitoring.
Test the transfer of a programme to another provider before you need it.

Embedded Finance and Banking as a Service Security Guide: Splitting Keys, KYC and Accountability Safely