PSD2: opinión de la Autoridad Bancaria Europea (ABE) permite más tiempo para implementar la autenticación fuerte de cliente

El 21 de junio de 2019, la Autoridad Bancaria Europea(ABE) publicó un dictamen sobre la autenticación fuerte de clientes (SCA) en el marco de la Directiva de Servicios de Pago revisada(PSD2). El Dictamen de la ABE permite a las Autoridades Competentes (AC) conceder excepcionalmente un plazo adicional más allá del 14 de septiembre de 2019 a determinados Proveedores de Servicios de Pago (PSP) para cumplir con los requisitos de la SCA. También aclara la conformidad de los métodos de autenticación más comunes con los requisitos de la DSP2 en materia de SCA.

En este artículo, analizo las aclaraciones del dictamen de la ABE y también planteo algunas áreas en las que se requieren aclaraciones adicionales.

Alcance de la ampliación

El Dictamen permite a las Autoridades Competentes (AC) conceder excepcionalmente un tiempo adicional más allá del 14 de septiembre de 2019 a determinados Proveedores de Servicios de Pago (PSP) para cumplir con los requisitos de la SCA. Más concretamente, el dictamen afirma que "las autoridades competentes pueden decidir trabajar con los proveedores de servicios de pago y las partes interesadas, incluidos los consumidores y los comerciantes, para proporcionar un tiempo adicional limitado que permita a los emisores migrar a enfoques de autenticación que cumplan con la SCA, como los descritos en este dictamen, y a los adquirentes migrar a sus comerciantes a soluciones que admitan la SCA"

Por ello, el dictamen se refiere en gran medida a los emisores, adquirentes y comerciantes cuando se habla de la posibilidad de obtener más tiempo para cumplir. Esta terminología se utiliza normalmente en el contexto del pago con tarjeta para el comercio electrónico. Probablemente sea así porque la mayoría de las solicitudes para retrasar el plazo de septiembre proceden de empresas de comercio electrónico.

Esto plantea la cuestión de si las autoridades competentes sólo concederán tiempo adicional en el contexto de los pagos con tarjeta para el comercio electrónico, y quizás no en el contexto de otras aplicaciones que requieren una autenticación fuerte, como la banca en línea y la banca móvil. Hemos pedido a la ABE que lo aclare.

DOCUMENTO TÉCNICO

Habilitando el monitoreo de fraude conforme con el PSD2 con la analísis de riesgos de OneSpan

Los nuevos requisitos de la PSD2 exigen que las organizaciones de servicios financieros realicen un seguimiento de las transacciones. Conozca los requisitos específicos y cómo OneSpan Risk Analytics puede ayudarle a cumplir con la normativa en este libro blanco.

Descargar ahora

Calendario de la prórroga

Como se ha mencionado anteriormente, el Dictamen permite a las autoridades competentes conceder "un tiempo adicional limitado" a los PSP para que cumplan los requisitos de la ley SCA. Sin embargo, el dictamen no impone un plazo. En consecuencia, los diferentes PSP podrían tener diferentes plazos para cumplir con los requisitos de la SCA, y esto podría afectar a los pagos en los que participan varios PSP. Por ejemplo, si se realiza un pago con tarjeta entre un emisor de tarjetas que cumple a partir del 14 de septiembre de 2019 y un adquirente que ha recibido una prórroga de, por ejemplo, seis meses, el adquirente podría enviar una solicitud de pago sin SCA al emisor. Pero, el emisor rechazará el pago, porque requiere SCA. Como consecuencia, los pagos podrían ser rechazados aunque tanto el emisor como el adquirente actúen correctamente. Esto plantea claramente la necesidad de que las CA concedan prórrogas de forma coordinada.

Alineación de los calendarios de SCA y Open Banking

Hasta ahora, la introducción de las API de banca abierta y de la SCA iban de la mano y seguían el mismo calendario, siendo la fecha límite el 14 de septiembre de 2019 para ambas. El dictamen de la ABE concede un tiempo adicional para aplicar los requisitos de la SCA, pero no concede un tiempo adicional para aplicar las API de banca abierta, el otro pilar de la DSP2. En consecuencia, los bancos podrían ofrecer las API de banca abierta a los proveedores terceros (TPP) sin necesidad de SCA.

Esto tiene una serie de consecuencias:

• Impacto en la seguridad: Si un banco no protege las cuentas bancarias con SCA, y si admite la autenticación a través del modelo integrado, los TPP obtendrán credenciales débiles utilizadas para proteger las cuentas bancarias. Por ejemplo, si una cuenta bancaria está protegida con un nombre de usuario y una contraseña estática, el TPP podría obtener estas credenciales. Como consecuencia, el TPP podría entrar en estas cuentas bancarias y quizás realizar pagos sin que los titulares de las cuentas lo supieran.

• Impacto en la experiencia del usuario: los usuarios que acceden a sus cuentas bancarias a través de un TPP (o más concretamente un proveedor de servicios de información de cuentas o AISP) podrían tener que realizar la SCA para el Banco-A pero no para el Banco-B. En consecuencia, la experiencia del usuario dentro de la aplicación del AISP será diferente para los distintos bancos, lo que podría resultar confuso. Esto también se aplica a los TPP que actúan como proveedores de servicios de iniciación de pagos (PISP).

WEBCAST

Seminario web: Extensión de la fecha límite de autenticación fuerte del cliente PSD2 - Aclaraciones sobre la opinión de la EBA

Aprenda del experto en PSD2 SCA Frederik Mennes sobre el alcance y los plazos de la extensión SCA y qué soluciones de autenticación cumplen.

Ver ahora

Cumplimiento de los elementos de autenticación

Las Normas Técnicas Reglamentarias (NTR) sobre Autenticación Fuerte de Clientes y Comunicación Común y Segura de la PSD2 definen la SCA como una "autenticación basada en el uso de dos o más elementos categorizados como conocimiento (algo que sólo el usuario sabe), posesión (algo que sólo el usuario posee) e inherencia (algo que el usuario es) que son independientes [...]". El dictamen contiene aclaraciones sobre qué elementos de autenticación pueden considerarse fuertes y en qué categoría se encuentran (es decir, conocimiento, posesión o inherencia).

A continuación se exponen algunas aclaraciones destacables del dictamen:

• El SMScomo elemento de posesión: El dictamen aclara que el SMS puede considerarse un elemento de posesión válido. Más concretamente, la tarjeta SIM del dispositivo móvil que recibe el SMS es un elemento de posesión válido. Esto implica que las contraseñas de un solo uso (OTP) entregadas a través de SMS pueden utilizarse para construir un mecanismo de autenticación fuerte cuando se combinan con un segundo factor (por ejemplo, una contraseña o un PIN). Sin embargo, el dictamen no aclara si el SMS puede utilizarse para la vinculación dinámica. De hecho, el requisito de enlace dinámico del artículo 5 de las RTS estipula que la confidencialidad e integridad de la información de pago (por ejemplo, el número de cuenta bancaria o la cantidad de dinero) debe protegerse durante el proceso de autenticación. Dado que el contenido de un SMS no suele estar protegido, parece que los SMS no cumplen los requisitos de enlace dinámico. La ABE debería dar más aclaraciones al respecto.

• Aplicaciones móviles como elemento de posesión: El dictamen refuerza el artículo 7 del RTS, que implica que las aplicaciones móviles son elementos de posesión válidos, si están protegidas con un mecanismo de vinculación del dispositivo que vincula la aplicación móvil con el dispositivo en el que se ejecuta. Una aplicación móvil que no esté protegida con un mecanismo de vinculación del dispositivo no puede considerarse un elemento de posesión válido.

• ListasOTP como elemento de posesión: Las instituciones financieras utilizan a veces tarjetas matriciales impresas o listas OTP impresas (a veces denominadas "listas TAN") para autenticar al usuario final de una aplicación bancaria en línea. El dictamen aclara que estas tarjetas o listas impresas no constituyen un elemento de posesión válido, porque pueden copiarse fácilmente (por ejemplo, haciendo una foto de la tarjeta con un dispositivo móvil).

Hay una serie de temas que no se abordan en el dictamen y que convendría aclarar. He enviado preguntas sobre estos temas a través de la herramienta de preguntas y respuestas de la ABE:

• Utilización de IBAN parciales o completos en la vinculación dinámica: El requisito de vinculación dinámica establece que el código de autentificación debe calcularse sobre un identificador del beneficiario. Supongamos que se utiliza un IBAN para identificar a un beneficiario. ¿Es necesario entonces calcular el código de autentificación sobre el IBAN completo, o basta con utilizar una parte del mismo? Del mismo modo, ¿es suficiente mostrar sólo una parte del IBAN al pagador? En la práctica, los bancos suelen utilizar sólo una parte del IBAN por múltiples razones, ya que resulta incómodo teclear o mostrar el IBAN completo.

• Uso del hash de la información de pago: Siempre en el contexto de la vinculación dinámica, a menudo se plantea la cuestión de si es necesario calcular el código de autenticación sobre la propia información de pago (importe, ID del beneficiario), o si basta con calcular el código de autenticación sobre un hash de la información de pago. Si el código de autenticación se calcula sobre un valor hash y el pagador no ve qué información de pago se utiliza, los pagadores podrían no entender a qué transacción se están comprometiendo realmente. Los ataques de ingeniería social contra los sistemas de autenticación suelen aprovecharse de ello.

Esperamos que la ABE proporcione aclaraciones adicionales sobre estos temas.

En mi blog hay un análisis más profundo de los requisitos de la PSD2 en materia de SCA.

Este artículo, publicado originalmente el 2 de julio de 2019, apareció por primera vez en la página personal de LinkedIn y en el blog de Wordpress de Frederik Mennes.