In an embedded finance arrangement — a retailer offering branded accounts, a payroll platform issuing cards, a marketplace extending financing — the compliance question is never whether the rules apply. They apply. The question is which company in the stack performs each obligation, which company pays when it fails, and which obligations the regulators will trace back to a specific party no matter what the contract says.

The short version: the chartered bank cannot contract away its regulatory accountability, the nonbank cannot assume the contract protects it from direct liability, and the program agreement is where the two facts collide. Reading that agreement as a compliance-allocation document, not just a commercial one, is the core skill.

The typical stack, and why the labels matter

Most embedded finance programs involve three roles, sometimes compressed into two companies. The brand owns the customer relationship and the interface. The program manager (or middleware provider) builds the product operations: onboarding flows, ledgering, card processing connections, compliance tooling. The bank holds the charter — and with it, deposit insurance, payment system access, and the ability to lend on a national footprint.

Regulators see this stack from the top down through the bank. Under the interagency third-party risk management guidance the Federal Reserve, FDIC, and OCC finalized in June 2023, a bank's use of third parties does not diminish its responsibility to operate in a safe and sound manner and in compliance with applicable law. Practically, that means the bank must underwrite, monitor, and be able to control its fintech partners — and examiners judge the bank on how well it does so.

What the bank keeps no matter what the contract says

Certain accountabilities remain with the chartered institution even when the day-to-day work is performed by a partner:

  • Bank Secrecy Act and anti-money-laundering program obligations for accounts and transactions on the bank's books, however much of the KYC workflow the program manager operates
  • Safety-and-soundness expectations, including knowing where customer funds are at all times and reconciling program ledgers against actual account balances
  • Compliance with consumer financial law for products offered through the bank — the bank is examined on the program's disclosures, error resolution, and fee practices
  • Oversight duties under the third-party guidance: due diligence before signing, contractual audit rights, ongoing monitoring, and a workable exit plan
  • Accuracy of deposit insurance representations connected to the bank's products

Watch out: Ledger reconciliation is not a back-office detail. Public failures in this market have turned on gaps between a program manager's ledger and the bank's records, leaving end users unable to access funds while ownership was sorted out. Ask precisely who maintains the system of record, how often it reconciles to the bank ledger, and what happens to that data if the program manager fails.

Reading the program agreement as a risk map

A well-drafted program agreement answers the ownership question task by task. The table below shows the pattern seen in many programs — as a reading guide, not a market standard, because allocations genuinely differ deal to deal.

Common allocation of compliance tasks in embedded finance programs (illustrative)
TaskOften performed byAccountability anchor
Compliance policies and program approvalBank drafts or approves; program manager implementsBank
Customer identification and onboardingProgram manager or brand runs the flow under bank-approved standardsBank (BSA/AML)
Transaction monitoring and suspicious activity reportingShared tooling; bank files reportsBank
Consumer disclosures and marketing reviewBrand produces; bank approvesBank and nonbank both exposed
Complaints, disputes, and error resolutionProgram manager or brand front-line; bank oversightBank and nonbank both exposed
Data security and incident responseEach party for its own systems, with notice dutiesContractual plus each party's own law

Beyond the allocation grid, four contract mechanisms deserve the closest reading: audit and examination access (regulators can examine the service providers of a bank, and the contract should anticipate it), indemnification and its carve-outs, compliance change management (who absorbs the cost when a rule changes), and termination and wind-down (what happens to customers, funds, and data when the program ends).

Where the nonbank is directly on the hook

Fintechs sometimes assume the bank's charter is an umbrella. It is not. Several exposure paths run straight to the nonbank:

  1. UDAAP. The prohibition on unfair, deceptive, or abusive acts or practices applies to covered nonbanks in their own right, and the CFPB has authority over many nonbank providers of consumer financial products, including through supervision of larger participants in some markets.
  2. Deposit insurance misrepresentation. FDIC rules restrict how anyone — including nonbanks — represents deposit insurance coverage. Saying or implying that the fintech itself is insured, or blurring when pass-through insurance applies, is an enforcement risk aimed directly at the brand. The FDIC publishes current guidance on official sign and advertising requirements.
  3. State licensing. Depending on the funds flow and product, the nonbank may need money transmitter, lending, servicing, or collection licenses in its own name. State regimes vary; an allocation clause in the program agreement does not substitute for a required license.
  4. BSA status. Some program structures make the nonbank itself a money services business with FinCEN registration and program obligations, separate from the bank's — the analysis parallels the licensing one.
  5. Product-specific rules. Credit-like features pull in credit regulation questions regardless of which entity is named as lender — the classification debates in our articles on earned wage access and buy now, pay later products show how much turns on product design details.

Diligence to run before anyone signs

For the fintech side, diligence on the bank matters as much as the reverse. Ask how many programs the bank runs and how concentrated its fee income is in partnership business; whether the bank has public enforcement actions touching third-party oversight; how prescriptive its compliance manual is and how fast its approval cycles run; and what its regulator relationship means for onboarding timelines. A bank under an enforcement action may freeze new program launches for months — a commercial risk that never appears in the agreement itself.

Practical step: Before signing, walk one imaginary customer through the entire lifecycle — onboarding, funding, a disputed transaction, a complaint, an account closure with a balance — and write down which company performs each step and under whose policy. Any step without a clear owner is a future incident.

Quick answers

If the bank approves our marketing, are we safe from liability for it?

No. Bank approval is an oversight control, not a liability shield. A deceptive claim exposes the companies that made and disseminated it, and UDAAP liability can attach to the nonbank directly. Bank review reduces the chance of a violation; it does not reassign responsibility for one. Treat the bank's marketing review as a floor and maintain your own claims-substantiation practice.

Can end users' funds really be at risk if the bank is FDIC-insured?

Deposit insurance protects against bank failure, not against every failure in the stack. If a program manager's ledger cannot establish who owns what in a pooled custodial account, or the program manager itself collapses, users can face delays or shortfalls even though the bank never failed. The record-keeping arrangements behind pass-through insurance, and the reconciliation regime, are what determine how bad that scenario gets.

Does a program agreement eliminate the need for our own licenses?

No. Contractual allocation and regulatory obligation are independent. If your role in the funds flow or the credit product triggers a state licensing requirement, that requirement applies to you regardless of what the bank agreed to handle. The analysis is state-by-state and fact-specific, which is why funds-flow mapping is usually the first work product in embedded finance counsel engagements.

Who deals with the regulators when something goes wrong?

Formally, each regulator deals with the entities it has authority over: the bank's examiner works through the bank, the CFPB or FTC may contact a nonbank directly, and state regulators reach license holders. Practically, the program agreement's cooperation, notice, and information-sharing clauses determine how coordinated that response is — and poorly drafted ones leave partners pointing at each other mid-inquiry.

Where this leaves you

Map the funds flow and data flow first, because they drive both the contract allocation and each party's independent obligations. Read the program agreement as a task-ownership document and fill every gap before signing. Then build the compliance operation the contract assumes exists — policies, monitoring, complaint handling, reconciliation — because the agreement describes duties, it does not perform them. For the adjacent rulebooks that shape these programs, see our pieces on open banking data-access obligations and the rest of the Banking, Payments & Fintech pathway.