Flux SCA

Definição

Os fluxos SCA definem como um PSU faz sua autenticação forte junto ao seu ASPSP, em um consentimento PSD ou em uma iniciação de pagamento.

A PSD2 prevê três modos — redirect, decoupled, embedded — e cada banco escolhe qual oferece. Para um TPP que quer cobrir todo o mercado, dominar os três é indispensável.

Os 3 modos em resumo

• Redirect — o PSU é redirecionado para a página ou o app do banco para se autenticar e depois retorna ao TPP. O mais comum na França.
• Decoupled — o PSU permanece na interface do TPP, mas valida o SCA por uma notificação push no app do banco. A UX mais fluida.
• Embedded — o PSU insere seus fatores de SCA diretamente na interface do TPP, que os transmite ao banco. O mais raro e o menos recomendado.

Redirect: o padrão de fato

O mais difundido, sobretudo na França e na Alemanha. O TPP redireciona para a URL de autenticação do ASPSP; o PSU se identifica na página real do seu banco (biometria, SMS, push) e retorna com um código OAuth2. Vantagens: familiar, responsabilidade clara do lado do banco, integração simples. Desvantagens: saída do contexto do TPP (perda de marca), retornos às vezes mal-sucedidos no mobile (deep links), atrito se a sessão bancária tiver expirado.

Decoupled: a melhor UX

O TPP dispara o SCA do lado do ASPSP, que envia uma notificação push no app bancário; o PSU valida por biometria no celular, sem sair do site do TPP, que faz polling do status. Vantagens: manutenção do contexto, biometria nativa, sem redirecionamento. Desvantagens: pressupõe o app bancário instalado, gestão mais complexa (polling ou webhook), suporte desigual entre os bancos.

Embedded: a evitar, salvo caso específico

O TPP exibe um formulário para inserir credenciais e fatores de SCA, que transmite ao banco. Vantagem: nenhum redirecionamento. Grandes desvantagens: risco de phishing (o PSU se acostuma a inserir suas credenciais fora de contexto), responsabilidade ambígua, sem biometria e um modo mal visto pelos reguladores — a maioria dos grandes bancos o recusa.

Comparação resumida

No ecossistema PSD2

O fluxo é escolhido pelo ASPSP, não pelo TPP. Do lado do TPP, é preciso detectar dinamicamente o modo ou os modos de cada banco e adaptar a integração. Os agregadores (Bridge, Tink, TrueLayer) absorvem essa complexidade.

Exemplos concretos

• Bancos franceses (redirect): BNP Paribas, Société Générale, Crédit Agricole, LCL, BPCE e La Banque Postale privilegiam o redirect, com o SCA acontecendo em seu app via push.
• Neobancos (decoupled): N26, Revolut, Boursorama e Hello Bank costumam oferecer um modo decoupled mais fluido, sobretudo no mobile.
• Caso PISP: no checkout, a Fintecture precisa detectar o banco já na digitação do IBAN, rotear para o fluxo certo e gerenciar o polling em decoupled — daí seu valor agregado frente a uma integração banco a banco.
• Conversão: passar do redirect ao decoupled pode ganhar de 10 a 15 pontos de conversão em um carrinho de e-commerce.
• Caso AISP: um único SCA completo na conexão e, depois, 180 dias de refresh via token OAuth2 sem novo SCA.
• Armadilhas: alguns bancos exigem um intervalo mínimo antes do polling, outros impõem um webhook — ler a documentação de cada ASPSP é obrigatório.
• Evolução PSR: o banco só vai pedir SCA no primeiro acesso de um AISP, e depois o próprio AISP vai autenticar o usuário com SCA pelo menos a cada 180 dias (art. 86). Um banco não poderá exigir SCA duas vezes no mesmo fluxo de iniciação (art. 44(1)(l)) nem acrescentar etapas em relação ao seu canal direto (art. 44(1)(j)). O PISP vai escolher o procedimento de autenticação quando o banco oferecer mais de um (art. 36(4)(ha)). Texto ainda não adotado, numeração provisória do texto de compromisso de abril de 2026.