A preparação para a PSD3 não é um problema futuro. É um problema presente.

Muitos bancos europeus ainda falam sobre PSD3 como se fosse um marco distante, mesmo que o acordo político tenha sido alcançado em novembro de 2025 e as equipas jurídicas agora coloquem 2026 no centro do planeamento de transição. A indústria já não tem espaço para tratar isto como algo que se irá consolidar “mais tarde”.

Parte do problema é a crença de que a PSD3 é essencialmente a PSD2 com algumas camadas adicionais — uma espécie de PSD2.0. Não é. O novo pacote — a Terceira Diretiva de Serviços de Pagamento e o Regulamento de Serviços de Pagamento (PSR) de aplicação direta — eleva o padrão de como as permissões são governadas, como a autenticação é evidenciada e como o acesso de terceiros é gerido.

Chega também num momento em que pagamentos de conta a conta, carteiras digitais e modelos mais amplos de partilha de dados estão a impor exigências mais pesadas na mesma infraestrutura que os bancos construíram para a PSD2.

No nosso trabalho com instituições europeias, estamos a ver abordagens muito diferentes. Alguns bancos aguardam o texto final antes de tomar decisões. Outros já estão a reconstruir os componentes que determinarão se a PSD3 será uma atualização controlada ou uma retrofitting disruptiva. A diferença não tem a ver com interpretação regulatória, mas sim com arquitetura.

Onde os bancos ainda estão expostos

Muitos bancos ainda abordam a PSD3 através da lente da interpretação política, embora a verdadeira pressão esteja nas infraestruturas subjacentes. Grande parte do que foi construído sob a PSD2 foi montado rapidamente para cumprir prazos, e muitos bancos nunca voltaram a reforçar esses componentes após a pressão imediata passar.

A consentimento é um exemplo. Muitos bancos ainda dependem de armazéns de consentimento específicos de canal ou painéis de controlo adicionados durante a PSD2. Essas configurações dificultam a gestão de permissões ao nível de detalhe que a PSD3 espera, e tornam ainda mais difícil revogá-las ou evidenciá-las de forma clara.
A autenticação muitas vezes está no mesmo lugar. Provar que uma etapa de Autenticação Forte do Cliente (SCA) ocorreu não é suficiente; os bancos precisam de mostrar o contexto de autenticação e o estado de autorização da parte que iniciou a transação no momento em que foi aprovada.

Controles de fraude acrescentam mais pressão. Agora, têm de mostrar como o risco foi avaliado em tempo real, e não reconstruído posteriormente. Isso torna-se mais difícil quando as ferramentas de monitorização permanecem fragmentadas ou os dados de transação estão dispersos por sistemas desconectados. Plataformas como o SmartVista Fraud Management da BPC, que combinam monitorização de transações online com gestão centralizada de dados e suporte de IA/ML, indicam o tipo de arquitetura que os bancos precisam. Precisam de uma que possa avaliar a atividade em tempo real e mostrar como essas decisões foram tomadas. O desempenho da API também está em jogo. O PSR dá mais peso à estabilidade das interfaces, à gestão consistente de erros e à entrega fiável de dados através dos canais. O acesso de terceiros e a integração também precisam dessa mudança — de verificações periódicas e passos manuais para verificação contínua e um modelo mais claro de gestão de direitos de acesso.

Instituições que reforçaram essas fundações após a PSD2 estão agora a adaptar-se à PSD3 com muito menos perturbações. Aqueles que deixaram as suas construções PSD2 inalteradas enfrentam agora uma subida mais íngreme.

O que a PSD2 deixou para trás

A PSD2 deixou um conjunto de decisões técnicas que agora definem a dificuldade da PSD3. Muitas instituições construíram rapidamente para cumprir o prazo: painéis de permissões separados por canal, lógica de autenticação dispersa por produtos, gateways de API ajustados para baixos volumes e passos manuais para verificar ou integrar terceiros. Essas escolhas resolveram o problema imediato, mas agora estão no centro da carga de trabalho da PSD3.

Outros usaram a PSD2 para organizar melhor as fundações. Centralizaram permissões, trataram a autenticação como um serviço partilhado, investiram em APIs mais fiáveis e introduziram controlos de acesso mais claros. Nada disso foi feito com a PSD3 em mente, mas dá-lhes espaço para se adaptarem sem desmontar os seus sistemas.

A PSD3 e o PSR expõem a diferença entre esses dois caminhos. O novo quadro espera que os bancos saibam, em tempo real, quem está a aceder a quê, sob quais permissões e com que nível de garantia. Espera que as APIs se comportem de forma consistente, que as verificações de fraude sejam evidenciadas no momento da transação e que os direitos de acesso sejam verificados continuamente. Essas expectativas variam bastante dependendo de como foi feita a base da PSD2.

O trabalho realizado sob a PSD2 agora decide o quão disruptiva será a PSD3.

As decisões que não podem ser adiadas

Várias decisões arquitetónicas já estão na mesa, e esperar pelo texto final não as tornará mais fáceis. As permissões precisam de um único local; armazéns de consentimento dispersos criados durante a PSD2 dificultam a gestão de detalhes, a revogação de acessos de forma limpa ou a demonstração do que estava em vigor no momento da aprovação.

A autenticação precisa de atuar como um serviço único, em vez de um conjunto de passos ao nível do produto, porque a PSD3 espera que os bancos mostrem o contexto completo de uma aprovação, não apenas que um evento SCA ocorreu.

Os direitos de acesso precisam de ser verificados continuamente, e não em intervalos, com uma forma mais limpa de gerir quem pode fazer o quê ao longo do tempo. E as APIs precisam de ser tratadas como infraestrutura operacional, com o nível de fiabilidade e consistência que o PSR exige.

Por isso, os bancos estão a começar a olhar além de soluções pontuais e para plataformas modulares que possam absorver mudanças regulatórias de forma mais limpa. Para as instituições tradicionais, uma infraestrutura preparada para o futuro é tão importante quanto a conformidade atual. Plataformas como o BPC SmartVista, concebidas como uma arquitetura modular, nativa na cloud e escalável, oferecem aos bancos uma rota mais prática para a adaptação à PSD3 e reduzem o risco de que a próxima mudança regulatória desencadeie outra reconstrução dispendiosa. Os bancos precisam de plataformas que facilitem a transição, apoiem a conformidade à medida que os requisitos evoluem e deixem espaço para se adaptarem sem reabrir toda a pilha.

Estas escolhas vão decidir se a PSD3 será uma atualização gerível ou uma reconstrução dispendiosa. Avançar cedo dá aos bancos espaço para se adaptarem por conta própria. Esperar pelo texto final arrisca comprimir o trabalho numa janela muito mais curta.

A janela é mais curta do que parece

Sempre que as regras de open-banking se tornaram mais restritivas, os bancos que avançaram cedo tiveram mais espaço para fazer escolhas deliberadas. Os que esperaram acabaram por fazer remendos sob pressão. A PSD3 está a seguir o mesmo caminho. Tratá-la como um trabalho de infraestrutura agora dá aos bancos mais controlo sobre o resultado. Esperar pelo texto final só reduz o espaço para agir.