ofOpen Finance Guide
GlossarySTETPSD3 and PSRBlogContact

The PSR (PSD3) for API teams

The PSR sets a functional baseline for the dedicated interface, and STET 1.6.3, unchanged since October 2022, does not cover all of it. The largest gap is consents. The TPP must send the bank the purpose and validity period of every consent, the bank must tell the TPP about every withdrawal, and STET has neither the fields nor a notification. A PISP must be able to read the account, its holders and its currencies before initiation, which the STET PISP role cannot do, and to know which status counts as confirmation of execution.

Start by filtering the list on the STET statuses Missing, then Partial. Then look at refresh token lifetimes, because the bank may now require SCA only on an AISP's first access, unless it suspects fraud, and it is the AISP that repeats it every 180 days. The notice period before an API change drops from three months to two.

By Tancrède Simonin, October 4, 2026

Where to start

The five obligations that change the most for this role.

  • OB-DB-007PSR 43(3b)Partial

    The TPP sends each consent to the ASPSP

    The TPP tells the ASPSP without undue delay about each new consent, with its name, the account, the purpose, the validity and the data categories, and the ASPSP shows only what the TPP sent it.

    STET 1.6.3 PUT /consents sends the accounts and data types, with no purpose, validity or date. Nothing exists for recurring PIS consents.

  • OB-DB-008PSR 43(4)Partial

    The ASPSP tells the TPP about every change

    The ASPSP tells the TPP without undue delay about any change the user makes in the dashboard, withdrawal included.

    STET 1.6.3 STET has neither a consent status to query nor a notification. A withdrawal revokes the refresh token, and the AISP only finds out from the invalid_grant error on its next refresh.

  • OB-PIS-009PSR 36(4)(hc)Missing

    Account, holders and currencies visible before initiation

    Before initiation, the PISP sees the account identifier, the holders' names and the currencies, where the user has access to them.

    STET 1.6.3 The PISP can only propose a debtorAccount in its request. It reads nothing about the account before initiation.

  • OB-PIS-011PSR 36(5)(b)Partial

    Confirmation that the payment will be executed

    The ASPSP confirms to the PISP as soon as possible that the payment has been or will be executed, taking pending orders into account, without sharing those orders with it.

    STET 1.6.3 The PISP reads ISO 20022 statuses (ACSP, ACSC, RJCT…) by polling, and the specification, which predates the text, does not say which one counts as confirmation of execution.

  • OB-SCA-002PSR 86(3)To review

    ASPSP SCA on the AISP's first access only

    For a given AISP, the ASPSP applies SCA only on the first access to the account data and not afterwards, unless it has reasonable grounds to suspect fraud.

    STET 1.6.3 The Framework has the AISP's refresh token revoked when the regulatory delay between two SCAs expires, which sends the user back to an SCA at the bank. After the first access the bank can no longer impose it, and renewing SCA is the AISP's job (OB-SCA-003).

Every obligation for this role

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

Open this view in the register
46 of 46

Dedicated interface(9)

Account information(5)

Payment initiation(12)

Consent dashboard(4)

Prohibited obstacles(11)

Strong customer authentication(4)

Authorities and sanctions(1)

STET 1.6.3 handbook pages to read

The pages these obligations cite, most cited first.

Glossary cards