Buy now, pay later grew fast enough that regulators had to scramble to catch up. In 2025, the scramble produced real output: a CFPB interpretive rule that brought BNPL products structured as digital user accounts squarely under Regulation Z, state-level disclosure legislation in several markets, and renewed attention to how platforms that distribute BNPL products handle consumer complaints and dispute resolution. If you operate a platform and embed a deferred payment product through a third-party credit engine, the compliance picture looks different today than it did eighteen months ago.
This post is not legal advice, and the regulatory landscape continues to shift. What it is: a working summary of the changes that matter operationally for platform product teams, and the places where the compliance burden falls on you directly rather than on your credit provider.
The CFPB Interpretive Rule: What It Actually Covers
In May 2024, the CFPB issued an interpretive rule concluding that BNPL products structured as digital user accounts are "credit cards" under the Truth in Lending Act and therefore subject to Regulation Z's credit card provisions. This was the CFPB's formal position that the pay-in-four model does not sit outside consumer credit regulation simply because the product is framed as installment payments rather than a revolving line.
The Regulation Z credit card provisions that now apply include, at minimum: the right to dispute charges and receive provisional credit during dispute investigation, requirements to issue periodic statements, and prohibitions on requiring consumers to waive dispute rights as a condition of using the product. These requirements apply to the card issuer, which in a BNPL context is typically the lender, not the platform. But platforms that embed the product in their checkout flow and handle customer service for the transaction layer need to understand where dispute rights attach and what their obligations are in the dispute chain.
If a consumer disputes a charge with you (the platform) and the underlying transaction was funded by a BNPL product, your dispute handling workflow needs to connect to the lender's dispute process in a way that preserves the consumer's Regulation Z rights. A platform that resolves purchase disputes independently of the credit provider, without coordinating on provisional credit status, is creating compliance risk for both parties.
State-Level Disclosure Requirements
Several states moved ahead of federal action with disclosure requirements specific to BNPL products. California's Department of Financial Protection and Innovation issued guidance requiring certain BNPL providers to include specific rate and fee disclosures at the point of application. Colorado and Virginia have similar provisions either in effect or moving through their legislative process as of this writing.
For platforms that operate nationally and use a single checkout flow for all states, this creates a disclosure localization problem. The disclosure language required in California may not be identical to what a standard Regulation Z credit application requires at the federal level, and certainly may not be identical to what other state-specific disclosure requirements ask for. A checkout flow that delivers the same disclosure screen to all users regardless of their state of residence may be non-compliant in the states with specific mandates.
This is primarily the credit provider's responsibility to solve, but as a platform distributing the product, you control the UI that presents disclosures to the consumer. If your credit engine provider does not have a state-aware disclosure delivery mechanism, that gap lives in your checkout flow. Verify with your credit provider that their disclosure templates are reviewed for state-specific requirements and that they have a process for updating those templates as state law evolves.
Who Owns the Consumer Complaint Handling
One area that caught platforms off guard in 2024 and 2025 is consumer complaint routing. When a consumer files a complaint with the CFPB about a BNPL transaction, the complaint may be routed to the platform, the credit provider, or both, depending on the nature of the complaint. Platforms that thought they had cleanly delegated all credit-related complaints to their BNPL partner discovered that complaints about the transaction experience, delivery failure, or merchant non-performance also touch credit rights when the consumer wants to stop payment on goods not received.
The practical requirement is a documented escalation path from your platform customer service team to the credit provider's dispute intake function. That path should be specified in your program agreement and tested periodically. It does not need to be automatic or instantaneous, but it needs to exist and actually work. A consumer who calls your platform support line about a disputed BNPL charge should not reach a dead end where your team says "that's the lender's issue" without giving the consumer a path to the lender's dispute process.
Credit Reporting Obligations
BNPL products structured as digital user accounts under the CFPB's interpretive rule may carry credit reporting obligations under the Fair Credit Reporting Act when the lender reports to consumer reporting agencies. As a platform, you are not typically the furnisher of record. But if your program agreement requires you to provide performance data to the credit provider for reporting purposes, you need to understand what data elements they are using and ensure your data is accurate.
The more common issue for platforms is consumer expectations: a borrower who uses a BNPL product expecting it not to affect their credit may discover it does if the lender reports. Transparent disclosure at the point of application is the right answer, but it requires the platform's application UI to accurately represent the product's credit reporting behavior. If your credit engine provider reports to bureaus and your application flow says nothing about credit reporting, that is a disclosure gap that creates consumer trust risk and potential regulatory exposure.
What Changed for Platforms Using Third-Party Credit Engines
If you use a third-party credit engine to power a BNPL product, the primary regulatory entity is the lender. But as a platform that distributes the product, holds the consumer relationship, and controls the UX, you carry meaningful compliance obligations that do not fully transfer to the credit provider contractually. They include: accurate disclosure of product terms in the checkout UI, functional dispute escalation to the lender, accurate transmission of transaction and performance data, and clear representation of credit reporting behavior.
We are not saying that platforms are liable for their credit partner's compliance failures. Each party in the chain is responsible for its own obligations. The point is that some obligations fall on the platform by virtue of controlling the consumer touchpoints, regardless of how the program agreement allocates responsibility.
The practical compliance checklist for a platform operating a BNPL product today looks like this: confirm your disclosure UI is state-aware or has a process for becoming state-aware; confirm your dispute escalation path to the credit provider is documented and functional; confirm your program agreement specifies credit reporting behavior and that the checkout UI accurately describes it; and confirm your consumer data transmission to the credit provider is accurate and timely enough to support Regulation Z dispute timelines. None of these items require legal expertise to check. They require someone on the product team to own them.
Where Lendforge Fits in This Picture
Lendforge is a decisioning and origination engine, not a BNPL product directly. But we work with platforms building deferred payment products, and the credit infrastructure we provide needs to support the compliance requirements that flow from the product structure the platform chooses. That means our adverse action reason codes need to be Regulation Z-compliant, our dispute audit trail needs to support provisional credit workflows, and our disclosure API outputs need to carry the data fields your disclosure templates require.
As the regulatory environment for BNPL continues to develop, we track these requirements and update our compliance tooling accordingly. If you are building a deferred payment product and have questions about how specific regulatory requirements interact with the decisioning layer, that is a conversation we have regularly with product and compliance teams. The regulatory picture is not simple, but it is navigable if you start from a clear understanding of which obligations belong to which party in the program chain.