ofOpen Finance Guide
GlossarySTETPSD3 and PSRBlogContact

The PSR (PSD3) for audit and pentest

The PSR writes into the regulation much of what an audit of a dedicated interface has to check. The twelve obstacles in Article 44 can be tested one by one, from the number of SCAs compared with the bank's own app to extra steps in a redirect journey. SCA also changes sides for account information. The bank may only require it on an AISP's first access, unless it suspects fraud, and from then on the AISP repeats it every 180 days.

Test TPP identification and account isolation first, since an AISP may only access the accounts the user designated. After a consent is withdrawn, the TPP must stop all access and delete the data, but not before 48 hours, which has to be checked on the TPP's side. A breach of Articles 85 to 87 on SCA falls under the same fines as the open banking chapter.

By Tancrède Simonin, October 4, 2026

Where to start

The five obligations that change the most for this role.

  • OB-IF-017PSR 36(2)(a)Covered

    TPP identification towards the ASPSP

    The interface lets AISPs and PISPs identify themselves towards the ASPSP, and they do so at every payment initiation for the PISP and at every session for the AISP.

    STET 1.6.3 STET identifies the TPP with an eIDAS QWAC over mTLS and checks that the client_id matches the authorisation number in the certificate. The PSR does not say how the TPP identifies itself.

  • OB-IF-009PSR 36(2)(b)Covered

    Authentication started by the TPP, protected session

    The interface lets the TPP ask the ASPSP to start authentication based on the user's consent, keeps the session between the parties open throughout authentication, and protects the integrity and confidentiality of credentials and authentication codes.

    STET 1.6.3 In redirect or decoupled mode, the TPP triggers authentication at the bank, through the OAuth2 authorisation for the AISP and through the payment request for the PISP, over a mutually authenticated TLS connection.

  • OB-AIS-007PSR 47(1)(d)Covered

    The AISP accesses designated accounts only

    The AISP accesses only information from designated accounts and their transactions, with mechanisms that prevent any other access, in line with the user's consent.

    STET 1.6.3 PUT /consents lists, for each data type, the accounts the user designated, and the bank uses it to limit access.

  • 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).

  • OB-DB-006PSR 43(2b)Out of spec

    After withdrawal, the TPP stops and deletes

    After a withdrawal, the TPP stops accessing and using the data, then deletes it without undue delay but not before 48 hours, unless the user explicitly chooses to let it keep the data.

    STET 1.6.3 The TPP can only apply this rule if it learns of the withdrawal, which STET only tells it indirectly (OB-DB-008).

Every obligation for this role

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

Open this view in the register
13 of 13

Dedicated interface(2)

Account information(1)

Consent dashboard(1)

Prohibited obstacles(7)

Strong customer authentication(2)

STET 1.6.3 handbook pages to read

The pages these obligations cite, most cited first.

Glossary cards