Fórum de perguntas e respostas do PSD2

Pesquise mais de 40 perguntas sobre tópicos como autenticação, segurança de aplicativo móvel de vinculação dinâmica e muito mais

Quais são as penalidades se os PSP's não cumprirem os novos regulamentos RTS até novembro de 2018?

O PSD2 é uma diretiva européia que todos os estados membros da UE precisam adotar. Os prestadores de serviços de pagamento precisam cumprir os requisitos do PSD2 para serem legalmente reconhecidos como prestadores de serviços de pagamento com o direito de prestar serviços na UE.

A EBA publicará um guia de avaliação do RTS no SCA e CSC semelhante ao guia do BCE publicado em 2014?

Não temos informações que confirmem ou neguem que a EBA emitisse um guia de avaliação semelhante.

O SMS é compatível com o PSD2?

Um dos objetivos da EBA em seu RTS era permanecer neutro em termos de tecnologia para fornecer o máximo de espaço possível para inovação. O desafio era não ser muito prescritivo ao especificar os requisitos. Por fim, nenhuma tecnologia específica é banida pelo RTS; no entanto, algumas das práticas existentes não serão mais totalmente compatíveis com os requisitos de SCA. Podemos dizer que o SMS pode ser visto como um elemento de posse, pois normalmente só pode ser lido pelo destinatário da mensagem do SMS. Portanto, em teoria, o SMS atende ao requisito de elemento de posse e, portanto, pode ser usado como um componente básico de uma solução de assinatura de transação.

Para atender aos requisitos de vinculação dinâmica, a mensagem SMS precisa incluir as informações de pagamento, ou seja, a quantidade de dinheiro e informações sobre o beneficiário, além do código de autenticação. Os requisitos de vinculação dinâmica também indicam que a confidencialidade e a integridade das informações de pagamento precisam ser protegidas. Isso pode implicar que as informações de pagamento precisam ser criptografadas. No entanto, descriptografar o conteúdo de uma mensagem SMS exigiria um aplicativo no cartão SIM do celular ou no próprio telefone, o que não é prático.

No final, o uso de SMS implica em ter um alto nível de segurança para o dispositivo do usuário, proteção contra fraudes na troca de SIM, proteção contra possíveis intercepções e uso indevido de SMS. Na realidade hoje, esses são desafios muito difíceis. Atualmente, diferentes autoridades competentes têm opiniões diferentes sobre o uso do SMS. Várias autoridades desencorajam o uso de SMS, enquanto outras o permitem. Monitoramos essas opiniões e atualizaremos essas Perguntas frequentes quando houver uma decisão clara.

O celular e o token podem ser contados como dois canais e compatíveis com PSD2?

De acordo com o PSD2, o mecanismo de autenticação deve ser construído a partir de dois dos três possíveis elementos de autenticação, ou seja, algo que apenas o usuário possui, algo que apenas o usuário conhece e algo que apenas o usuário é.

Quando você usaria o código de autenticação? Você considera isso um segundo fator?

O código de autenticação sempre deve ser usado para autenticar um usuário. O código de autenticação deve ser gerado por um mecanismo de autenticação que é construído a partir de dois dos três possíveis elementos de autenticação, ou seja, algo que apenas o usuário possui, algo que apenas o usuário conhece e algo que somente o usuário é.

O protocolo seguro 3D para placas é suficiente para o SCA ou é obrigatório?

O 3D Secure é realmente um protocolo que pode ser usado pelos PSPs para criar uma solução para atender aos requisitos de SCA para pagamentos baseados em cartão.

Qual categoria dos três elementos do SCA você pode atribuir ao OTP por SMS? Isso é conhecimento ou posse?

O usuário recebe a mensagem SMS normalmente em um telefone pessoal, portanto isso seria um elemento de posse.

Você poderia esclarecer o escopo do PSD2? É apenas pagamentos pela Internet (online, com base no navegador)? Se não, o que mais?

O PSD2 abrange pagamentos móveis e baseados em navegador.

Você pode nos contar mais sobre como implementar a análise de comportamento? É uma extensão do DP4APPS SDK?

A autenticação comportamental do OneSpan é uma extensão do OneSpan Mobile Security Suite. A autenticação comportamental permite não apenas provar de forma precisa e sem problemas a identidade do usuário, mas também identificar comportamentos específicos, como ataques de bot. Mais informações estão disponíveis aqui.

Os clientes do OneSpan Mobile Security Suite podem aproveitar sua implementação existente adicionando apenas os novos componentes necessários da solução. Para obter a melhor combinação de segurança e facilidade de uso, hoje é importante combinar todos os três elementos: 

  1. Segurança de aplicativos móveis com coleta de dados do dispositivo cliente 
  2. Estrutura de autenticação multifatorial e biométrica e canal seguro para comunicação segura 
  3. Software de análise de fraude e risco para analisar entradas, dispositivos, comportamento e aplicação de decisões do usuário em tempo real em vários canais O conjunto de soluções da OneSpan abrange todas essas áreas. 

 

Mais informações sobre Conformidade com PSD2 .

Existe alguma orientação sobre se a validação ao usar biometria deve ocorrer no lado do servidor ou no cliente?

As Normas Técnicas Regulatórias (RTS) sobre Autenticação Forte do Cliente não especificam se a verificação biométrica deve ocorrer no lado do cliente ou do servidor. Portanto, ambas as opções são permitidas.

O OneSpan recebeu garantias formais do BCE em relação à conformidade de seus tokens com o PSD2 RTS?

No momento, não existe um programa formal de certificação para produtos específicos no PSD2. Como tal, não é possível para o OneSpan obter garantia formal. No entanto, a OneSpan discute a conformidade de seus produtos de maneira informal com as autoridades competentes, a fim de garantir a interpretação correta do RTS e garantir a conformidade dos produtos.

Você pretende rotular cada modelo de token (por exemplo, DP310) com uma indicação de conformidade com PSD2?

O OneSpan não está planejando fazer isso no momento. Além disso, não existe um programa formal de certificação para soluções fortes de autenticação no PSD2.

Os dispositivos de hardware de autenticação pin-pad OneSpan são compatíveis?

Os requisitos de vinculação dinâmica no RTS afirmam que o código de autenticação deve ser calculado sobre determinadas informações da transação, incluindo a quantidade de dinheiro e informações sobre o beneficiário (por exemplo, o número da conta bancária do beneficiário).

Além disso, o pagador deve estar ciente dessas informações da transação. Finalmente, a confidencialidade, integridade e autenticidade das informações da transação devem ser protegidas o tempo todo. Com base nesses requisitos, podemos dizer o seguinte sobre o uso de dispositivos de hardware de autenticação com teclado PIN:

  • Este dispositivo fornece um nível de segurança de elementos de posse e conhecimento muito altos 
  • Este dispositivo fornece uma maneira para o usuário final inserir os detalhes do valor e do beneficiário e incluí-los na geração de um código de autenticação exclusivo 
  • O usuário está ciente das ações com esse dispositivo. Portanto, o Digipass de hardware com teclado PIN, se usado com o modo de assinatura de dados de transação, é compatível com os requisitos de vinculação dinâmica.

A vinculação dinâmica é igual à assinatura da transação?

Sim, ele é. O termo "ligação dinâmica" é usado pelo PSD2 e pelo RTS no SCA.

Isso significa que o OneSpan fornece o vínculo dinâmico, em vez de uma entidade separada, como o PSP?

É de responsabilidade do PSP executar autenticação forte de seus usuários. O OneSpan pode fornecer aos PSPs produtos e serviços para executar autenticação forte.

O RTS requer separação de canais entre o aplicativo que usará a transmissão OTP e OTP. Como você vê a conformidade com 1AA?

O rascunho final do RTS não requer mais segregação de canais. Conforme indicado nos comentários no rascunho final do RTS, esse idioma foi removido do rascunho do RTS, porque era confuso.

Como você cumpre o requisito do artigo 2 (2) A) quando um cliente faz vários pagamentos juntos para diferentes beneficiários?

Para pagamentos em massa, o código de autenticação deve ser calculado com base na quantia total de dinheiro de todos os pagamentos combinados e com base nos números de conta de todos os beneficiários.

O OneSpan possui soluções para gerar vínculo dinâmico nos casos em que os clientes não estão dispostos a usar smartphones?

Hoje, o OneSpan fornece soluções de autenticação para mais de 2.000 bancos em todo o mundo, com vários casos de uso, necessidades de negócios, grupos de usuários e requisitos regulatórios. Isso é possível porque o OneSpan oferece uma gama muito grande de soluções que podem cobrir todas as necessidades possíveis. Por exemplo, o OneSpan fornece dispositivos muito simples de usar compatíveis com PSD2 com telas grandes, botões e até comandos de voz para usuários idosos: Digipass 301

Opcionalmente, no espaço SWYS, uma opção popular é usar um dos dispositivos de última geração com um teclado de borracha robusto: Digipass 770

Este dispositivo não precisa de entrada completa do usuário, apenas precisa da aprovação do cliente e entrada curta do PIN. Os estudos de aceitação do usuário realizados pelos clientes OneSpan mostram uma taxa de adoção muito alta e um declínio essencial nas chamadas de helpdesk dos usuários ao mudar para esta tecnologia.

Para autenticação por SMS usando um processo 3DS, ainda precisamos incluir detalhes de pagamento quando um ACS gera o OTP e o distribui para o número de celular registrado?

Nossa interpretação dos requisitos de vinculação dinâmica no rascunho final do RTS é de fato que as informações de pagamento precisam ser incluídas na mensagem SMS para autenticação de pagamento.

Temos um hardware Digipass 275 com 5 números que pode ser usado como uma resposta desafiadora para vinculação dinâmica. Isso é compatível com links dinâmicos?

Provavelmente, isso é compatível com o rascunho final do RTS.

O OneSpan Go 6 Digipass é compatível com o RTS no que diz respeito ao requisito de vinculação dinâmica para pagamentos de alto valor?

Em geral, os Go-tokens não geram códigos de autenticação sobre informações de pagamento (como a quantidade de dinheiro). Por esse motivo, ele não pode ser usado para a vinculação dinâmica, que é sempre necessária para pagamentos acima de 500 euros.

Como as soluções baseadas em hardware, como tokens OTP, fornecem vínculo dinâmico com transações únicas?

Em geral, os usuários podem inserir informações de pagamento, como a quantia em dinheiro e o número da conta do beneficiário, em tokens de hardware. Isso pode acontecer através do teclado do token, via cabo USB ou digitalizando um código visual. O token de hardware pode usar as informações de pagamento para calcular um código de autenticação de acordo com os requisitos de vinculação dinâmica.

O PSU precisa ver os detalhes do pagamento (valor e conta) no token? O que você vê é o que você assina?

“Veja o que você assina” nos tokens de hardware pode ser usado para atender ao requisito de vinculação dinâmica, mas não é a única opção. A exibição dos dados em um aplicativo móvel provavelmente também será aceitável.

Você poderia ser mais específico sobre várias possibilidades de assinatura / autorização de transação? A vinculação dinâmica permite várias transações / beneficiários?

O rascunho final do RTS indica que, no caso de pagamentos em massa, o código de autenticação deve ser calculado sobre o valor total dos pagamentos, bem como informações sobre os beneficiários dos vários pagamentos.

Ainda é necessário o vínculo dinâmico para pagamentos abaixo de 30 euros em caso de implementação da solução de monitoramento de transações?

Não, a vinculação dinâmica não é necessária para pagamentos abaixo de 30 EUR, desde que o valor cumulativo ou o número de transações de pagamento eletrônico remoto anteriores iniciadas pelo pagador desde a última aplicação de autenticação forte do cliente não exceda, respectivamente, 100 ou cinco EUR transações individuais remotas consecutivas de pagamento eletrônico.

Se forem usadas isenções, é correto que o SCA no total possa ser ignorado e não apenas a vinculação dinâmica?

Essa é a nossa compreensão também.

Qual é a opinião da OneSpan sobre o RTS para bancos corporativos?

O RTS no SCA fornece requisitos mínimos de segurança para autenticação de usuários. No caso de bancos corporativos, os usuários normalmente efetuam pagamentos de valores relativamente altos. Portanto, esperamos que os bancos protejam seus aplicativos bancários corporativos com mecanismos de autenticação mais fortes do que o exigido pelo RTS no SCA.

Quais são os requisitos se o cliente já tiver uma lista de beneficiários certificados com SA, mas precisar fazer uma transferência de dinheiro com um valor diferente?

Conforme indicado no artigo 13 do projeto final de RTS, o SCA não é necessário para pagamentos a beneficiários confiáveis. Para condições precisas, consulte o próprio artigo.

O RTS permite autenticação de fator único somente após a primeira tentativa. O 2FA deve ser usado a cada 9 dias. Isso é diferente do que você recomendou no passado. Por favor explique?

O artigo 10 do rascunho final do RTS estabelece que os prestadores de serviços de pagamento não estão isentos da aplicação de autenticação forte de clientes a pagadores que desejam consultar seu saldo ou consultar seu histórico de pagamentos nos últimos 90 dias, se uma das seguintes condições for atendida :

  • O usuário do serviço de pagamento acessa on-line o saldo da sua conta ou o histórico de pagamentos desde os primeiros 90 dias do parágrafo 1 pela primeira vez
     
  • A última vez que o usuário do serviço de pagamento acessou on-line seu histórico de pagamentos nos últimos 90 dias do parágrafo 1 e a autenticação forte do cliente foi aplicada há mais de 90 dias.

Os pagamentos podem ser incluídos na lista de permissões? Se validarmos o destino da lista de permissões e permitirmos pagamentos sem DL para esse destino, será suficiente?

O artigo 13 do rascunho final do RTS permite que o provedor de serviços de pagamento não execute autenticação forte do cliente se o pagador iniciar uma transação de pagamento em que o beneficiário esteja incluído em uma lista de beneficiários confiáveis criados anteriormente. Consulte o artigo 13 para obter detalhes.

O OneSpan Mobile App Shielding precisa ser reembalado com o aplicativo de banco móvel sempre que houver uma atualização de versão?

Existem duas partes desta pergunta:

  • Sempre que o PSP está prestes a lançar seu aplicativo móvel para o mercado de aplicativos, é necessário aplicar a proteção do aplicativo para que o aplicativo seja protegido. A boa notícia é que o empacotamento de blindagem do aplicativo leva vários segundos e, portanto, não afeta os ciclos de lançamento do PSP.
     
  • Como a solução OneSpan Mobile App Shielding é atualizada regularmente para se defender contra ameaças móveis em evolução, também é recomendável que os PSPs protejam seus aplicativos com a versão mais recente para garantir o mais alto nível possível de proteção.

A proteção de aplicativos cobre a proteção de clonagem?

O OneSpan Mobile Security Suite fornece um recurso de ligação de dispositivo que oferece proteção de clonagem para aplicativos móveis.

Você precisa de blindagem de aplicativo móvel ao usar uma solução SMS? Aplicativo SIM?

O dispositivo móvel onde o SMS chega também pode conter um aplicativo de autenticação (no cenário 1aa ou 2aa), no qual o SMS precisa ser inserido. Este aplicativo precisaria ser protegido usando a proteção de aplicativos móveis.

Existe alguma preocupação adicional de segurança com a implementação do APP2APP vs push?

Em nossa opinião, essas são duas abordagens igualmente seguras que, em última análise, dependem da mesma tecnologia subjacente do canal de comunicação seguro. Nós os vemos sendo ótimos com diferentes modelos de uso. Muitos dos bancos implementarão o aplicativo de autenticação que funcionaria na seguinte configuração: 

Quando a transação é iniciada dentro do aplicativo bancário móvel, o link de comunicação App2App será estabelecido para o aplicativo de autenticação instalado no mesmo dispositivo. Isso permite alternar entre dois aplicativos automaticamente, o que melhora a experiência do usuário. 

Quando a transação é iniciada no navegador da Web a partir de outro dispositivo (PC ou tablet), a notificação PUSH será enviada para o aplicativo de autenticação instalado no dispositivo móvel do usuário. Como alternativa, com quase a mesma experiência do usuário, o processo de digitalização e assinatura óptica pode ser usado. 

Você pode encontrar mais informações sobre as soluções Cronto aqui: Sinal de Cronto

Para App2App com canal de comunicação seguro, a troca de dados entre os aplicativos ocorre via back-end em um formato criptografado.

A plataforma universal do Windows (UWP) e os tablets Windows são uma plataforma de solução viável para SCA em uma configuração 2AA de 1AA? O sandbox é diferente entre iOS e Android?

As técnicas de sandboxing da Plataforma Universal do Windows (UWP) são semelhantes ao Android e iOS. A UWP adotou muitos dos conceitos do Android e iOS. O Windows 10 Mobile permite executar apenas aplicativos UWP, portanto, os mecanismos de sandbox têm força comparável à do Android e iOS aqui. O Windows 10 padrão permite a execução de aplicativos UWP e regulares do Windows, portanto, o sandbox é menos forte que o Android ou iOS.

Quando a transação foi iniciada no TPP APP, qual dos casos de uso apresentados parece mais provável de ser usado?

Quando o usuário está usando um aplicativo TPP, provavelmente vemos um dos três casos de uso a seguir: 

  • EMPURRE a notificação do banco para o aplicativo de autenticação fornecido pela instituição financeira. Isso não precisa de integração específica entre as partes.
     
  • Comunicação App2App entre um aplicativo TPP e um aplicativo de autenticação fornecido pela instituição financeira. Isso requer uma integração mínima do serviço de autenticação entre o TPP e a instituição financeira. 
     
  • Estrutura de segurança móvel incorporada no aplicativo TPP. Isso implica que o TPP não dependerá da implementação da autenticação da instituição financeira, mas fornecerá o seu próprio. 

Nas três opções, TPPs e instituições financeiras precisarão coletar entradas de dados dos dispositivos do usuário e realizar uma análise minuciosa em vários aplicativos, canais e terminais para uma avaliação completa dos riscos. A melhor opção é implementar um software de risco dedicado, como o OneSpan Risk Analytics, que fornece: 

  • Detecção em tempo real de fraudes sofisticadas 
     
  • Processamento de grandes quantidades de pontos de dados para detectar comportamento anormal do usuário, transações suspeitas e navegação atípica no aplicativo de pagamento 
     
  • Pontuação precisa de riscos e mitigação de ameaças em todos os dispositivos móveis comuns (por exemplo, telefones celulares e tablets) 
     
  • Operações invisíveis para os usuários finais, mitigando fraudes e proporcionando a melhor experiência possível
     

Se a autenticação de dois aplicativos for usada, os dois aplicativos móveis precisam usar o SO do sandbox e a proteção de aplicativos móveis?

O sandbox é aplicado pelo sistema operacional (por exemplo, Android ou iOS) do dispositivo móvel para todos os aplicativos em execução no dispositivo. A proteção de aplicativos móveis deve ser aplicada ao aplicativo de autenticação.

O digipass SDK está disponível / é compatível com o nativescript?

Sim, é esse o caso.

Você poderia elaborar a comunicação segura oferecida pelo OneSpan Mobile Security Suite? O que é usado para protegê-lo? O que é necessário no servidor?

A funcionalidade de comunicações seguras do OneSpan Mobile Security Suite oferece a capacidade de criar um canal de comunicação seguro entre o aplicativo e o servidor, protegendo a confidencialidade, a integridade e a autenticidade de todas as informações de pagamento. O OneSpan Mobile Security Suite vem com SDKs do lado do cliente e do servidor para estabelecer o canal seguro. Dessa maneira, os PSPs podem configurar facilmente um canal seguro sem precisar gerenciar a complexidade do canal seguro.

Se o identificador de hardware, a impressão digital e o pino precisarem ser combinados para um aplicativo, há uma recomendação para um algoritmo HMAC?

Recomendamos o uso de algoritmos HMAC padrão, como HMAC-SHA256 ou HMAC-SHA3.

Para ser compatível com a situação 2AA, os dois aplicativos precisam ser protegidos por blindagem de aplicativo móvel? Ou apenas o aplicativo de autenticação?

O aplicativo de autenticação precisa ser protegido com blindagem de aplicativo móvel. O aplicativo bancário pode estar protegido, mas não é obrigatório no rascunho final do RTS.

Como você vê o uso de parâmetros comportamentais como fatores de autenticação?

Sim, vemos isso como um possível elemento de herança. Os comentários da EBA ao projeto final de RTS também indicam que isso é possível.

O OneSpan possui uma solução para usar o fator 'herança' (biometria) como elemento de autenticação?

Sim, o OneSpan Mobile Security Suite oferece suporte à autenticação biométrica com base em impressões digitais, digitalização facial e comportamento do usuário.

Você pode discutir o TRA para pagamentos em massa?

No caso de pagamentos em massa, o código de autenticação para SCA deve ser calculado com base no valor total de dinheiro de todos os pagamentos combinados e com base nos números de conta de todos os beneficiários. Não há disposições específicas sobre o TRA para pagamentos em massa.

Uma solução de prevenção da OneSpan pode reunir todos os tipos de transações, incluindo: banco eletrônico, cartão, pos, banco móvel, carteiras etc.?

Sim, o OneSpan Risk Analytics pode ser usado para analisar transações para diferentes tipos de canais de pagamento.

A solução OneSpan é uma solução baseada na nuvem? E se sim, privado ou público?

O OneSpan Risk Analytics está disponível no local e na nuvem. A versão em nuvem é hospedada pelo OneSpan.

O OneSpan Risk Analytics é compatível com os requisitos de RTS?

Sim, o OneSpan Risk Analytics pode executar a análise de risco de transação de acordo com os requisitos no rascunho final do RTS.

Todos os PSPs exigem TRA, mesmo que planejem usar o SCA para todas as transações? Em caso afirmativo, qual é a lógica por trás desse requisito?

De fato, os PSPs sempre precisam usar o TRA, mesmo que usem o SCA. O TRA fornece uma segunda camada de segurança ao lado de SCA. O TRA é útil para proteger contra ataques de engenharia social, nos quais um adversário tenta convencer o usuário genuíno a confirmar um pagamento usando o SCA quando o pagamento é realmente fraudulento.

As diretrizes ou diretrizes definem certos mandatos para as soluções 2AA e 1AA, caso o meio físico seja perdido ou roubado?

O rascunho final do RTS indica que o procedimento de autenticação deve incluir, em geral, mecanismos de monitoramento de transações para detectar tentativas de uso de credenciais de segurança personalizadas de um usuário de serviço de pagamento que foram perdidas, roubadas ou inapropriadas. Isso se aplica a todas as soluções de autenticação, não apenas àquelas da categoria 2aa ou 1aa.

Fale Conosco

Você tem outras perguntas sobre o PSD2? Obtenha as informações necessárias rapidamente.