ofOpen Finance Guide
GlossárioSTETDSP3 e PSRBlogContato

O PSR (DSP3) para auditoria e pentest

O PSR leva para o regulamento boa parte do que uma auditoria de interface dedicada precisa verificar. Os doze obstáculos do artigo 44 se testam um a um, do número de SCA comparado com o app do banco até as etapas a mais em uma jornada por redirecionamento. A SCA também muda de lado na informação sobre contas. O banco só pode exigi-la no primeiro acesso de um AISP, salvo suspeita de fraude, e depois é o AISP que a refaz a cada 180 dias.

Teste primeiro a identificação do TPP e o isolamento das contas, já que o AISP só pode acessar as contas que o usuário designou. Depois da retirada de um consentimento, o TPP deve parar todo acesso e apagar os dados, mas não antes de 48 horas, o que se verifica do lado do TPP. Um descumprimento dos artigos 85 a 87 sobre SCA fica sujeito às mesmas multas que o capítulo de open banking.

Por Tancrède Simonin, 4 de outubro de 2026

Por onde começar

As cinco obrigações que mais mudam para este papel.

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

    Identificação do TPP perante o ASPSP

    A interface permite que AISPs e PISPs se identifiquem perante o ASPSP, e eles o fazem a cada iniciação de pagamento, no caso do PISP, e a cada sessão, no caso do AISP.

    STET 1.6.3 O STET identifica o TPP com um certificado eIDAS QWAC em mTLS e verifica se o client_id corresponde ao número de autorização do certificado. O PSR não diz por qual meio o TPP se identifica.

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

    Autenticação iniciada pelo TPP, sessão protegida

    A interface permite ao TPP pedir ao ASPSP que inicie a autenticação com base no consentimento do usuário, mantém a sessão entre as partes durante toda a autenticação e protege a integridade e a confidencialidade das credenciais e dos códigos de autenticação.

    STET 1.6.3 Em redirecionamento ou desacoplado, o TPP dispara a autenticação no banco, pela autorização OAuth2 no caso do AISP e pela solicitação de pagamento no caso do PISP, sobre uma conexão TLS com autenticação mútua.

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

    O AISP só acessa as contas designadas

    O AISP só acessa informações das contas designadas e de suas transações, com mecanismos que impedem qualquer outro acesso, de acordo com o consentimento do usuário.

    STET 1.6.3 PUT /consents lista, por tipo de dado, as contas que o usuário designou, e o banco o usa para limitar o acesso.

  • OB-SCA-002PSR 86(3)A revisar

    SCA do ASPSP apenas no primeiro acesso do AISP

    Para um AISP específico, o ASPSP só aplica a SCA no primeiro acesso aos dados da conta e não depois, salvo motivo razoável para suspeitar de fraude.

    STET 1.6.3 O Framework faz revogar o refresh token do AISP quando vence o prazo regulamentar entre duas SCAs, o que leva o usuário de volta a uma SCA no banco. Depois do primeiro acesso, o banco não pode mais impô-la, e renovar a SCA cabe ao AISP (OB-SCA-003).

  • OB-DB-006PSR 43(2b)Fora da spec

    Após a retirada, o TPP para e apaga

    Após uma retirada, o TPP deixa de acessar e de usar os dados e depois os apaga sem demora injustificada, mas não antes de 48 horas, salvo se o usuário escolher expressamente que ele os mantenha.

    STET 1.6.3 O TPP só pode aplicar essa regra se souber da retirada, o que o STET só lhe comunica de forma indireta (OB-DB-008).

Todas as obrigações deste papel

13 obrigações do registro dizem respeito a este papel. Obrigações verificadas em 4 de outubro de 2026.

Abrir esta visão no registro
13 de 13

Interface dedicada(2)

Informação sobre contas(1)

Painel de consentimentos(1)

Obstáculos proibidos(7)

Autenticação forte(2)

Páginas do manual STET 1.6.3 para ler

As páginas citadas por essas obrigações, da mais citada à menos citada.

Fichas do glossário