ofOpen Finance Guide
GlossarySTETPSD3 and PSRBlogContact

The PSR (PSD3) for operations and infrastructure

The PSR moves operational rules from the 2018 RTS into the regulation and removes the fallback mechanism. If the dedicated interface goes down, TPPs no longer have the customer interface to fall back on. The dedicated interface is presumed unavailable once five consecutive requests get a server error or no answer within 30 seconds. The maintenance window is new. Planned downtime is announced a month ahead and normally falls between 00:00 and 06:00, local time for the bank.

Start with the quarterly statistics, which put the dedicated interface next to the customer interface for availability and for the rate of successful requests, counted in number and in value for payments. The RTS due nine months after entry into force will set the method. The text says nothing about certificates. TPP identification is left to the future Article 89 RTS, and until then the qualified eIDAS certificates required by the 2018 RTS remain in use.

By Tancrède Simonin, October 4, 2026

Where to start

The five obligations that change the most for this role.

  • OB-IF-011PSR 38(1)Out of spec

    Unavailability presumed after five failed requests

    The ASPSP keeps planned unavailability to what is strictly necessary and works to prevent the rest, and the interface is presumed unavailable when five consecutive requests get a server error or no response within 30 seconds.

    STET 1.6.3 The rule is monitored on the operations side. STET defines no timeout and no error threshold.

  • OB-IF-012PSR 38(2)Out of spec

    Maintenance announced a month ahead, from 00:00 to 06:00

    Except for emergency changes, the ASPSP announces each planned unavailability and its duration to TPPs at least one month ahead, and it normally takes place between 00:00 and 06:00, in the ASPSP's local time according to recital 57.

    STET 1.6.3 STET has no status endpoint and no maintenance calendar. The announcement goes through the bank's developer portal.

  • OB-IF-006PSR 35(5)Out of spec

    Quarterly statistics published

    Each quarter the ASPSP publishes on its website the availability, unplanned unavailability and performance of the dedicated interface and of the customer interface, performance being the success rate of AIS requests and of PIS requests by number and by amount.

    STET 1.6.3 Measurement and publication happen on the operations side. The method will come from the Article 38(5) RTS.

  • OB-IF-010PSR 37(1)Out of spec

    Parity with the customer interface

    The dedicated interface offers at all times at least the same availability and performance as the customer interface, technical support included, and does not respond more slowly than it.

    STET 1.6.3 A specification cannot guarantee a service level. The comparison is made on the Article 35(5) statistics.

  • OB-IF-013PSR 38(2a)Out of spec

    TPPs kept informed during an outage

    During unplanned unavailability, the ASPSP promptly tells TPPs what it is doing to restore the interface and how long it expects the fix to take, and ensures an optimal recovery time.

    STET 1.6.3 STET has nothing for signalling an outage to TPPs. The recovery time will be set by the Article 38(5) RTS.

Every obligation for this role

15 obligations in the register concern this role. Obligations checked on October 4, 2026.

Open this view in the register
15 of 15

Dedicated interface(11)

Account information(1)

Consent dashboard(2)

Authorities and sanctions(1)

STET 1.6.3 handbook pages to read

The pages these obligations cite, most cited first.

Glossary cards