Embedded finance — credit, payments, and account features dropped into non-financial apps through partner modules — made the checkout button a regulated product, and the CFPB's interpretive rule of May 2024 settled the headline question for the biggest category: buy-now-pay-later providers are credit card issuers under Regulation Z for the purposes of its dispute-resolution and refund duties, importing statement obligations, error-resolution mechanics, and the fee-discipline framework into a product class that grew up calling itself checkout technology. For the host app, the rule and the broader supervision of embedded products convert a UX partnership into a compliance-ownership question the app cannot outsource.
3G Times publishes information, not legal advice. Embedded-product structure turns on charters, partnerships, and marketing roles, and belongs with counsel.
Who owns what in an embedded credit module?
The architecture splits cleanly on paper: the bank or licensed lender holds the credit decision and the regulatory file; the technology provider runs origination, servicing, and the interface; the host app contributes distribution, brand, and the customer relationship. Compliance ownership follows the customer's perception and the marketing's reality — the supervision's consistent position. When the host app's brand fronts the credit offer, UDAAP exposure for the offer's claims sits with the brand the consumer trusted, whatever the flow-downs say. When the host app controls the data pipelines feeding underwriting, fair-lending exposure for those inputs arrives through the partner bank's diligence. And when the dispute lands in the host app's support queue, the error-resolution clocks have already started — the 2024 interpretive rule's practical effect is that the consumer's complaint path, wherever it begins, must reach Regulation Z mechanics at Regulation Z speed.
| Embedded duty | Owning partner | Host app's residual |
|---|---|---|
| Credit decision, adverse action | Bank/lender | Marketing claims discipline |
| Disputes and refunds (Reg Z) | BNPL provider as issuer | Routing and SLA to the provider |
| Fair lending inputs | Bank/lender | Data lineage for model features |
| Privacy of shared data | Each party | Consent and label accuracy |
| Marketing and disclosures | Shared | Prominence and match to journey |
What did the interpretive rule change operationally?
Three mechanics, mapped from card issuerland to pay-in-four. Disputes: the consumer's right to assert a billing error — goods not delivered, wrong amount — now runs through investigation mechanics with timelines, rather than the refund-discretionary practice the category grew up with. Refunds: returned merchandise means credited installments or returned payments under the same discipline, ending the variance where one provider's app handled returns as customer-service favors. Statements and disclosures: periodic-information duties adapted to the installment structure, which the providers' 2024-2025 remediations rendered as in-app account documentation. The rule did not impose the card fee apparatus wholesale — late-fee structures in BNPL had already converged near zero under market and supervisory pressure — but it ended the category's central bet: that a credit product delivered as software answers to neither lineage.
How should a host app diligence the module?
As a product launch, not a SDK integration. The bank-partner question upstream: does the embedded lender hold the licenses and the program agreements that survive supervisory attention — the same file the host app's own bank partners will ask about when they see a credit module beside their deposit product. The claims inventory: every surface the app shows about the credit feature — button copy, checkout banners, promotional installments — reviewed for cost clarity under the prominence discipline, because drip-priced credit inside a shopping flow is the UDAAP fact pattern par excellence. The data contract: what the host app shares with the module (cart data, identity, device signals), under what consents, with what store-label consequences. And the complaint routing: tested end-to-end, because the dispute filed in the app's chat that never reached the provider is the violation wearing a support ticket number.
What comes after BNPL in the embedded stack?
The same question, asked of each layer: earned-wage-access modules drawing wage-access disclosure scrutiny; deposit-account embeds carrying the partner-bank's full BSA and Reg E file; investment embeds routing through the securities regime's solicitation and custody lines; insurance embeds meeting producer-licensing maps. The supervision's trajectory treats the embedding as irrelevant to the duty — the product is what it is, wherever the button sits — and the states layer their own innovations on top (the late-fee and earned-wage statutes of 2023-2025, varying by state). The host app's durable strategy is a single embedded-products compliance framework: inventory of modules, ownership map per module, claims gate per surface, and routing SLAs per duty — so the tenth embedded product inherits the program instead of inventing one.
What does this mean in practice?
- Diligence the lender like a bank partner — licenses, program agreements, prior supervisory findings — because your examiners and partners will.
- Gate every credit surface for cost prominence — the BNPL button is a credit offer, and the disclosure rules price it as one.
- Test the dispute path monthly — from the app's support entry to the provider's Reg Z clock, with the routing evidence retained.
- Keep the module inventory current — each embedded product, its owner, its regime, one map the whole program reads.
Embedded finance's premise was that distribution is the scarce resource and compliance is a service to plug in. The 2024 rule and everything since say the opposite: the button is the product, the product carries the statute, and the app whose brand sits on the checkout owns more of the file than the contract admits. The host apps that priced that ownership early are embedding at scale; the others are one dispute away from learning what the button was.
The synthesis for the roadmap: embedded products will keep arriving — payroll, insurance, identity, crypto — and each arrival asks the ownership question the BNPL rule just answered. The institutions that wrote the general framework (inventory, ownership map, claims gate, routing SLA) during the BNPL cycle will onboard the next wave as configuration; the ones that wrote a BNPL-specific patch will write the next patch, and the one after, always one interpretive rule behind.
How do refunds actually work under the rule?
Through the issuer mechanics: returned goods mean the installment plan adjusts — pending charges reversed, paid installments refunded — on the regulated timeline rather than the merchant's discretion. The host app's job is visibility: the return flow in the shopping interface must state the credit path honestly, because the customer's refund expectation formed in the host's checkout, not the provider's app.
Frequently asked questions
Does the interpretive rule apply to all embedded credit or just BNPL?
The 2024 rule addressed BNPL products specifically — pay-in-four and close variants — extending Reg Z's dispute and refund mechanics to them. Other embedded credit (instalment lending under state licenses, lines of credit) sits in its own existing regimes; the ownership analysis is the same.
Can the host app contract away UDAAP exposure for the module?
Exposure allocates; duty does not. The brand whose interface makes the claim answers for the claim, whatever the indemnity says — the flow-down is a cost-recovery mechanism, not a defense.
The data-sharing clause deserves its own diligence: the module's underwriting consumes host-app signals — cart composition, device data, behavioral patterns — and each signal's fairness profile becomes the bank partner's question at renewal. The lineage file that names every shared field, its purpose, and its review date is the artifact that keeps the embedding from becoming the fair-lending finding.
What is the single most common embedded-compliance failure?
Dispute routing: the consumer complains where they live — the host app — and the Reg Z clock the provider owes starts silently. The monthly routing test with retained evidence is the control that closes it.
For more context, read Alternative App Distribution After Epic and the DMA: What Fintech Distribution Maps Look Like Now.
For more context, read disclosure evidence mobile apps.
For more context, read banking chatbot compliance udaap.