El pasado mes de Febrero, la Autoridad Bancaria Europea (EBA) publicó el borrador final del Estándar Técnico Regulatorio (RTS, Regulatory Technical Standard) sobre Autenticación Reforzada y Comunicaciones Seguras en el contexto del artículo 98 de la Directiva de Pagos PSD2 (2015/2366). En este post vamos a a hacer un repaso del requisito de Autenticación Reforzada, tal como queda a fecha de hoy de acuerdo a lo establecido en el mencionado estándar. Dado que el documento deberá ser sometido al escrutinio del Parlamento Europeo y del Consejo, no es previsible que fuera de aplicación antes de Noviembre de 2018.
Recordemos que la directiva revisada de servicios de pago (PSD2) establece el requisito de Autenticacion Reforzada (Strong Authentication) como uno de los pilares esenciales para garantizar la seguridad de los pagos minoristas por Internet. Esta directiva supuso un paso más en el camino hacia un mercado digital europeo único, favoreciendo el crecimiento de la economía, a los consumidores y empresas, a la vez que orientada a reducir los niveles de fraude en las transacciones online. Sin embargo, la directiva dejaba algunos puntos abiertos en cuanto al modo de abordar algunos de sus requisitos técnicos, estableciendo el mandato para la EBA (Autoridad Bancaria Europea) de aclararlos en una serie de estándares técnicos (RTS).
El requisito de Autenticación Reforzada
La PSD2 requiere que los procesadores de servicios de pagos por Internet, establezcan mecanismos de Autenticación Reforzada y medidas de seguridad para proteger las credenciales de seguridad de los usuarios cuando éstos:
- Acceden a su cuenta de pago online
- Inician una transacción de pago electrónico, o
- Llevan a cabo, a través de canales remotos, cualquier acción que pueda implicar un riesgo de pago fraudulento u otros abusos.
Además, en relación con las transacciones de pago online, la Autenticación Reforzada debe incluir elementos que asocien dinámicamente la transacción a la cantidad específica y al beneficiario de la misma; es decir, uno de los elementos de la autenticación debe ser calculado dinámicamente y en su cálculo deben usarse estos datos específicos de la transacción; de esta manera el código de autenticación así generado no podría ser usado en otra operación distinta.
¿En qué consiste?
La Autenticación Reforzada se basa en el uso combinado de dos o más elementos del tipo:
- Algo que solamente el usuario conoce (CONOCIMIENTO); por ejemplo, una contraseña.
- Algo que solamente el usuario posee (POSESIÓN); por ejemplo, un token, una tarjeta, un teléfono móvil
- Algo que el usuario es (INHERENCIA); por ejemplo, un rasgo biométrico como la huella digital, el iris..
Además, estos elementos deben ser:
- Independientes, esto es, el compromiso de uno de los elementos no implica el compromiso de los otros; por ejemplo, aunque un hacker pueda robar mediante un keylogger una contraseña (algo que el usuario sabe), esto no implica que el delincuente tenga acceso a otros elementos físicos como el token o el teléfono móvil.
- Diseñado para preservar la confidencialidad de los datos de autenticación.
- Al menos uno de los elementos debe ser NO replicable y NO reutilizable.
- No susceptible de ser robado a través de Internet.
Autenticación Reforzada en el Acceso online
Cuando un usuario se limite a acceder para consultar el saldo y/o los movimientos ejecutados en los últimos 90 días de una o más cuentas de pago, sin que ello suponga la divulgación de datos sensibles, entonces no será necesario el uso de Autenticación Reforzada, excepto cuando se realice el acceso por vez primera o transcurridos más de 90 días desde la última vez que se aplicó la Autenticación Reforzada en el acceso.
Este es a mi juicio uno de los puntos que más impacto tiene en la experiencia de usuario y obligará a la mayoría de los bancos a modificar sus procedimientos de acceso a sus servicios de Banca online.
Uso de dispositivos multipropósito
Una de las dudas que había suscitado el anterior borrador, era el impacto del requisito de independencia entre el canal, dispositivo o aplicación móvil usado para mostrar el código de validación del pago electrónico y el canal, dispositivo o aplicación móvil usado para iniciar el pago. El nuevo documento de la EBA aclara este punto y permite que ambas funcionalidades (la de presentación del código de validación e inicio del pago) coexistan en el mismo dispositivo (ej: móvil o tablet), siempre y cuando se cumplan las siguientes condiciones:
- El uso de espacios de ejecución seguro separados para las distintas aplicaciones instaladas en el dispositivo.
- Uso de mecanismos para asegurar que el dispositivo o el software no haya sido alterado ni por parte del usuario ni por un tercero, o el uso de mecanismos para mitigar las consecuencias de esta manipulación en caso de producirse.
Sobre el uso de contraseñas y pines
Lamentablemente el nuevo documento de la EBA no es muy específico a la hora de aclarar las características que tiene que tener un componente de la Autenticación Reforzada, para que pueda ser considerado como válido dentro de la categoría de algo que solamente el usuario conoce (ej: una contraseña). En este sentido, se limita a especificar que debe tener características de seguridad adecuadas como longitud (se entiende que mínima) o complejidad. Esta ambigüedad contrasta con la mayor concreción del anterior borrador, donde se mencionaban más características como el cambio periódico de la contraseña. Dependiendo del enfoque final, esta claro que estas características de la contraseña pueden tener un impacto (a veces negativo) sobre la experiencia de usuario.
Beneficiarios de confianza
Cuando el beneficiario del pago electrónico este incluido en una lista blanca creada o confirmada por el propio usuario del servicio, entonces este tipo de pagos puede estar exento de la aplicación del requisito de Autenticación Reforzada. Esta exención también es aplicable cuando el usuario inicia una serie de pagos hacia el mismo beneficiario y por el mismo importe. No obstante, estas exenciones no serán aplicables:
- Cuando la lista blanca de beneficiarios se cree, confirme o modifique.
- Cuando el usuario inicia por primera vez una serie de pagos o cuando modifique la serie de pagos
Además, se establece la exención en la aplicación de la Autenticación Reforzada, en el caso de que el ordenante y el beneficiario de la transferencia sean la misma persona (física o jurídica) y las cuentas origen y destino sean de la misma entidad.
Contactless y bajos importes
En el documento se definen otras exenciones en la aplicación de la Autenticación Reforzada sobre pagos presenciales y de importes bajos:
- Exclusión de pagos con contactless, siempre que el importe no exceda de 50 €, la cantidad acumulada de pagos sin Autenticación Reforzada no supere los 150 € y/o no se hayan llevado a cabo más de 5 pagos consecutivos sin este tipo de autenticación.
- Pagos en terminales desatendidos relacionados con parkings y peajes en autopistas.
Monitorización de transacciones
Los procesadores de servicios de pagos electrónicos, deben establecer mecanismos de seguridad alrededor de los procesos de autenticación, orientados a la detección de fraude mediante suplantación de identidad y el uso fraudulento de credenciales de usuario. Entre estos mecanismos, se cita la monitorización en tiempo real de las transacciones. Dichos mecanismos deberán tener en cuenta al menos los siguientes factores de riesgo:
- Lista de elementos de autenticación robados o comprometidos
- Importes de la transacción
- Escenarios de fraude conocidos
- Signos de infección por código malicioso en la sesión de autenticación.
- Los patrones de pagos previos y el historial del usuario del servicio
- Anomalías detectadas en estos patrones de uso
- La ubicación geográfica del ordenante y beneficiario
- …
En base al análisis en tiempo real de estos factores, los mecanismos de monitorización de transacciones. permitirán a las organizaciones no sólo detectar y prevenir proactivamente los intentos de fraude online, sino también identificar transacciones de bajo riesgo, sobre las que podrán decidir la aplicación o no de la Autenticación Reforzada.
Transacciones de bajo nivel de riesgo
En el caso de que una determinada transacción sea considerada de bajo riesgo, dicha transacción podrá ser validada sin el requisito de Autenticación Reforzada. En este sentido, sin embargo, el borrador de la EBA es muy específico sobre las condiciones que han de darse para que esta exención se pueda aplicar. Veamos cuales son estos criterios.
La EBA establece unos umbrales de exención por importe (ETV, Exemption Threshold Value) que se establecen en función del tipo de operativa (pagos en remoto con tarjeta y transferencias) y las tasas de fraude medidas trimestralmente por la organización para ése tipo de operativa. En ningún caso, sin embargo, ése umbral de exención puede superar los 500 €, tal como se define en la siguiente tabla incluida en el documento de la EBA:
Es decir, de acuerdo con esta tabla:
- No se podrá considerar como de bajo riesgo ninguna transacción que supere los 500 €.
- No se podrá considerar como de bajo riesgo ninguna transacción que exceda el ETV que corresponda en la tabla, de acuerdo a las tasas de fraude actuales calculadas por la entidad para el tipo de operativa.
- El umbral de exención se va reduciendo, hasta llegar a los 100 €, a medida que la tasa de fraude calculada por la entidad va empeorando.
- Cuando las tasas de fraude calculadas para un determinado tipo de operativa en dos periodos consecutivos (180 días) superen las tasas especificadas en la tabla para el ETV de 100 €, entonces la entidad no podrá aplicar la exención de la Autenticación Reforzada.
Además del ETV, deben cumplirse las siguientes condiciones que definen el criterio de «bajo riesgo» que deberá implementar el sistema monitorización de transacciones. Se considera bajo riesgo, cuando concurren las siguientes condiciones:
- No se identifica un patrón de comportamiento o gasto anómalo en relación con la pauta habitual del cliente.
- No se identifica ningún indicio sospechoso en el dispositivo o software empleado por el usuario para el acceso.
- No se detecta en la sesión ningún indicio de infección por malware en el dispositivo del usuario.
- No se identifica ningún patrón de fraude conocido.
- La ubicación del usuario que inicia el pago no es anómala.
- La ubicación del beneficiario no está identificada como de alto riesgo.
Cese de la posibilidad de aplicar la exención por bajo riesgo:
Tal como se define el el documento de la EBA, una vez que un proveedor de servicios de pago ha notificado a las autoridades competentes su intención de usar la exención a partir del análisis de riesgo de las transacciones, entonces deberán calcular trimestralmente sus tasas de fraude para los tipos de operativa relacionados en la tabla. Esta tasa se calcula computando en cada trimestre y para cada tipo de operativa, el importe total de todas las operaciones de ese tipo que han resultado ser fraudulentas (tanto si ha sido fraude exitoso como si se ha recuperado el importe) frente al importe total de todas las operaciones de ése tipo en el periodo de cómputo, con independencia de que haya usado en ellas Autenticación Reforzada o se haya aplicado la exención de la misma por bajo riesgo. El método de cálculo empleado para obtener estas tasas deberá ser auditado además de manera periódica para verificar que es completo y adecuado. Además, dicho método debe estar documentado y estar accesible para las autoridades.
Cuando las tasas de fraude calculadas para un determinado tipo de operativa en dos periodos consecutivos (180 días) superen las tasas especificadas en la tabla para el ETV de 100 €, entonces el procesador de servicios de pago no podrá aplicar la exención de la Autenticación Reforzada y deberá notificar esta circunstancia a las autoridades competentes, indicando los planes mitigatorios que pretende aplicar para corregir la situación. Una vez corregida (las tasas de fraude calculadas vuelven a estar dentro de los umbrales especificados), entonces podrá volverse a aplicar la exención, previa notificación a las autoridades.
Epílogo
Como puede verse, los requisitos establecidos por la EBA son bastante prescriptivos y un tanto burocráticos en algunos aspectos. Sin duda, implican cambios relevantes en los procedimientos habituales usados por los bancos para autenticar a los usuarios y validar las transacciones. Sin embargo, si el estándar se aprueba tal como está redactado el borrador final, los usuarios se beneficiarán de un modelo de seguridad bastante robusto y altamente consistente entre las distintas entidades. No obstante, como siempre con estos temas, hay opiniones para todos los gustos.
Seguiremos siguiendo este tema. Un fuerte abrazo y gracias.