La EBA publica una opinión sobre la implementación de los RTS sobre la autenticación reforzada y los estándares de comunicación abiertos comunes y seguros

La Autoridad Bancaria Europea (por sus siglas en inglés, EBA) publicó el 13-6-2018 su opinión sobre la implementación de los RTS (regulatory technical standards), la autenticación reforzada (por sus siglas en inglés, SCA) y los estándares de comunicación abiertos comunes y seguros (por sus siglas en inglés, CSC).

Comentarios generales

Para que los proveedores de servicios de pago (PSP) cumplan con estos estándares, con la autenticación reforzada y la comunicación estandarizada antes del 14-9-2019, dentro de las fechas límite impuestas por los RTS, muchas de las entidades del sector deberán desarrollar o modificar sus sistemas informáticos, incluyendo la construcción de interfaces y otras infraestructuras en el caso de proveedores de servicios de pago gestores de cuentas (ASPSP).

En este contexto, la EBA aclara los siguientes puntos:

1. Los proveedores de servicios de información sobre cuentas (AISP) o de iniciación de pagos (PISP) a un usuario del servicio de pago (PSU), después de un contrato firmado por ambas partes, los ASPSP no tienen que verificar el consentimiento.

2. Es suficiente que los AISP y PISP puedan confiar en los procedimientos de autenticación proporcionados por los ASPSP al usuario de servicios de pago, cuando se trata de la expresión del consentimiento explícito.

Alcance de los datos y el límite de las cuatro veces diarias

Muchos de los AISP, PISP y ASPSP están acostumbrados a acceder a una amplia gama de datos a través del uso de lo que comúnmente se conoce como screen scraping. Para los PISP esto es particularmente importante, si el ASPSP que ejecuta el pago no tiene ningún sistema de reserva en tiempo real; es decir, un sistema de reserva que refleje inmediatamente cualquier movimiento en la cuenta, ya que solicitan confirmación del ASPSP de que el pago que inician se ha ejecutado.

Con respecto a los AISP , tienden a acceder a diferentes tipos de datos. Según el artículo 67 (2) (d) de PSD II, estos proveedores «acceden únicamente a la información de cuentas de pago designadas y transacciones de pago asociadas». El RTS aplicable, en el artículo 36 (1) (a), especifica que tienen acceso a los mismos datos a los que los clientes podrían acceder sobre sus cuentas de pago designadas y sobre las transacciones de pago asociadas usando su interfaz web, móvil o tableta, siempre que esta información no incluya datos sensibles del pago. PSD II no trata sobre el acceso a otros tipos de información que las citadas.

Los datos que los titulares de cuentas de pago pueden ver, en la actualidad y también una vez que los RTS sean de aplicación, conforman un conjunto básico de datos, pero puede haber variaciones sobre ellos. Esto significa que los datos a los que los AISP pueden acceder varían dependiendo del ASPSP donde se encuentra la cuenta de pago.

La EBA aclara que los AISP pueden acceder a todos los datos disponibles de las cuentas de pago mantenidas con un ASPSP específico, con independencia del canal electrónico utilizado para acceder a él. Esto es, si hay más datos disponibles a través de una conexión de computadoras en línea que a través de una aplicación móvil, el proveedor puede acceder a los datos disponibles a través del interfaz entre computadoras, al margen del canal que esté utilizando el usuario.

Con respecto a los PISP, el artículo 66 (3) (f) y (g) de la PSD II establece que este tipo de proveedor «no solicitará al usuario del servicio de pago ningún dato que no sea el necesario para proporcionar el servicio de inicio de pago” y “no utilizar, acceder o almacenar datos para fines distintos a la provisión del servicio de iniciación de pago según lo solicite explícitamente el ordenante», mientras que el artículo 66 (4) (b) establece que el ASPSP deberá «proporcionar o poner a disposición toda la información sobre el inicio de la transacción de pago y toda la información accesible para el proveedor de servicios de pago de servicio de cuentas con respecto a la ejecución de la transacción de pago al proveedor del servicio de inicio de pago».

Además, el artículo 36 (1) (b) del RTS determina que los ASPSP proporcionarán a los iniciadores de pagos «la misma información sobre la iniciación y ejecución de la operación de pago proporcionada o puesta a disposición del usuario del servicio de pago».

La combinación de los apartados (1) (b) y (c) del artículo 36 establece requisitos jurídicamente vinculantes que tienen por objeto garantizar que el proveedor que inicia un pago tenga la misma información que necesita para iniciar un pago el propio usuario. La respuesta “sí / no” ayudará al PISP a gestionar el riesgo al que se enfrentará si, tras el inicio del pago, resulta que este no puede ejecutarse. Quizás no sea posible evaluar este riesgo solo con la información recibida en virtud del artículo 36 (1) (b) del RTS. Por ello, en términos prácticos, los iniciadores pueden tener un interés particular en buscar garantías sobre la probabilidad de que el pago se ejecute, dado que la ausencia de un sistema de reserva en tiempo real podría generar más incertidumbre sobre el estado de la transacción iniciada.

La EBA considera que el ASPSP, al determinar si da una respuesta afirmativa o negativa a la solicitud de confirmación requerida en virtud del artículo 36 (1) (c), en relación a si hay o no fondos disponibles, tenga en cuenta no solo el saldo sino también cualquier sobregiro u otro dato que utilice el ASPSP para determinar si se ejecuta o no un pago de uno de sus propios clientes.

En el caso de que el ASPSP no tenga un sistema que le permita responder de manera adecuada a la solicitud de confirmación enviada por el proveedor que inició el pago,  debería dar a los PISP la posibilidad de acceder a los datos necesarios para permitirles decidir sobre la disponibilidad suficiente de fondos.

La EBA aclara que el alcance de los datos del ASPSP compartidos con PISP y AISP, bajo la PSD II y los RTS, no incluye la identidad del usuario del servicio de pago (por ejemplo, dirección, fecha de nacimiento, número de la seguridad social), dado que estos datos no son necesarios ni requeridos para iniciar un pago ni para acceder a la información de la cuenta.

La EBA también señala que el artículo 36 (5) (b) de los RTS limita el acceso del iniciador a los datos de la cuenta de pago cuando el usuario no solicite activamente esa información, no más de cuatro veces en un período de 24 horas. El usuario no estará directamente activo si no está en una sesión en el momento de la solicitud; es decir, no está viendo los datos ni está ejecutando una acción para actualizar los datos que se mostrarán. Un ASPSP puede acordar contractualmente con el iniciador que pueda acceder a la cuenta sin la participación del cliente en «una frecuencia más alta», o que el ASPSP le envíe información «con el consentimiento del usuario del servicio de pago».

Según la EBA, un PISP tiene el derecho a efectuar las mismas transacciones que el ASPSP ofrece a sus propios usuarios, como pagos instantáneos, pagos por lotes, pagos internacionales, transacciones recurrentes, pagos establecidos por esquemas nacionales y pagos con fecha futura.

SCA y los factores de autenticación

La SCA, tal y como se define en la PSD II, se aplica a todas las transacciones de pago iniciadas por el ordenante, incluidas las transacciones de pago con tarjeta iniciadas a través del beneficiario dentro del EEE.

Esta autenticación reforzada se basa en el uso de dos o más elementos categorizados  como conocimiento (algo que solo el usuario conoce), posesión (algo que solo el usuario posee) e inherencia (algo que el usuario es) que son independientes.

Los PSP deben diseñar un método de autenticación que utilice dos elementos de dos categorías diferentes, por ejemplo, un elemento conocido (como una contraseña) y uno inherente (como las huellas dactilares). Los elementos inherentes al usuario se basan típicamente en datos biométricos (incluida la biometría de comportamiento), siempre que cumplan los requisitos del artículo 8 de los RTS.

Dado que el conocimiento se define como «algo que solo el usuario sabe», el número de tarjeta con CVV y su fecha de caducidad no pueden considerarse un elemento de conocimiento.

Para que un dispositivo se considere posesión, se requiere generar o recibir un elemento de validación dinámico en el dispositivo que confirme esa posesión.

Se debe aplicar la SCA para acceder a la información de la cuenta de pago y para cada iniciación de pago, incluso en una sesión en la que se ejecutara para acceder a los datos de la cuenta, a menos que se exima en virtud del RTS.

¿Quién puede aplicar SCA y quién puede decidir sus exenciones?

Según la PSD II, los ASPSP permitirán a los PISP y AISP confiar en los procedimientos de autenticación provistos a sus usuarios, y establece que las credenciales de seguridad son accesibles para estos proveedores. Asimismo, el considerando 30 de la PSD II establece: «Las credenciales de seguridad personalizadas empleadas para que el cliente sea autenticado bien directamente por el usuario del servicio de pago, o bien por el proveedor de servicios de iniciación del pago son, normalmente, las emitidas por los proveedores de servicios de pago gestores de cuenta».

El PSP que aplica la SCA es el que emite las credenciales de seguridad personalizadas. En consecuencia, también es el mismo proveedor el que decide si aplica o no una exención. Sin embargo, el ASPSP puede optar por contratar a otros proveedores para que realicen la SCA en su nombre y determinen la responsabilidad entre ellos. La EBA también señala que ya existen en algunos Estados miembros varios acuerdos gubernamentales sobre conjuntos universales de credenciales de seguridad personalizadas que pueden ser utilizados por los usuarios con múltiples PSP.

La EBA señala que los PISP y AISP a veces desean emitir sus propias credenciales para acceder a sus plataformas (por ejemplo, aplicación o sitio web en línea) y, por lo tanto, también pueden decidir si realizan la SCA en el acceso a estas plataformas o aplican una exención. Sin embargo, solo el ASPSP puede aplicar la SCA o decidir si una exención se aplica o no a la cuenta de pago del usuario cuando actúan estos proveedores. Por ejemplo, solo el ASPSP puede decidir si aplica o no la exención del análisis de riesgo de la transacción en virtud del artículo 18 del RTS. El iniciador puede tener acceso a la lista creada o modificada por el usuario en el dominio de ASPSP, pero la decisión de aplicar o no la exención le corresponde a este.

Exenciones de la SCA

Los beneficiarios nunca pueden decidir si usan o no una exención.

*El PSP del ordenante siempre toma la decisión final sobre si acepta o aplica una exención. Puede volver a aplicar la SCA para ejecutar la transacción, si es técnicamente factible, o rechazar su inicio.

La EBA aclara que el límite de cinco transacciones debe calcularse sobre la base de todas las transacciones en las que la exención particular se aplicara, no sobre la base de todas las transacciones en las que podría haberse aplicado.

En relación con los dos límites acumulativos establecidos en los artículos 11 y 16 de los RTS y, en particular, si el límite se basa en el número de transacciones (cinco) y el límite basado en el importe monetario, se aclara que el límite acumulado es el límite en función del número de transacciones o del monto monetario (pero no ambos). Esto significa que puede ser preferible que los PSP decidan desde el principio qué límite acumulativo utilizan (en lugar de transacción por transacción), ya que de lo contrario podría ser confuso para los consumidores.

El artículo 10 de los RTS proporciona una exención cuando el usuario o el AISP accede a información limitada de la cuenta de pago (por ejemplo, el saldo o datos sobre las transacciones de los últimos 90 días) durante un período de 90 días después del primer acceso habiendo aplicado la SCA. Este período es específico para cada iniciador y también es diferente del período de 90 días para que el usuario acceda directamente a la información de su cuenta. Cuando ha transcurrido el período de 90 días, la exención ya no se aplica y la SCA debe volver a realizarse para iniciar un nuevo período. El ASPSP puede restablecer el contador de 90 días siempre que se aplique la SCA, al margen del canal que el usuario utilice para acceder a su cuenta. Realizar un pago directamente o mediante iniciación de pago y realizar la SCA no reiniciará este periodo a los efectos del artículo 10.

Sobre la exención para los beneficiarios de confianza, la EBA aclara que no se limita a las transferencias  y puede aplicarse también a las tarjetas a través del PSP del ordenante, previa confirmación de este. La EBA explica que el PSP del beneficiario no puede aplicar esta exención.

En relación con la exención de transacciones de bajo riesgo, se podrá aplicar siempre que se haya realizado el análisis de riesgo de la transacción y el índice de fraude sea inferior al umbral definido. La EBA señala que la tasa de fraude incluye no solo transacciones no autorizadas, sino también transacciones fraudulentas resultantes de la manipulación del ordenante, tal y como se definirá en el documento de consulta que este regulador emitirá en el verano de 2018.

La tasa de fraude según se define en el anexo A de los RTS se calcula para todas las transacciones, ya sean transferencias o pagos con tarjeta, y no se puede definir por beneficiario individual o por canal. El PSP del beneficiario puede acordar contractualmente externalizar su control del riesgo de transacción a un comerciante, o permitir que solo ciertos comercios predefinidos se beneficien de la exención de ese PSP.

Métodos para realizar la SCA

Hoy se utilizan tres métodos para realizar la SCA del usuario:

1. a través de una interfaz especifica o redirección;
2. con enfoques integrados; y
3. con enfoques desacoplados (o una combinación de ellos).

En los casos de redirección y enfoques desacoplados, los datos de autenticación del usuario se intercambian directamente entre estos y el ASPSP, a diferencia de los enfoques integrados, en los que esos datos se intercambian entre PSP y ASPSP a través de la interfaz.

El artículo 32 (3) de los RTS ha generado cierto debate. La EBA aclara que los RTS no establecen que la redirección en sí sea un obstáculo para los PISP y AISP que prestan servicios a sus usuarios. No obstante, los RTS declaran que podría ser así considerado, si el ASPSP lo implementa de una manera restrictiva u obstructiva para ellos.

Los ASPSP que hayan establecido una interfaz específica se asegurarán de que esta no cree obstáculos a la prestación de servicios de iniciación de pagos y de información sobre cuentas. Se entiende por obstáculos, entre otros, impedir el uso por los PSP de las credenciales expedidas por los ASPSP, imponer la redirección hacia la autenticación u otras funciones del ASPSP, exigir autorizaciones y registros adicionales, además de los previstos, etc.

Para determinar qué métodos se usan en los procedimientos de la SCA, todos los métodos proporcionados al usuario deben ser compatibles con la intervención de un PISP o AISP. Si no lo fueran, esto constituiría un obstáculo.

Finalmente, la EBA recomienda a las autoridades competentes alentar a sus participantes en el mercado a que usen la vía de preguntas y respuestas de la EBA, tan pronto como esté disponible, para enviar cualquier consulta que tengan sobre los RTS relativos al SCA y CSC.