BNPL Regulation: What the FCA Rules Mean for Your Platform

Paying in instalments is older than the credit card, but the version most shoppers know today started at a Swedish bookshop. Klarna processed its first transaction there in April 2005, letting customers pay after their order arrived or split the cost into parts. When its founders first pitched the idea as "buy now, pay later," the jury turned them down.

The model spread across Europe, Australia, and the US anyway, because it solved a problem merchants cared about: getting shoppers through checkout. Plans were interest-free, approval took seconds, and the merchant paid most of the cost. To the shopper it felt like a payment option rather than a loan. That's also why, for most of its history, BNPL sat outside the consumer credit rules that govern cards and personal loans.

The scale is now hard to ignore. In the UK alone, BNPL lending grew from £0.06bn in 2017 to over £13bn in 2024, according to the FCA (2026).

One in five UK adults, or 10.9 million people, used BNPL in the 12 months to May 2024, according to the FCA Financial Lives survey (2024).

Once a payment option reaches that many people, regulators stop treating it as a checkout feature. Over the past 18 months, three of the four markets below have brought BNPL under credit rules, and one has stepped back:

• Australia: BNPL providers have needed an Australian credit licence since 10 June 2025. Low cost contracts can use a lighter set of responsible lending obligations (ASIC, 2025).
• United Kingdom: The FCA began regulating BNPL as deferred payment credit on 15 July 2026.
• European Union: The revised Consumer Credit Directive applies from 20 November 2026 and brings many BNPL products under EU consumer credit rules (European Commission, 2026).
• United States: The CFPB went the other way. On 12 May 2025 it withdrew its 2024 interpretive rule, which had treated BNPL lenders like credit card issuers (CFPB, 2025).

The UK is the newest of these regimes to take effect. Lenders now need FCA permission to offer deferred payment credit. The product itself must include affordability checks, clear upfront information, support for customers who fall behind, and a route to the Financial Ombudsman Service. Three months on, firms with temporary permission are working toward a full authorisation deadline in January 2027, and most of what's left to do has nothing to do with legal drafting.

The legal reading belongs with your counsel. This guide covers the other half of the work: where each requirement lands in your product, from the decision to lend through to the complaint that might follow it. That's the part we know best, after two decades of building regulated payment systems, including instalment payments built at the processor level.

What Changed in 2026

The Government legislated in July 2025 to bring deferred payment credit (DPC) inside the FCA's perimeter. The regulator published its final rules in Policy Statement PS26/1 on 11 February 2026, and regulation day followed five months later.

The regulator was clear about what it was trying to prevent. Sarah Pritchard, the FCA's deputy chief executive, said: "We want the Buy Now Pay Later sector to thrive [...] no one should be lent to if they're unable to repay, because that could worsen their financial situation."

Each protection in the new regime corresponds to a part of the product that has to change:

Who Is in Scope and Who Is Not

The rules cover interest-free credit repaid in 12 or fewer instalments within 12 months, where the lender and the merchant are different businesses. They also cover arrangements where the lender becomes the legal supplier of the goods or services. Several arrangements sit outside that line:

• Merchants' own credit: Retailers that offer instalments directly, with no third-party lender involved, remain exempt under a Government decision made in 2024.
• Broking: Introducing or arranging DPC agreements isn't a regulated activity. That's relevant for the retailers and platforms that present a lender's plan at checkout.
• Earlier agreements: DPC agreements signed before 15 July 2026 stay unregulated, and lenders can keep servicing them.
• Specialist cases: Insurance premium finance, employee lending, and some lending by registered social landlords are excluded.

The edges of these definitions are where legal advice earns its fee. A plan that stretches past 12 instalments or 12 months is no longer DPC at all; it falls under the wider consumer credit rules. Any structure that blurs who is lending and who is supplying needs a careful read before it reaches your developers. For ticketing and event platforms that run their own payment plans, the merchant exemption is the first clause to check.

We cover the commercial case for instalments at the box office in Why Ticketing Platforms Should Offer BNPL.

The Authorisation Clock

Lenders already offering DPC on 15 July 2025 without the right permissions could register for the temporary permissions regime between 15 May and 1 July 2026. Fifteen firms appear on the FCA's temporary permission register (2026), from Clearpay to a group of Greater Manchester credit unions.

Temporary permission only bridges the gap. Firms in the regime have six months from regulation day to apply for full authorisation, so applications are due in January 2027. A lender that never entered the regime can't sign new DPC agreements until it's authorised.

An authorisation application asks a firm to describe how it runs the regulated activity. For DPC, much of that description concerns systems: how affordability decisions get made, how customers heading into difficulty are spotted, and how the firm checks that its product produces fair outcomes. Those answers are far easier to write, and far more convincing, when the systems already produce the evidence.

Affordability Checks Without Wrecking Conversion

BNPL earned its place at checkout by being fast. The new rules don't ask lenders to give that up, but they do ask for something in return. Every DPC transaction now needs a creditworthiness assessment, including purchases of £50 or less, under the same Consumer Credit sourcebook rules that apply to other regulated lending.

The FCA kept those rules outcomes-based. Lenders decide whether a transaction carries a material affordability risk. Where it doesn't, they aren't required to assess income and expenditure, and can rely on lending data, credit history, and open credit lines instead (Reed Smith, 2026).

That flexibility matters, because checkout friction has a measurable cost. Among US online shoppers who abandoned an order during checkout, 17% did so because the process was too long or complicated, according to the Baymard Institute (2025).

The catch is that "proportionate" isn't a technical specification. It's a judgment the lender has to be able to defend, transaction by transaction, to a regulator, an ombudsman, or a customer who says the plan should never have been approved. The engineering challenge is building a check light enough to keep the purchase moving and thorough enough to hold up afterwards.

Data Sources and Decisioning

A proportionate decision engine usually draws on some mix of the following, scaled to the risk of the transaction:

• Your own history with the customer: Past repayments, missed payments, and how long they've used your plans.
• Current exposure: The total the customer already owes you across open plans, which a single basket value won't show.
• Credit reference agency data: A wider view of the customer's commitments. It costs time and money on every call, so most designs reserve it for higher-risk decisions.
• Purchase context: Basket value, merchant category, and whether the customer is new to you or returning.

The practical answer is tiering. A small basket from a customer with a clean repayment record might clear on internal data alone. A larger basket, or a customer whose open balances keep climbing, moves up to a bureau check or a request for income information. Where those thresholds sit is a risk appetite decision, and it will change as the firm learns, so the thresholds belong in configuration that a credit team can adjust without waiting for a software release.

One detail links decisioning directly to disclosure. The key product information shown before the agreement has to say whether the lender will, or may, obtain information from a credit reference agency. If the engine only calls a bureau above a certain threshold, the wording at checkout has to reflect that accurately. That means product, legal, and engineering teams need to agree on a single source of truth for when bureau calls happen.

Latency deserves its own design work. Bureau calls can be slow or unavailable at the worst possible moment, and the engine needs a defined fallback for when that happens. The fallback could be to decline, to approve a lower limit, or to queue the decision. Whichever option you choose, it's a lending decision in its own right and should be documented as one.

Keeping a Record of Why You Said Yes

When a customer complains that a plan was unaffordable, the lender's answer is only as good as its record of the decision. The same record feeds the authorisation application and the outcome monitoring the Consumer Duty expects. Too many lending platforms log the outcome of a decision and little else.

For each decision, a defensible record captures:

1. The data the engine used, including whether a bureau was called and what came back.
2. The version of the rules or model that made the decision.
3. The outcome, the limit granted, and the reason codes behind it.
4. The key product information version the customer saw at that moment.
5. A timestamp and identifiers that tie the decision to the agreement it produced.

The second item is the one that most often gets missed. If thresholds change in March and a complaint about a January decision arrives in June, the lender needs to show the rules as they stood in January, not as they stand today.

There's a balance to strike here too. Credit data is personal data under UK GDPR, so the record should hold what's needed to explain the decision and nothing more, with retention periods agreed with your compliance team before the first agreement is signed.

Disclosure Has to Fit Inside the Checkout

Most BNPL decisions happen in the few seconds between choosing a payment method and confirming the order, often on a phone. That's the window in which the new rules expect the customer to understand what they're agreeing to.

The FCA split pre-contract information into two layers so it wouldn't bury people in text. Key product information has to appear prominently before the agreement is made. A second layer, additional product information, holds the rights a customer may need later and must be made available before signing (Reed Smith, 2026).

On paper, the list is short. In practice, much of it is dynamic. Payment amounts and dates change with every basket, the credit reference agency line depends on how the decision engine is configured, and the risks section has to stay accurate as the product changes. Very little of this can live as static copy in a template.

There's also a question of whose screen it is. The obligation to provide key product information sits with the lender, but the checkout it appears in often belongs to a retailer, a marketplace, or a ticketing platform using the lender's widget or API. Lenders that let partners render their own version of the plan details take on a real risk: the wording customers see may drift from the wording compliance approved. Locked components that partners embed, but can't edit, are the safer pattern. They do cost partners some design freedom, and that trade-off is worth agreeing in the commercial contract rather than discovering in a complaint.

The Consumer Duty raises the bar further. Its consumer understanding outcome asks firms to check that communications are actually understood, not just delivered. For a checkout component, that points toward usability testing on real devices and comparing variations of the plan summary. It also means monitoring signals such as how often customers open the additional information, or how many contact support in the first week of a plan.

What to Record Each Time the Information Is Shown

Showing the right information is half the job. Proving it was shown is the other half, and that proof usually comes from the event log rather than from the page itself. For every agreement, the record should hold:

1. The version of the key product information and additional information content displayed.
2. The values rendered into it: credit amount, cash price, schedule, and payment amounts.
3. The channel and device type, and which partner's checkout hosted it.
4. The customer's acknowledgment and the time it was given.
5. A link to the creditworthiness decision and the agreement it produced.

Keep these records with the decision log described above, and a complaint about a plan from months ago becomes a quick lookup rather than a forensic exercise.

Servicing Is Where the Hidden Work Sits

Most of the attention around the new rules has gone to the moment of lending. Most of the build effort, in our experience of payment platforms, goes into what happens over the next few weeks and months: collecting payments, handling the ones that fail, and dealing with customers whose circumstances have changed since they clicked "confirm."

Under the new rules, that period is regulated too. When a payment is missed, lenders must contact the customer as soon as possible and explain the adverse consequences that will follow from it. Before terminating an agreement or taking enforcement action, they must give reasonable notice and signpost free, impartial debt advice, including an explanation of why it might help (Reed Smith, 2026). Those communications also need to show that the customer's individual circumstances were taken into account (Herbert Smith Freehills Kramer, 2026).

That last requirement is the one that strains a typical servicing stack. A fixed sequence of reminder emails, triggered by a failed payment and identical for everyone, doesn't show anyone's circumstances being considered.

Spotting Financial Difficulty Early

BNPL debt has an awkward shape. A customer rarely owes one large sum; they owe several small ones, across several plans, each on its own schedule. A system that services plan by plan can see one missed payment and miss the pattern around it entirely.

The signals worth surfacing at the customer level include:

• Repeated payment failures: Especially when they follow several automatic retries on the same card.
• Rising exposure: New plans being opened while existing ones fall behind.
• Changed behaviour: Requests to move payment dates, partial payments, or a sudden drop in activity.
• Direct disclosure: A customer telling support they've lost work, fallen ill, or are struggling, which should be logged where collections staff can see it.

Payment retry logic deserves a specific review. Aggressive retries on a continuous payment authority can recover revenue in the short term, but for a customer already in difficulty they can mean extra bank charges and a worse position. That's the kind of outcome the Consumer Duty asks firms to watch for.

When difficulty is identified, the options available to staff need to exist in the system itself, not in a policy document. Pausing payments, spreading the remaining balance, or stopping further lending should each be an action an agent can take, with the decision, reason, and outcome recorded. Forbearance that lives in an agent's notes is hard to apply consistently and harder to evidence.

Complaints That Can Now Reach the Ombudsman

Regulated DPC customers can now take complaints to the Financial Ombudsman Service. Under the standard complaint rules, a firm generally has eight weeks to resolve a complaint before the customer can escalate it, and the ombudsman will expect the firm's records to explain what happened.

This is where the decision log and disclosure records pay for themselves. A complaint about affordability or unclear terms becomes answerable when the firm can show what data it used, what rules applied, what the customer saw, and how their difficulty was handled afterwards.

One system detail is easy to overlook. Agreements signed before 15 July 2026 remain unregulated, and the ombudsman's voluntary jurisdiction doesn't extend to them (A&O Shearman, 2026). For the next year, lenders will be servicing both kinds side by side, so every agreement needs a clear regulated or unregulated flag driving which communications, processes, and complaint routes apply to it.

CASE STUDY | UPC: Adding Buy Now Pay Later to Meet Growing Consumer Demand

Ukrainian Processing Center, one of the largest processing centers in Central and Eastern Europe, wanted its bank clients to offer instalment payments to their merchants. Softjourn built an instalment payments API into UPC's eCommerce Connect gateway.

• Merchants offer "Buy in Installments" at checkout, with 3, 6, 9, or 12-month plans
• The full purchase amount is blocked on the card at checkout, then debited plan by plan over the agreed term
• Banks and merchants track instalment payment data through the eCommerce Connect dashboard

Read the full case study

The Data the FCA Will Ask For

Authorisation also starts an ongoing reporting relationship with the regulator. Fully authorised DPC lenders must give the FCA product sales data about their DPC lending (FCA, 2026). The Consumer Duty adds a second layer: firms have to monitor whether their products deliver good outcomes, and their boards must review that evidence at least once a year.

Neither obligation is hard to state, and both are hard to meet if the data lives in a dozen places. The questions tend to cut across systems that were built separately:

The most common obstacle isn't missing data. It's inconsistent definitions. If the collections team counts a customer as "in arrears" after one missed payment and the finance team waits for two, then any figure that reaches the FCA or the board depends on who ran the report. Agreeing on these definitions once, writing them down, and building every report from the same event records is slower at the start and far cheaper than reconciling numbers after a regulator has asked about them.

The decision logs, disclosure records, and servicing events described above do most of this work already. A reporting layer built on top of them can answer the regulator's questions without manual spreadsheet work every quarter.

Build, Partner, or Buy the Compliance Layer

Every requirement so far comes down to systems, and every firm facing them has the same practical choice to make about who builds those systems. The answer depends less on budget than on where lending sits in the business. A BNPL lender, a retailer offering instalments, and a ticketing platform weighing its own payment plans are solving different problems, even when the rules they read are the same.

Most firms end up with a mix. A lender might buy a collections tool, build its own decision engine, and bring in a partner to connect the two and produce a single audit trail. A retailer might add a third-party lender's plans to its checkout and keep its own team focused elsewhere.

None of these options moves the accountability. A regulated firm can outsource the work, but it can't outsource its responsibility for the outcome, so whoever builds the system has to produce evidence the firm can stand behind.

Three questions settle most of the decision:

1. Does lending sit in your product, or alongside it?
2. Can your current team deliver the changes before the January 2027 authorisation deadline without stalling other work?
3. If a complaint arrives a year from now, will one system be able to tell the whole story of that customer's plan?

The third question is often where a development partner earns its place, because joining decision, disclosure, servicing, and complaint data into one record is the kind of work that sits between vendors and in-house teams. Make sure any partner you choose has done regulated payments work before. Learning the domain and the deadline at the same time is an expensive combination.

CASE STUDY | Bullet: Adapting to New Irish Payroll System Requirements

When Ireland required employers to report payroll results to the Revenue Online Service in real time from 1 January 2019, Bullet's accounting platform had to change with it. Softjourn updated the software so payroll data could be shared with Revenue automatically, or exported as files for upload.

"Softjourn did a great job and took a tremendous amount of pressure off me." Peter Connor, founder of Bullet

Read the full case study

READ MORE: Silicon Valley Bank: Using Automation in Banking for More Than Just Simplifying Processes

What the UK Rules Signal for Other Markets

For firms that only lend in the UK, the work described above is the whole job. For firms selling across borders, the UK is the first of several regimes arriving close together, and they won't match each other line by line.

The EU's revised Consumer Credit Directive applies from 20 November 2026, a month from now, and member states are implementing it through their own national laws. In the US, the federal step back hasn't settled the question. New York, for example, has a state law covering BNPL providers and published draft rules in February 2026 that would require licensing, cap late and penalty fees, and require lenders to tell customers whether loans will be reported to credit bureaus (New York DFS, 2026).

The practical lesson for technology teams is to avoid hard-coding one market's rules into the product. Disclosure content, decision thresholds, arrears timelines, and fee limits will differ by jurisdiction. A platform that treats them as per-market configuration will take on each new regime as a project. A platform that treats them as code will face a rebuild each time.

Where to Start If You're Still Catching Up

Three months past regulation day, many firms have the essentials in place and a list of gaps behind them. If you're working through that list, this is the order we'd take it in:

1. Confirm scope with counsel: Check which of your products are DPC, which are exempt, and which fall under the wider consumer credit rules.
2. Plan back from January 2027: Work out what your authorisation application needs to describe, and which systems have to exist for you to describe them honestly.
3. Map each requirement to a system: Give every protection in the regime an owner and a system of record.
4. Audit one week of credit decisions: See what your engine actually records, including the rules version in force when each decision was made.
5. Put disclosure under version control: Lock the components partners embed, and log what each customer saw.
6. Review servicing at the customer level: Look at retry logic, financial difficulty signals, and forbearance actions staff can apply and record.
7. Flag every agreement: Mark each one as regulated or unregulated so the right processes and complaint routes follow it.
8. Agree on data definitions before the first report: Then build reporting from the same event records your teams already use.

None of this is quick, and some of it will surface problems in systems built before anyone expected BNPL to be regulated. Those problems are better found by your own team in October than by a regulator or an ombudsman next year.

For more on how we approach regulated payment systems, see our payment processing development services. Contact Softjourn to get started on your BNPL compliance roadmap.