On the way to PSD3: bill_line guide of what you must know so far

Every few years the EU writes a new chapter in their rulebook for payments, and every time the market treats this as somebody elseʼs problem until the deadline becomes red. PSD2 taught that lesson expensively: strong customer authentication was postponed twice because issuers, acquirers and the software behind them were not ready on the same day. The successor package – the PSD3 directive and the Payment Services Regulation (PSR) – is now close enough to adoption. bill_line develops software and infrastructure technology for payment providers, banks and fintech companies, so we ask one narrow question of every clause: what has to exist in the product before our clientsʼ compliance date arrives?

Factcheck and general conditions

The EU Parliament and the Council reached a provisional agreement on 27 November 2025. The ECON committee approved the negotiated text on 5 May 2026, and the Parliament’s own legislative tracker lists the package as “close to adoption”, with formal votes and Official Journal publication still to come. PwC Legal’s reading of the compromise text puts most PSR rules into application 21 months after entry into force, with the verification-of-payee service following at 27 months and a window of up to 27 months for e-money institutions to move onto the new licence. With publication expected in late 2026, the working deadline sits in 2028. This obliges vendors the release has to ship in 2027: no PSP goes live on a regulatory build in the quarter it becomes mandatory.

One structural point matters more than any date. PSD2 was a directive, so each member state transposed it in its own way. Most of the conduct rules – authentication, liability, open banking access – now move into the PSR, a regulation that applies directly and identically in all 27 markets. A provider licensed in Lisbon and serving clients in Warsaw, will finally read one text, and its software can carry one rule set instead of a matrix of national exceptions.

bill_line recommends: New merchant monitoring rules from Mastercard

Fraud liability moves up the chain

The numbers behind the reform are concrete. The joint EBA and ECB report on payment fraud puts losses across the EEA at €4.2 bln in 2024, up from €3.5 bln a year earlier: €2.2 bln on credit transfers and €1.3 bln on cards. The uncomfortable line in the same report is that payment service users bore roughly 85% of credit-transfer fraud losses. These are mostly scams where a legitimate customer was talked into authorising the payment themselves. That is precisely the gap the PSR is written to close, and it closes it by moving the bill to the provider.

Three changes follow this.

• Every credit transfer will have to pass a check that the payee’s name matches the IBAN, free of charge and within seconds, and a provider that skips the check refunds the full amount.
• Customers manipulated by someone impersonating their bank or PSP, get their money back, with the provider given 15 business days to pay or to justify a refusal, and the burden of proving gross negligence sitting with the provider, not the customer.
• Transaction monitoring becomes a duty on the payee side as well as the payer side, so an acquirer that lets an obviously abnormal flow through carries the liability for it.

Each of those changes describes an emergence of a new system (or, at least, the drastic change of existing one). A name-matching service that answers in seconds is a latency budget. A 15-day refund clock with the burden of proof on the provider is a case-management tool with evidence attached to every step. Payee-side monitoring is a scoring engine sitting in the acquiring flow, where most stacks today have nothing but velocity limits.

There’s also an interesting take in the Council’s own summary. It states the trading name a customer sees at checkout must match the name on their bank statement. Descriptor logic is where “unrecognised transaction” chargebacks are born.

SCA stays, but stops being a checkbox

There was talk of loosening strong customer authentication. It didn’t happen, and the data shows why: the EBA and ECB found card fraud 17 times higher when the payee sat outside the EEA, where SCA is not legally required – and Deloitte’s assessment credits SCA with cutting fraud by 70–80% since PSD2.

So, what changes, you may ask. And bill_line answers: the shape of the requirement. Authentication may no longer depend on owning a smartphone unless the customer agrees to that. Two inherence factors, such as face and behavioural biometrics, may be combined where a provider can prove they are independent. And for merchant-initiated transactions the customer authenticates once, when the mandate is set up, not on every renewal. Providers serving subscription merchants have waited years for that sentence to appear in law rather than in scheme rules. And the software now has to know which transaction in a chain is the mandate and which is the renewal.

What bill_line is building before the clock starts

None of this is absorbed at the checkout page. It lands in the layer that holds acquirer connections, routing, descriptors and fraud signals – the layer bill_line builds for its clients. Our goal os to effectively scope this on 3 fronts:

• descriptor management that lets a provider push brand names – not legal entities – to the statement without touching code;

• payee-side transaction monitoring as a native module rather than a bolt-on, because the PSR makes it every acquirer’s obligation;
• mandate-aware SCA orchestration that separates set-up from renewal so that the exemption is applied by design, not by an operator flagging transactions by hand.

Level-2 standards from the EBA will fill in the detail, and some of it will shift. The direction will not. PSD3 moves cost and liability towards whoever runs the pipes, and the providers who come through it cleanly will be the ones whose software was built with the regulation in mind. bill_line would rather do that work for our clients now, on our own timeline, than in the last quarter before 2028.