Definition
The PSR (Payment Services Regulation) is the European regulation the Commission proposed on 28 June 2023 together with DSP3, under reference COM(2023) 367. DSP3 keeps the licensing and supervision of institutions. The PSR takes over the rest of DSP2, which covers the rights and obligations attached to payments, TPP access to accounts, SCA and the fight against fraud.
The article numbers cited on this page are those of the compromise text of 17 April 2026 (Council, doc. 8221/26). This numbering is provisional, and the review by the lawyer-linguists will probably change it before publication in the Official Journal.
Why a regulation
DSP2 is a directive. Each Member State transposed it in its own way, so banks and TPPs work with national rules that differ slightly. A regulation applies as written in every Member State, without transposition. National authorities remain in charge of supervision and must have the obstacles reported by a TPP removed (art. 48), but the text they apply is the same everywhere.
Where the text stands
The PSR is not adopted and has not been published in the Official Journal. Its procedure, 2023/0210(COD), follows the same path as that of DSP3.
| Date | Step |
|---|---|
| 28 June 2023 | Commission proposal |
| 23 April 2024 | Parliament's first-reading position |
| 18 June 2025 | Council negotiating mandate |
| 27 November 2025 | Provisional agreement in trilogue |
| 17 April 2026 | Final compromise text circulated by the Council |
| 22 April 2026 | Confirmed by Coreper |
| 5 May 2026 | Approved by Parliament's ECON committee |
| Pending | Council first-reading position, then Parliament's second-reading vote |
As of 4 October 2026, Parliament's Legislative Observatory lists a plenary sitting on 14 December 2026, as an indicative date. For now the agreed text exists only in English.
How the application dates are calculated
Article 112 gives no calendar date. The regulation enters into force on the twentieth day after its publication in the Official Journal. That date is called T.
- At T, only Articles 85a (SCA exemption for certain recurring credit transfers) and 108a (payments in electronic money tokens) apply.
- At T + 21 months, the rest of the regulation applies and DSP2 is repealed (DSP3 art. 48).
- At T + 27 months, verification of payee extended to all credit transfers (art. 50) and the liability that goes with it (art. 57) apply.
Until T + 21 months, DSP2 and Delegated Regulation 2018/389 on SCA and communication remain the rule. The EBA must deliver its new draft RTS on SCA and interfaces twelve months after entry into force (art. 89). The text does not say what happens to Regulation 2018/389 after T + 21 months if these RTS are not yet applicable.
Open banking, Articles 33 to 48
A dedicated interface becomes mandatory for every bank that offers a payment account accessible online (art. 35(1)). The fallback mechanism through the customer interface, which the current RTS require unless the bank is exempted, disappears. Two ways out remain. At the bank's request, the authority may allow it to expose its customer interface instead, or exempt it from having an interface (art. 39). A TPP may also "exceptionally" go through another safe and efficient interface (art. 45(1)), with the bank's agreement according to recital 68a.
The text sets no numeric threshold for availability, latency or error rate. It requires parity with the customer interface for response time, availability and performance (art. 36(1)(c), 37(1) and 38). The interface is presumed unavailable after five consecutive requests that get a server error or no response within 30 seconds. Planned maintenance is announced one month in advance and normally takes place between midnight and 6 a.m., bank's local time (art. 38). Every quarter, the bank publishes its availability and performance statistics next to those of its customer interface (art. 35(5)). The EBA must specify their format, and the recovery time after an outage, in an RTS due nine months after entry into force (art. 38(5)).
A change to the interface specifications is published at least two months before it goes into production, against three months today (art. 35(4)).
The bank must build into its interface a consent dashboard covering the consents given to AISPs, and to PISPs for multiple or recurring payments (art. 43). The customer sees the TPP, the account, the purpose, the duration and the data categories. They can withdraw an access at any time, restore it within 48 hours and view the history for two years. The TPP sends the bank the details of each new consent, and the bank notifies the TPP of any withdrawal, in both cases "without undue delay". The text does not require real time.
Article 44 lists twelve prohibited obstacles, and the list is not exhaustive. Examples include asking for more SCA than in the bank's direct channel, adding steps to a redirect or decoupled journey, and requiring two SCAs in the same initiation journey.
On the AISP side, the bank serves requests whether or not the customer is present (art. 41). The limit of four accesses per day without the customer, which appears in the current RTS, is not in the compromise.
On the PISP side, Article 36(4) sets a minimum: standing orders, future-dated payments, payments to several payees, and a check of the account holder's name before initiation. The PISP gets a yes or no answer on the availability of funds (art. 36(5)). The standalone confirmation of funds service for card issuers (CBPII, Article 65 of DSP2) is removed.
Regulated access still requires no contract with the bank (art. 34). A bank may offer paid APIs for services that go beyond the regulation, and recital 56 cites variable recurring payments.
SCA, Articles 85 to 89
The definition of SCA does not change (art. 3(35)). The bank applies its SCA only on the first access by a given AISP, unless it suspects fraud (art. 86(3)). After that, the AISP applies SCA when the customer views their data in the AISP's service, at least every 180 days, using its own SCA or the bank's (art. 86(4)).
The PISP chooses the authentication procedure when the bank offers several (art. 36(4)(ha)). Exemptions are left to the EBA's RTS, which will set their criteria (art. 85(11)). The compromise contains no euro threshold. Finally, a PSP must offer free of charge at least one SCA method suited to each customer, and cannot make SCA depend on owning a smartphone, unless the customer chose a mobile-only service (art. 88).
Fraud and refunds
Article 59 creates a single new right to a refund. It covers a consumer manipulated by someone posing as their own bank through channels attributed to that bank (phone number, email address, website, app, including fraudulent copies of them). The bank refunds the full amount if the customer informed it without delay and reported the fraud to the police. It has fifteen business days to refund or give reasons for a refusal. Other manipulation frauds (fake investment, romance scam, fake invoice, fake police officer) are not covered by this right.
PSPs must take part in fraud data sharing arrangements (art. 83a). Verification of payee extends to all credit transfers, including those not in euro, at T + 27 months (art. 50). The time limit to dispute an unauthorised transaction goes from 13 to 18 months (art. 54).
Penalties
For breaches of the open banking chapter and of Articles 85 to 87 on SCA, Member States must provide for a fine whose maximum is at least 10% of annual turnover for a legal person and at least EUR 3 million for a natural person (art. 97). Daily periodic penalty payments are possible for up to six months (art. 98).
What remains to be written
The compromise gives the EBA eleven standards and guidelines to produce for the PSR and seven for DSP3, based on a count made on the texts. At the end of September 2026, the EBA had published no list, roadmap or consultation. The first drafts are due nine months after entry into force (interface statistics), then twelve months (SCA, exemptions, communication standards) and eighteen months (data on TPP access to be reported to the authorities, art. 48(8)). The text mentions neither eIDAS certificates nor any particular API standard. TPP identification will be specified in these RTS (art. 89), and until then the qualified certificates of Regulation 2018/389 remain the rule.
PSR vs DSP3: what goes where
- DSP3 (directive) covers the licensing, capital, safeguarding of funds and supervision of payment institutions, electronic money issuers included.
- The PSR (regulation) covers the rules for executing payments: customer information, open banking, SCA, fraud, liability and refunds.
In the PSD2 ecosystem
For a bank or a TPP, the PSR is the text to read. Articles 35 to 44 and 85 to 89 already describe most of the interface obligations. The missing pieces are known: TPP identification, SCA exemption thresholds and the format of the statistics.
Concrete examples
- A bank that runs a fallback interface today will be able to shut it down. It will, however, have to publish every quarter the availability and performance of its dedicated interface, compared with those of its website and app.
- An aggregator will no longer send its customers back to the bank for a new SCA every 180 days. It will apply SCA itself when the customer views their accounts in its app. On the bank side, token and consent lifetimes set to match the current rule will need to be revised.
- A customer who withdraws an aggregator's access from their bank's dashboard can restore it within 48 hours. This requires an API in both directions between bank and TPP. STET 1.6.3 currently has neither a consent status nor a notification for this exchange.
- A customer called by a fake adviser who displays their bank's number, and who makes a transfer on the caller's instructions, will be able to claim a full refund if they informed their bank and reported the fraud to the police. The same customer, if they fall for a fake crypto investment, has no such right under the PSR.
- A PISP will be able to set up a standing order or pay several payees at any bank, since Article 36(4) makes these a minimum.