Autenticação forte de cliente e a PSD2: o bom, o ruim e o péssimo

Em alguns dias, em 14 de setembro de 2019, os tão esperados requisitos de autenticação forte do cliente (SCA) sob o PSD2 finalmente entrarão em vigor. Publicados há cerca de 18 meses pela Comissão Europeia nos Padrões Técnicos Regulatórios (RTS) sobre Autenticação Forte do Cliente e Comunicação Comum e Segura, esses requisitos afetarão a forma como os consumidores na Europa acessam seus aplicativos de Internet banking, pagam por compras de comércio eletrônico e usar novos serviços financeiros fornecidos por Terceiros Provedores (TPPs) via Open Banking.

Neste artigo, examinamos o SCA no PSD2 e avaliamos o que deu certo e o que é necessário para uma implantação ainda mais bem-sucedida do SCA na Europa.

1) O bom

O PSD2 está aumentando o nível de segurança para autenticação de serviços financeiros em toda a Europa e está harmonizando a força dos processos de autenticação para aplicativos financeiros.Por causa do PSD2, as instituições financeiras têm eliminado os métodos de autenticação fracos. Os exemplos são soluções baseadas exclusivamente em combinações de nome de usuário / senha e soluções baseadas em listas impressas de códigos de autenticação, como listas TAN e cartões de matriz. Conforme confirmado pelo Parecer da Autoridade Bancária Europeia (EBA) de 21 de junho, estas soluções não cumprem os requisitos do SCA.

O PSD2 garante que os conceitos de autenticação avançados, como vínculo dinâmico, vinculação de dispositivo para aplicativos móveis, proteção de aplicativos móveis e análise de risco de transação se tornem ferramentas de segurança padrão em serviços financeiros. Nesse aspecto, o PSD2 vai muito além do EBA Diretrizes finais sobre a segurança de pagamentos pela Internet , que se tornou aplicável em 1 de agosto de 2015 e será substituído por PSD2 em 14 de setembro.

O PSD2 também está acelerando a adoção de métodos de autenticação adaptativos, que ajustam a maneira como o usuário é autenticado ao risco do que o usuário deseja fazer. Como tal, o PSD2 permite atingir um equilíbrio específico do usuário entre conveniência e segurança. Esta abordagem foi incluída no RTS graças à abertura e estreita colaboração da EBA com os participantes da indústria durante a elaboração do RTS.

2) O Mau

O PSD2 atribui aos bancos a responsabilidade de proteger o acesso às contas bancárias, também conhecidos como Account Servicing Payment Service Providers (ASPSPs). Como os bancos são donos das contas bancárias, isso parece fazer sentido à primeira vista.

No entanto, ao olhar mais de perto, torna-se claro que esta abordagem cria uma complexidade significativa no contexto do Open Banking, da seguinte forma:

• Em primeiro lugar, os usuários de aplicativos TPP precisarão se autenticar duas vezes: uma vez para acessar o aplicativo TPP e uma segunda vez para usar uma determinada conta bancária por meio do aplicativo TPP.

• Além disso, o método e o fluxo de autenticação de uma determinada conta bancária dependem do banco. Por exemplo, o banco A pode implementar autenticação usando um leitor de cartão e abordagem de “redirecionamento”, enquanto o banco B pode usar um aplicativo móvel por meio da abordagem “desacoplada”. Portanto, a experiência do usuário no aplicativo TPP dependerá do banco.

Como consequência, a experiência geral de autenticação para o usuário TPP médio promete ser complicada.

No entanto, o PSD2 em si não é o culpado por isso. O problema é a consequência de um problema maior que transcende o PSD2, a saber, a ausência de um sistema de identidade digital pan-europeu baseado em identidades verificadas e confiáveis. A inspiração para tais sistemas já pode ser encontrada em vários países, como Suécia (ID do Banco) e Índia (Aadhaar). O desafio é construir esse sistema a nível europeu. Esse sistema é fundamental para o futuro do Open Banking.Artigo recente do Citi fornece mais inspiração para isso.

3) O Feio

Os requisitos SCA do PSD2 devem ser preparados para o futuro e independentes de tecnologia. Eles fornecem alguma margem de manobra para os Provedores de Serviços de Pagamento (PSPs), o que significa que os PSPs podem decidir a melhor forma de atender a um determinado requisito.No entanto, isso pode deixar os PSPs, que precisam atender aos requisitos, no escuro. Alguns exemplos:

• Uso de SMS para links dinâmicos . A EBA esclareceu no seu parecer de 21 de junho que o SMS pode ser considerado um elemento de posse válido. Mais especificamente, o cartão SIM no dispositivo móvel que recebe o SMS é um elemento de posse válido. Isso implica que as senhas de uso único (OTPs) entregues via SMS podem ser usadas para construir um mecanismo de autenticação forte quando combinado com um segundo fator (por exemplo, uma senha ou PIN). No entanto, o parecer não esclarece se o SMS pode ser utilizado para ligações dinâmicas. Na verdade, o requisito de ligação dinâmica no Artigo 5 do RTS estipula que a confidencialidade e integridade das informações de pagamento (por exemplo, número da conta bancária, quantia em dinheiro) devem ser protegidas durante o processo de autenticação. Uma vez que o conteúdo de um SMS normalmente não é protegido, parece O SMS não atende aos requisitos de link dinâmico .

• Criação de um ambiente de execução segura para aplicativos móveis . O RTS afirma que os PSPs devem usar ambientes de execução seguros para proteger os aplicativos móveis. No entanto, o RTS final não define o que um ambiente de execução seguro realmente é, ou Como as poderia ser implementado. Dado o estado atual da segurança de aplicativos móveis, a melhor abordagem para atender a esse requisito provavelmente consiste em usar tecnologia de proteção de aplicativos , protegendo o aplicativo contra ameaças como sobreposições, injeção de código e keylogging.

Finalmente, o cronograma para a aplicação dos requisitos SCA de PSD2 começou a mudar nos últimos meses. Originalmente, os requisitos SCA para aplicativos de Internet banking e comércio eletrônico se tornariam aplicáveis em 14 de setembro de 2019. Na mesma data, entraria em vigor a exigência de que os bancos forneçam uma interface de comunicação para o Open Banking. No entanto, desde que a EBA publicou o seu parecer em 21 de junho, os prazos tornaram-se mais fragmentados. No momento da redação, os prazos são os seguintes:

• Prazo para os bancos implementarem SCA para serviços bancários pela Internet: 14 de setembro de 2019, exceto no Reino Unido, onde o prazo agora é 14 de março de 2020

• Prazo para implementação de SCA para pagamentos com cartão para e-commerce: atrasos específicos do país são permitidos

• Prazo para os bancos oferecerem interfaces de banco aberto: 14 de setembro de 2019

Como consequência, diferentes PSPs podem ter diferentes cronogramas para cumprir os requisitos do SCA, e isso pode afetar os pagamentos quando vários PSPs estão envolvidos. Por exemplo, se um pagamento com cartão for realizado entre um emissor de cartão que está em conformidade em 14 de setembro de 2019 e um adquirente que recebeu uma extensão de digamos 6 meses, o adquirente pode enviar uma solicitação de pagamento sem SCA para o emissor, mas o o emissor recusará o pagamento porque requer SCA. Como consequência, os pagamentos podem ser recusados, embora o emissor e o adquirente ajam corretamente. Isso claramente aumenta a necessidade de Autoridades Competentes (ACs) concederem extensões de uma forma coordenada. A EBA deve desempenhar o papel de coordenador entre as diferentes ACs aqui.

No filme épico de Sergio Leone de 1966, o Bom leva o ouro, o Mau morre e o Feio é salvo pela misericórdia do Bom. Esperemos que o roteiro do filme se aplique ao PSD2 também.

RELATÓRIO BRANCO

PSD2: quais soluções fortes de autenticação e transação cumprem?

Descubra os requisitos mais importantes do RTS final e quais soluções de autenticação têm maior probabilidade de atender aos requisitos.

Baixar Agora

Uma análise mais aprofundada do PSD2 e seus requisitos de autenticação forte do cliente é disponivel aqui .