PSD2 e open banking: papéis, APIs, autenticação forte e certificados eIDAS

Antes de 2018, se você quisesse criar um aplicativo que mostrasse todas as contas bancárias de um cliente em um só lugar, pedia a senha do internet banking dele e entrava como se fosse ele. Funcionava, era frágil e, do ponto de vista de segurança, indefensável. A segunda Diretiva de Serviços de Pagamento europeia — a PSD2 — substituiu esse arranjo por algo melhor: terceiros licenciados, consentimento explícito do cliente e interfaces que os bancos são legalmente obrigados a oferecer.

O resultado é um ecossistema de APIs regulado com uma propriedade incomum para quem é engenheiro: a especificação do que precisa ser oferecido é texto legal, enquanto o como ficou a cargo do mercado, o que gerou vários padrões técnicos concorrentes sobre uma única obrigação. Este guia cobre as duas metades: o modelo regulatório que você precisa atender e a mecânica das APIs contra as quais você vai efetivamente programar.

O que mudou e por quê

A PSD2 perseguia três objetivos ao mesmo tempo: mais concorrência em pagamentos, mais segurança e uma base legal para o acesso a contas que já acontecia informalmente. Sua disposição de maior impacto é o acesso a contas: um banco que mantém uma conta de pagamento acessível online deve permitir que um terceiro licenciado, agindo com o consentimento explícito do cliente, consulte essa conta ou inicie um pagamento a partir dela — sem cobrar por isso e sem exigir contrato entre o banco e o terceiro.

Outras duas disposições moldam a engenharia do dia a dia. A autenticação forte do cliente tornou-se obrigatória para a maioria dos pagamentos eletrônicos e para o acesso online às contas. E as regras de responsabilidade pesaram decisivamente a favor do cliente: transações não autorizadas são reembolsadas rapidamente, a menos que o prestador comprove fraude ou negligência grave, e é por isso que os bancos investem tanto na etapa de autenticação.

"Open banking" é o termo de mercado para o ecossistema que a diretiva criou. Existem arcabouços semelhantes em outras partes do mundo, com bases legais diferentes e formatos técnicos comparáveis.

Os papéis regulados

Quatro siglas sustentam todo o modelo.

• ASPSP — Account Servicing Payment Service Provider, o prestador que mantém a conta. É a instituição detentora da conta, obrigada a expor a interface; na prática, o banco.
• AISP — Account Information Service Provider, o prestador de informação sobre contas. Lê dados da conta: saldos, transações, dados cadastrais da conta. Somente leitura: agregação, controle de orçamento, análise de crédito.
• PISP — Payment Initiation Service Provider, o prestador de iniciação de pagamento. Ordena um pagamento a partir da conta do cliente, com o consentimento dele. Nunca toca nos fundos; quem executa é o banco.
• CBPII — Card Based Payment Instrument Issuer, o emissor de instrumentos de pagamento baseados em cartão. Faz ao banco uma única pergunta de sim ou não: esses fundos estão disponíveis agora? É usado por emissores cujos cartões debitam uma conta mantida em outra instituição.

Uma mesma empresa pode acumular vários papéis. O cliente, o usuário de serviços de pagamento na linguagem da norma, é a única parte que pode dar o consentimento, e pode revogá-lo a qualquer momento.

O papel de PISP merece atenção porque muda a economia do e-commerce: o lojista pode receber por uma transferência de conta para conta iniciada no checkout, sem bandeira de cartão, sem tarifa de intercâmbio e — com um esquema instantâneo por baixo — com fundos irrevogáveis em segundos. É um perfil de risco realmente diferente do fluxo de cartão descrito em pagamentos com cartão, porque uma transferência não tem mecanismo de chargeback.

Autenticação forte do cliente

A SCA (Strong Customer Authentication) exige autenticação com pelo menos dois elementos independentes, tirados de três categorias:

• Conhecimento — algo que só o usuário sabe (uma senha, não uma palavra fácil de lembrar enviada por e-mail).
• Posse — algo que só o usuário tem (um celular cadastrado com uma chave vinculada, um token físico, um cartão com chip).
• Inerência — algo que o usuário é (impressão digital, rosto ou biometria comportamental).

Independência significa que o comprometimento de um elemento não pode comprometer os outros; um código exibido no mesmo navegador que mantém a sessão não se qualifica. Para pagamentos remotos há um requisito adicional, a vinculação dinâmica: o código de autenticação precisa estar vinculado criptograficamente ao valor e ao beneficiário específicos, e qualquer alteração em um ou outro o invalida. Essa única regra elimina toda uma classe de ataques em que uma autenticação aprovada é reaproveitada para outro beneficiário.

As normas técnicas regulatórias definem isenções que o banco pode aplicar, por sua conta e risco:

Há dois pontos que engenheiros costumam errar. As isenções são solicitadas pelo prestador de pagamento, mas concedidas pelo emissor, então o seu código precisa lidar com um challenge que chega mesmo assim. E o acesso à informação de contas tem seu próprio ritmo: SCA no primeiro acesso, depois um período em que o terceiro pode atualizar os dados sem a presença do cliente um número limitado de vezes por dia, e então nova autenticação.

A interface, e como provar quem você é

Os bancos podem expor uma interface dedicada — uma API construída para esse fim — e a grande maioria faz isso. As regras impõem obrigações que parecem um SLA escrito por um regulador: a interface dedicada deve oferecer disponibilidade e desempenho no mínimo equivalentes aos dos canais que o banco oferece aos próprios clientes, publicar estatísticas de disponibilidade e de erros, fornecer um ambiente de testes com sandbox e permitir testes em larga escala antes do lançamento. Quando a interface dedicada de um banco não atinge esses padrões, deve existir um mecanismo de contingência para que os terceiros ainda consigam chegar ao canal do cliente; bancos que demonstram ter uma interface em conformidade podem ser dispensados de construí-lo. Esse é um dos pontos que a legislação sucessora pretende simplificar.

A identificação usa certificados eIDAS, emitidos por prestadores qualificados de serviços de confiança, que trazem como extensão o número de autorização do terceiro e seus papéis:

• QWAC — Qualified Website Authentication Certificate, apresentado em um handshake TLS com autenticação mútua. Identifica quem está chamando na camada de transporte.
• QSEALC — Qualified Certificate for Electronic Seal, usado para assinar a própria requisição HTTP, de modo que a mensagem continue atribuível independentemente do transporte.

Ambos codificam os atributos de papel (PSP_AI, PSP_PI, PSP_IC), o que permite ao banco verificar a autorização sem contrato bilateral. Certificados comprovam identidade; não são autorização para uma conta específica. O que concede o acesso é o consentimento do cliente, obtido por um redirecionamento para a autenticação do próprio banco — uma separação que se encaixa naturalmente no fluxo authorization code do OAuth 2.0 usado pela maioria das implementações, muitas vezes com OpenID Connect por cima.

O cenário dos padrões

Uma diretiva, vários padrões de API, porque a legislação especificou deliberadamente resultados, e não schemas.

Berlin Group NextGenPSD2 é o mais implementado na Europa continental: REST e JSON, um recurso de consentimento explícito e várias abordagens de SCA (redirect, desacoplada, embutida). Sua flexibilidade é também sua fraqueza — cada banco escolhe opções diferentes, então "compatível com Berlin Group" não quer dizer plug-and-play.

UK Open Banking nasceu de uma medida corretiva da autoridade de concorrência britânica, e não só da PSD2, o que permitiu uma especificação mais rígida e com governança centralizada, com diretório, testes de conformidade e um perfil de OpenID Connect obrigatório. Por isso é o mais uniforme dos três.

STET, de origem francesa, é uma especificação REST compacta e bem alinhada ao vocabulário da ISO 20022 nos payloads de iniciação de pagamento.

Consequência prática: mesmo dentro de um único padrão, espere particularidades de cada banco em paginação, profundidade do histórico de transações, semântica da data de lançamento, tratamento de moedas e códigos de erro. As equipes ou integram por meio de um agregador, ou constroem uma camada de adaptadores por banco atrás de um modelo interno normalizado — um uso clássico da ideia de camada anticorrupção, e das questões de roteamento e cotas tratadas em gestão de APIs e gateways.

Um fluxo típico de informação de contas

O formato é o mesmo entre os padrões, mesmo quando os detalhes diferem. Primeiro, crie um consentimento que descreva exatamente o que está sendo solicitado:

POST /v1/consents HTTP/1.1
Host: api.examplebank.test
X-Request-ID: 1a2b3c4d-5e6f-4a7b-8c9d-0e1f2a3b4c5d
PSU-IP-Address: 203.0.113.14
TPP-Signature-Certificate: <base64 QSEALC>
Signature: keyId="SN=...,CA=...",algorithm="rsa-sha256",headers="digest x-request-id",signature="..."
Content-Type: application/json

{
  "access": { "balances": [ { "iban": "GB11ABCD12345678901234" } ],
              "transactions": [ { "iban": "GB11ABCD12345678901234" } ] },
  "recurringIndicator": true,
  "validUntil": "2026-12-07",
  "frequencyPerDay": 4,
  "combinedServiceIndicator": false
}

O banco responde com um identificador de consentimento e um link para sua página de autenticação. O cliente é redirecionado para lá, se autentica com SCA no próprio banco e volta para a sua URI de redirecionamento. O consentimento então passa de received para valid, e as chamadas de dados passam a ser possíveis:

GET /v1/accounts/3dc3d5b3-7023-4848-9853-f5400a64e80f/transactions?bookingStatus=booked&dateFrom=2026-08-01 HTTP/1.1
Consent-ID: 4a1e7a2c-88f1-4f2f-9a1e-8b7c6d5e4f30
Authorization: Bearer eyJhbGciOiJQUzI1NiIsInR5cCI6IkpXVCJ9...

Uma iniciação de pagamento segue o mesmo padrão: criar o recurso de pagamento, redirecionar para a autenticação e depois consultar o status — RCVD, ACTC, ACSC e companhia, tirados diretamente do vocabulário da ISO 20022 descrito em fundamentos dos sistemas de pagamento.

Notas de design que economizam semanas:

• O consentimento é uma entidade de primeira classe no seu domínio. Persista o id, o escopo, a expiração, o status e a frequência diária restante; conduza a jornada de renovação a partir dele.
• Nunca armazene credenciais bancárias dos clientes. Além de ser proibido, só o fato de recebê-las transforma seu serviço em alvo de phishing.
• Trate todo banco como instável. Timeouts, janelas de manutenção e dados parciais são normais; use circuit breakers, faça cache sinalizando claramente a defasagem dos dados e degrade para um "atualizado em" em vez de uma página de erro.
• Registre logs para auditoria, não o conteúdo. Reguladores e disputas precisam de prova do consentimento e do que foi solicitado; conteúdo de contas nos logs da aplicação é um passivo.
• Minimize os dados. Pedir noventa dias de todas as contas quando você precisa só do saldo atual é, ao mesmo tempo, um risco de compliance e um produto mais lento.

Para onde as regras estão indo

A Comissão Europeia propôs um pacote sucessor: uma diretiva revisada (comumente chamada de PSD3) acompanhada de um regulamento de serviços de pagamento de aplicação direta, além de um arcabouço separado para um acesso mais amplo a dados financeiros. A tendência aponta para obrigações de desempenho mais rígidas para as interfaces, com a exigência de contingência removida para os bancos que as cumprirem, regras mais claras sobre autenticação e sobre responsabilidade em fraudes por falsidade de identidade, supervisão mais consistente e a migração do detalhamento técnico das transposições nacionais para um texto de aplicação direta. Os textos ainda estão mudando; construa para as regras atuais e mantenha substituíveis as partes da sua arquitetura dedicadas a consentimento e autenticação.

Principais pontos

• A PSD2 obriga os bancos a abrir as contas de pagamento a terceiros licenciados que atuam com consentimento explícito do cliente, substituindo o screen scraping baseado no compartilhamento de credenciais.
• Quatro papéis importam: o banco que mantém a conta, o prestador de informação sobre contas, o prestador de iniciação de pagamento e o papel de confirmação de fundos para emissores de cartão.
• A autenticação forte do cliente exige dois fatores independentes mais a vinculação dinâmica de valor e beneficiário; as isenções são solicitadas pelo prestador, mas concedidas pelo banco.
• Certificados eIDAS identificam o terceiro nas camadas de transporte e de mensagem, enquanto redirecionamentos no estilo OAuth carregam o consentimento do cliente.
• Berlin Group, UK Open Banking e STET resolvem a mesma obrigação de formas diferentes, e a variação entre bancos significa uma camada de adaptadores ou um agregador.
• Modele o consentimento explicitamente, conte com expirações e interfaces instáveis, minimize os dados que solicita e mantenha a camada de autenticação substituível à medida que chegam a PSD3 e o regulamento de serviços de pagamento.