A DSP2 é muitas vezes vista do lado de negócios como uma simples «obrigação de os bancos abrirem APIs». Do lado técnico, é uma montagem nada trivial: múltiplos padrões, certificados eletrônicos qualificados, OAuth2 reforçado, fluxos de autenticação assíncronos e uma fragmentação bem real entre os bancos.
Este artigo dá uma visão de alto nível, mas precisa dessa arquitetura, para CTOs, PMs técnicos e desenvolvedores que precisam estimar um projeto DSP2 — seja para integrar um TPP parceiro ou para expor as próprias APIs. Para a versão de negócios / produto, veja antes: Entender a PSD2 visualmente.
O stack DSP2 em uma imagem
Uma chamada DSP2 atravessa várias camadas que não servem para a mesma coisa. Nenhuma é negociável.
Para lembrar: não basta assinar as requisições em HTTPS clássico. O canal é mTLS (as duas partes se autenticam), os payloads são assinados de forma independente e a autorização passa por um OAuth2 estritamente perfilado.
Os padrões de API: não um, mas três
A diretiva obriga a abrir APIs, mas não dita o formato. Três padrões se impuseram na Europa.
| Padrão | Cobertura | Estilo |
|---|---|---|
| STET | França e Bélgica | REST/JSON, baseado em ISO 20022 |
| Berlin Group | Maioria da UE | REST/JSON, o mais difundido |
| Open Banking UK | Reino Unido | O mais maduro, perfil FAPI obrigatório |
Consequências concretas:
- Cobrir toda a França = suportar STET (BNP, Société Générale, BPCE, Crédit Agricole, La Banque Postale, etc.) mais algumas implementações Berlin Group de bancos online.
- Escalar na Europa = adicionar Berlin Group com as variantes por país (Alemanha, Espanha e Itália não seguem exatamente a mesma versão).
- Na prática, muitas equipes usam um agregador (Bridge, Tink, TrueLayer, Yapily) que absorve essa fragmentação em troca de uma margem.
A cadeia de confiança: eIDAS, QWAC e QSealC
A DSP2 responde a uma pergunta simples: como um banco sabe que uma chamada de API vem realmente de um TPP autorizado? A resposta passa pelos certificados eletrônicos qualificados do regulamento eIDAS TSP.
Dois certificados, dois usos:
- QWAC — serve para estabelecer o canal mTLS. Identifica o TPP no nível de transporte. Pense em «carteira de identidade».
- QSealC — assina o conteúdo das requisições (assinatura destacada). Garante a integridade e o não repúdio do payload. Pense em «selo de lacre no envelope».
Ambos codificam os papéis PSD2 do TPP (AISP / PISP / CBPII). O banco verifica dinamicamente que o certificado de fato cobre a operação solicitada.
OAuth2: materializar o consentimento
No lado da autorização, é OAuth2 no seu fluxo Authorization Code + PKCE. Nada exótico, mas com restrições:
- O TPP monta a URL de autorização e redireciona o PSU para o banco.
- O banco autentica o PSU (login + SCA) e depois exibe a tela de consentimento.
- Retorno ao TPP com um código de uso único.
- Troca do código por um access token (curto) e um refresh token (longo, até 180 dias no lado AISP).
- Cada chamada de API carrega
Authorization: Bearer <token>e a assinatura QSealC e passa por mTLS.
Para os perfis mais estritos (FAPI 1.0 Advanced ou 2.0), adiciona-se JWT / JWS / JWE para as requisições assinadas (JAR) e o binding do token ao certificado de cliente. É obrigatório no Reino Unido, opcional / não imposto no Berlin Group e no STET.
Os três fluxos SCA a suportar
O momento em que o PSU se autentica junto ao seu banco (a SCA) pode assumir três formas, e é o banco que escolhe, não você. Cobrir todo o mercado obriga a tratar as três — veja Flux SCA.
| Fluxo | Como funciona | Quando o banco o escolhe |
|---|---|---|
| Redirect | O PSU é redirecionado para o site ou o app do seu banco e depois volta. | O padrão de fato na França. |
| Decoupled | Push notification no app bancário, validação biométrica, polling no lado do TPP. | Neobancos, melhor UX mobile. |
| Embedded | O PSU digita suas credenciais na interface do TPP, que as transmite. | Raro, desaconselhado, muitas vezes recusado. |
Armadilhas frequentes:
- No decoupled, alguns bancos exigem um intervalo mínimo entre o disparo e o polling, outros limitam o número de chamadas e impõem um webhook.
- No redirect, os retornos mobile via deep link são fonte de bugs: preveja um fallback web.
- Uma única SCA inicial, e depois 180 dias de acesso AIS via refresh token sem nova SCA — é o regulamento EBA de 2022. Antes de 2022, eram 90 dias.
O consentimento: um objeto a modelar de ponta a ponta
O consentimento não é uma variável booleana. É um objeto armazenado no lado do banco, com:
- Um perímetro (contas, tipos de acesso: saldos, transações, detalhes).
- Uma janela temporal (até 180 dias para AIS, de uso único para PIS).
- Uma frequência (4 atualizações por dia sem a presença do PSU).
- Um estado que evolui ao longo do tempo.
No lado da implementação, você deve:
- Persistir o consentId e vinculá-lo ao seu PSU.
- Monitorar o seu estado (poll + webhook se disponível).
- Disparar uma renovação antes da expiração, idealmente com uma UX que se antecipe.
- Gerenciar a revogação no lado do banco: um consentimento ativo no seu lado pode ser desligado sem que você saiba enquanto não chamar a API.
Segurança: mTLS, assinatura, idempotência
Três exigências técnicas estruturam toda integração DSP2.
- mTLS em todas as chamadas back-channel. O TPP apresenta seu QWAC, o banco apresenta o seu.
- HTTP Signature das requisições via QSealC: a assinatura cobre os cabeçalhos críticos e um hash do body. Indispensável no lado PIS para não poder negar uma iniciação de pagamento.
- Idempotency key em todas as operações PIS para evitar pagamentos em duplicidade em caso de retry de rede.
A isso se soma a gestão robusta dos erros: códigos HTTP, códigos de negócio próprios de cada padrão, rate limits, janelas de manutenção bancária. Nenhuma API ASPSP tem SLA contratual de 99,99 %.
Webhook ou polling?
Para acompanhar o estado de um consentimento, de um pagamento iniciado ou de um fluxo SCA decoupled, dois mecanismos coexistem — veja Webhook / Polling.
- Polling: o TPP consulta a API de status em intervalos. Universal, mas custoso e lento.
- Webhook: o banco chama um endpoint do TPP. Reativo, mas poucos bancos expõem um confiável no lado DSP2 da UE.
Na prática, combina-se: webhook quando disponível, polling de reserva, com backoff exponencial.
Testar sem quebrar a produção
Três ambientes a conhecer:
- Sandbox pública: aberta, sem certificados eIDAS reais. Útil para o POC.
- Sandbox certificada: exige certificados de teste emitidos por um QTSP, com processo de inscrição por banco. É aqui que se valida a integração de ponta a ponta.
- Produção: exige a autorização ACPR (ou equivalente), certificados QWAC + QSealC válidos e o registro prévio junto a cada banco.
A passagem da sandbox para a produção raramente é transparente: tamanho dos payloads, latências, códigos de erro, SCA real versus simulada — cada banco reserva surpresas.
E depois? O que DSP3 e PSR mudam
Para as equipes técnicas, as evoluções a antecipar:
- Qualidade de API medida e publicada pelos reguladores: SLA, tempos de resposta, taxa de erro.
- Fim do screen scraping: nada de fallback fora da API.
- Antifraude reforçado (em especial APP fraud): VoP (Verification of Payee) nos SEPA, compartilhamento de indicadores entre atores.
- Convergência FAPI mais que provável, alinhamento com a EUDI Wallet para a identidade.
- FIDA: extensão a novas famílias de dados (poupança, crédito, seguros). O modelo técnico é muito inspirado na DSP2, mas com esquemas de permissões mais finos.
Para resumir
Construir ou integrar uma API DSP2 não é «plugar mais uma API REST». É:
- Escolher um ou vários padrões (STET, Berlin Group, eventualmente OB UK).
- Obter e manter vivos os certificados eIDAS (QWAC + QSealC).
- Implementar OAuth2 com PKCE, assinatura de requisição e idempotência.
- Suportar os três fluxos SCA no lado UX e no lado backend.
- Modelar o consentimento como um objeto de primeira ordem, com seu ciclo de vida.
- Gerenciar a fragmentação banco a banco — ou terceirizá-la para um agregador.
Para a versão de produto / negócio, leia Entender a PSD2 visualmente. Para o vocabulário completo, o glossário Open Banking está indexado por categoria.