Desafios bancários se somam: PSD2 significa novas regras de compartilhamento de dados

Publicados: 2018-04-13

Muitos de vocês, sem dúvida, já ouviram falar da diretiva da Autoridade Bancária Europeia (ou EBA) da União Européia chamada PSD2 (abreviação de Diretiva de Serviços de Pagamento). Essas diretrizes foram publicadas originalmente no final de 2015. Em janeiro de 2018, todos os estados membros foram obrigados a implementar os regulamentos.

O setor bancário está enfrentando muitos desafios se já não estiver pensando em um futuro muito digital.

Entendendo a autenticação forte do cliente para PSD2 da UE

Os principais objetivos do PSD2 incluem:

  1. Abrindo novas oportunidades de mercado para uma variedade de players, como comerciantes on-line, ao mesmo tempo em que nivelamos o campo de jogo para todas as principais partes interessadas
  2. Proporcionar transparência ao consumidor e escolha do consumidor
  3. Apresentando novas e mais robustas práticas de segurança para pagamentos online

Há uma série de diretrizes em geral para PSD2; no entanto, uma das melhores Diretrizes PSD2 pode ser baixada do MEF (Mobile Ecosystem Forum).

Autenticação forte do cliente

Um dos elementos-chave dos regulamentos PSD2 é o conceito de autenticação forte do cliente (ou SCA). A EBA observa: “Graças ao PSD2, os consumidores estarão mais protegidos quando fizerem pagamentos ou transações eletrônicas (como usar seu banco on-line ou comprar on-line).

O Regulatory Technical Standard (RTS) torna a autenticação forte do cliente (SCA) a base para acessar a conta de pagamento, bem como para fazer pagamentos online.” Em resumo, o SCA exige, no mínimo, autenticação de dois fatores (2FA).

A autenticação de dois fatores significa que os usuários terão que “provar” sua identidade por dois elementos separados de três:

  1. Algo que eles sabem (um código PIN ou senha)
  2. Algo que eles possuem (um dispositivo móvel, um cartão)
  3. Algo que eles são (impressões digitais, varredura facial: por exemplo, biometria)

A EBA observa que o SCA é comumente usado em toda a UE; no entanto, isso nem sempre é o caso de transações de pagamento on-line, como pagamento com cartão de crédito ou transferência bancária direta. A SCA é aplicada nos países da UE da Bélgica, Holanda e Suécia); no entanto, em outros países da UE, a SCA é aplicada apenas de forma voluntária, de acordo com um excelente comunicado de imprensa da Comissão Europeia.

Enquanto os estados membros da UE deveriam ter implementado o PSD2 até janeiro de 2018, o SCA se tornará obrigatório 18 meses depois da Norma Técnica Regulatória da EBA (RTS) após a data de entrada em vigor do RTS (que está prevista para ser ainda este ano) . Então, em essência, estamos olhando para meados do final de 2019 (setembro de 2019 foi uma dessas datas citadas por alguns documentos). Isso permitirá que todas as partes interessadas tenham tempo suficiente para incorporar o SCA e outros requisitos de segurança em seus sistemas e fluxos de trabalho.

Banco de varejo: Leões, banqueiros e fintechs, oh meu Deus!

varejo_banking_fintech.jpg Fintechs ameaçam o status quo. Ao contrário dos bancos, eles estão livres de legados, regulamentações e, na maioria dos casos, até mesmo da necessidade de ganhar dinheiro. Os banqueiros de varejo precisam se adaptar e se concentrar no relacionamento com os clientes para competir.

2FA para SCA

Dada a linha do tempo da SCA, 2018 é o momento perfeito para as empresas começarem a implementar soluções 2FA para dar conta do aumento de segurança necessário.

O escritório de advocacia internacional Taylor Wessing, em seu artigo: Strong customer authentication under PSD2 , observa que “A EBA concordou com a maioria dos entrevistados no Documento de Consulta que, para garantir a neutralidade tecnológica e permitir o desenvolvimento de , meios de pagamento acessíveis e inovadores, não deve definir mais os elementos de autenticação.” Isso significa que a EBA não especifica a maneira pela qual o 2FA pode ser implementado. Há uma variedade de esquemas, incluindo entrega de token em canais móveis, como SMS ou notificações push ou canais de e-mail mais tradicionais, bem como soluções de token soft TOTP e outros.

Tudo isso observado, devemos salientar que, como qualquer bom esquema de implementação de 2FA, existem algumas limitações e regulamentações específicas e estas precisam ser cuidadosamente consideradas.

Códigos de autenticação

O RTS observa que a geração de um código de autenticação atende às seguintes condições:

  1. Nenhuma informação sobre o conhecimento, posse e herança pode ser derivada da divulgação do código de autenticação
  2. Não é possível gerar um novo código de autenticação com base no conhecimento de qualquer outro código de autenticação gerado anteriormente
  3. O código de autenticação não pode ser forjado

Além disso, o RTS afirma que não devem ser tentadas mais de 5 tentativas de autenticação com falha dentro do tempo de vida do código e que o tempo máximo sem atividade do pagador ou usuário após ser autenticado para acessar sua conta de pagamento online não deve exceder 5 minutos .

Vinculação dinâmica da transação

O RTS indica que as transações eletrônicas remotas – essencialmente pagamentos feitos pela Internet (seja em um dispositivo desktop, como um laptop ou dispositivo móvel) devem incluir elementos que “vinculem dinamicamente a transação a um valor específico e a um beneficiário específico”. O RTS considera isso uma forma adicional de SCA.

Para este requisito de SCA, o valor da transação de pagamento, bem como quem é o beneficiário (ou comerciante) deve ser fornecido de volta ao usuário no momento de uma transação 2FA. Se houver alguma alteração no valor ou no beneficiário, outro código de autenticação deve ser gerado (por exemplo, “vinculando dinamicamente” esse código ao novo beneficiário e/ou valor do pagamento). Uma mensagem SMS com todas as informações necessárias pode ser semelhante à imagem à direita: O código de segurança de 10 minutos, o nome do comerciante (ou beneficiário) e o valor da transação.

Curiosamente, um código de autenticação gerado por um aplicativo compatível com TOTP de terceiros, como o Google Authenticator, é gerado completamente separado das informações de pagamento/comerciante e, portanto, não pode ser vinculado dinamicamente.

Independência do canal

Este requisito é um pouco complicado. A RTS estabelece que “os prestadores de serviços de pagamento devem adotar medidas de segurança, sempre que algum dos elementos de autenticação forte do cliente ou o próprio código de autenticação seja utilizado através de um dispositivo multifuncional, para mitigar o risco que resultaria desse dispositivo multifuncional sendo comprometido”. Um dispositivo multifuncional pode ser um dispositivo móvel ou tablet, ou até mesmo um laptop.

Se um usuário estiver em um laptop e for solicitado a fazer um pagamento, esse comerciante poderá enviar um SMS para o dispositivo móvel do usuário com o beneficiário (por exemplo, o comerciante), bem como o valor que ele pagará, juntamente com a autenticação código no corpo do SMS.

Em outro exemplo, se o usuário estiver usando um dispositivo móvel para interagir com um comerciante e iniciar um pagamento, essa independência de canal não proíbe especificamente o SMS ou qualquer canal de entrega específico para celular. Aqui, é uma linha tênue. Em muitos casos, o único dispositivo que um usuário possui é um dispositivo multifuncional, como um telefone celular. Mas, independência de canal é apenas isso – um canal independente no mesmo dispositivo – um SMS com um código de autenticação é um canal diferente (na verdade, é um canal fora de banda , alcançado através do número de telefone móvel) do que o canal móvel aplicativo ou navegador da Web que o usuário está interagindo com o comerciante. A mesma independência de canal se aplicaria ao uso do aplicativo móvel para gerar um código compatível com TOTP (como o Google Authenticator), mas, conforme observado anteriormente, o código de reclamação TOTP falha na vinculação dinâmica da transação.

Por outro lado, se o usuário estivesse usando um aplicativo móvel para acessar o comerciante, não seria possível uma notificação push para esse mesmo aplicativo (com o código de autenticação), pois são o mesmo canal.

Há quem diga que 2FA sobre SMS é muito inseguro e, em alguns casos, isso pode ser verdade. Sim, houve alguns casos isolados em que um invasor conseguiu acessar mensagens SMS 2FA via SS7 em um operador; no entanto, muitas dessas vulnerabilidades foram fechadas. Além disso, importa muito como o código de autenticação é gerado e fornecido ao usuário e como o provedor de serviços de mensagens entrega esses códigos.

Em situações em que os dispositivos multifuncionais são predominantes (e hoje, esses são e continuarão sendo os dispositivos mais predominantes), um canal de mensagens fornecido pela operadora móvel deve continuar a ser um canal fora de banda viável para tokens 2FA.

Para uma análise mais detalhada, encontrei um post informativo no blog de Frederik Mennes que fornece mais detalhes sobre quais tipos de cenários – especialmente para dispositivos multifuncionais – devem ser compatíveis com PSD2 SCA.

PSD2 SCA não deve ser encarado de ânimo leve, mas muitas soluções 2FA já implementadas devem funcionar; no entanto, também sabemos que muitos comerciantes on-line ainda não estão fornecendo soluções compatíveis com PSD2 SCA. No momento da redação deste artigo, ainda há tempo suficiente para incorporar o SCA nos fluxos de trabalho de pagamento.

O SAP Authentication 365 é uma solução que fornece uma solução em nuvem baseada em API para permitir que as empresas implementem SCA compatível com PSD2. O serviço móvel SAP Authentication 365 é um serviço de ponta a ponta que permite implementar um serviço de autenticação multicanal de dois fatores (2FA) de forma rápida e segura, com autenticação adaptada ao seu negócio digital.

Ele ajuda a proteger a identidade e os dados de seus clientes corporativos, habilitando a autenticação via SMS, e-mail, notificações push ou tokens TOTP. A API REST da SAP simplifica a geração e autenticação de códigos de validação ou autenticação e fornece flexibilidade e recursos para permitir a implementação de uma estratégia SCA compatível com PSD2.