Los desafíos bancarios se suman: PSD2 significa nuevas reglas para compartir datos

Publicado: 2018-04-13

Muchos de ustedes, sin duda, han oído hablar de la directiva de la Autoridad Bancaria Europea (o EBA) de la Unión Europea llamada PSD2 (abreviatura de Directiva de servicios de pago). Estas pautas se publicaron originalmente a fines de 2015. Para enero de 2018, todos los estados miembros debían implementar las regulaciones.

La industria bancaria se enfrenta a muchos desafíos si no es que ya está pensando en un futuro muy digital.

Comprensión de la autenticación sólida de clientes para PSD2 de la UE

Los propósitos clave de PSD2 incluyen:

  1. Abrir nuevas oportunidades de mercado para una variedad de jugadores, como comerciantes en línea, al mismo tiempo que nivela el campo de juego para todas las partes interesadas clave.
  2. Proporcionar transparencia al consumidor y elección del consumidor
  3. Introducción de prácticas de seguridad nuevas y más sólidas para pagos en línea

Hay una serie de pautas en general para PSD2; sin embargo, una de las mejores Directrices de PSD2 se puede descargar desde MEF (Foro de Ecosistemas Móviles).

Autenticación sólida del cliente

Uno de los elementos clave de las regulaciones de PSD2 es el concepto de autenticación fuerte de clientes (o SCA). La EBA señala: “Gracias a PSD2, los consumidores estarán mejor protegidos cuando realicen pagos o transacciones electrónicas (como usar su banca en línea o comprar en línea).

El Estándar Técnico Regulatorio (RTS) hace que la autenticación sólida del cliente (SCA) sea la base para acceder a la cuenta de pago de uno, así como para realizar pagos en línea”. En resumen, SCA requiere, como mínimo, autenticación de dos factores (2FA).

La autenticación de dos factores significa que los usuarios tendrán que "probar" su identidad mediante dos elementos separados de tres:

  1. Algo que saben (un código PIN o contraseña)
  2. Algo que poseen (un dispositivo móvil, una tarjeta)
  3. Algo que son (huellas dactilares, escaneo facial: por ejemplo, biometría)

La EBA señala que SCA se usa comúnmente en toda la UE; sin embargo, este no es siempre el caso de las transacciones de pago en línea, como el pago con tarjeta de crédito o la transferencia bancaria directa. SCA se aplica en los países de la UE de Bélgica, los Países Bajos y Suecia); sin embargo, en otros países de la UE, la SCA solo se aplica de forma voluntaria, según un excelente comunicado de prensa de la Comisión Europea.

Si bien los estados miembros de la UE debían haber implementado la PSD2 en enero de 2018, la SCA será obligatoria 18 meses después de la Norma técnica reglamentaria (RTS) de la EBA después de la fecha de entrada en vigor de la RTS (que se prevé que sea a finales de este año). . Entonces, en esencia, estamos mirando hacia mediados o finales de 2019 (septiembre de 2019 fue una de esas fechas citadas en algunos documentos). Esto permitirá que todas las partes interesadas tengan tiempo suficiente para incorporar SCA y otros requisitos de seguridad en sus sistemas y flujos de trabajo.

Banca minorista: Leones, banqueros y fintechs, ¡oh Dios mío!

banca_minorista_fintech.jpg Las fintech amenazan el statu quo. A diferencia de los bancos, no están sujetos a legados, regulaciones y, en la mayoría de los casos, ni siquiera a la necesidad de ganar dinero. Los banqueros minoristas deben adaptarse y centrarse en las relaciones con los clientes para competir.

2FA para SCA

Dada la línea de tiempo de SCA, 2018 es un momento perfecto para que las empresas comiencen a implementar soluciones 2FA para dar cuenta de la mayor seguridad requerida.

El bufete de abogados internacional Taylor Wessing, en su artículo: Strong customer authentication under PSD2 , señala que “La EBA estuvo de acuerdo con la mayoría de los encuestados en el Documento de consulta en que, para garantizar la neutralidad tecnológica y permitir el desarrollo de soluciones fáciles de usar , medios de pago accesibles e innovadores, no debe definir más los elementos de autenticación”. Esto significa que la EBA no especifica la forma en que se puede implementar 2FA. Hay una variedad de esquemas que incluyen la entrega de tokens a través de canales móviles como SMS o notificaciones automáticas o canales de correo electrónico más tradicionales, así como soluciones de token de software TOTP y otros.

Tomando nota de todo esto, debemos señalar que, como cualquier buen esquema de implementación de 2FA, existen algunas limitaciones y regulaciones específicas que deben considerarse cuidadosamente.

Códigos de autenticación

El RTS señala que la generación de un código de autenticación cumple las siguientes condiciones:

  1. No se puede derivar información sobre el conocimiento, la posesión y la herencia de la divulgación del código de autenticación.
  2. No es posible generar un nuevo código de autenticación basado en el conocimiento de cualquier otro código de autenticación generado previamente
  3. El código de autenticación no se puede falsificar

Además, el RTS establece que no se deben intentar más de 5 intentos de autenticación fallidos dentro del tiempo de vida del código y que el tiempo máximo sin actividad por parte del pagador o usuario después de ser autenticado para acceder a su cuenta de pago en línea no debe exceder los 5 minutos. .

Vinculación dinámica de la transacción

El RTS indica que las transacciones electrónicas remotas, esencialmente pagos realizados a través de Internet (ya sea en un dispositivo de escritorio, como una computadora portátil o un dispositivo móvil), deben incluir elementos que “vinculen dinámicamente la transacción a una cantidad específica y un beneficiario específico”. El RTS considera que se trata de una forma adicional de SCA.

Para este requisito de SCA, el monto de la transacción de pago, así como quién es el beneficiario (o el comerciante), debe devolverse al usuario en el momento de una transacción 2FA. Si hay algún cambio en el monto o en el beneficiario, se debe generar otro código de autenticación (por ejemplo, “vincular dinámicamente” ese código al nuevo beneficiario y/o monto del pago). Un mensaje SMS con toda la información requerida puede parecerse a la imagen de la derecha: el código de seguridad de 10 minutos, el nombre del comerciante (o del beneficiario) y el monto de la transacción.

Curiosamente, un código de autenticación generado por una aplicación compatible con TOTP de terceros, como Google Authenticator, se genera de forma completamente independiente de la información de pago/comerciante y, por lo tanto, no se puede vincular dinámicamente.

Independencia de canales

Este requisito es un poco complicado. El RTS establece que los “proveedores de servicios de pago adoptarán medidas de seguridad, cuando cualquiera de los elementos de la autenticación fuerte del cliente o el propio código de autenticación se utilice a través de un dispositivo multipropósito, para mitigar el riesgo que resultaría de ese dispositivo multipropósito. estar comprometido.” Un dispositivo multipropósito podría ser un dispositivo móvil o una tableta, o incluso una computadora portátil.

Si un usuario está en una computadora portátil y se le solicita que realice un pago, ese comerciante puede enviar un SMS al dispositivo móvil del usuario con el beneficiario (por ejemplo, el comerciante), así como la cantidad que va a pagar, junto con la autenticación. código en el cuerpo del SMS.

En otro ejemplo, si el usuario está utilizando un dispositivo móvil para interactuar con un comerciante e inicia un pago, esta independencia de canal no prohíbe específicamente los SMS ni ningún canal de entrega específico para dispositivos móviles. Aquí, es una línea muy fina. En muchos casos, el único dispositivo que tiene un usuario es un dispositivo polivalente, como un teléfono móvil. Pero, la independencia del canal es solo eso, un canal independiente en el mismo dispositivo, un SMS con un código de autenticación es un canal diferente (de hecho, es un canal fuera de banda , al que se accede a través del número de teléfono móvil) que el móvil. aplicación o navegador web que el usuario está interactuando con el comerciante. La misma independencia de canal se aplicaría al uso de una aplicación móvil para generar un código compatible con TOTP (como Google Authenticator), pero como se señaló anteriormente, el código de queja TOTP falla en la vinculación dinámica de la transacción.

Por el contrario, si el usuario estaba usando una aplicación móvil para acceder al comerciante, no sería posible enviar una notificación automática a esa misma aplicación (con el código de autenticación), ya que son el mismo canal.

Hay quienes dirían que 2FA a través de SMS es muy inseguro y, en algunos casos, eso podría ser cierto. Sí, hubo algunos casos aislados en los que un atacante logró acceder a mensajes SMS 2FA a través de SS7 en un operador; sin embargo, muchas de estas vulnerabilidades se han cerrado. Además, importa mucho cómo se genera y proporciona el código de autenticación al usuario y cómo el proveedor de servicios de mensajería entrega dichos códigos.

En situaciones en las que prevalecen los dispositivos multipropósito (y hoy en día, estos son y seguirán siendo los dispositivos más frecuentes), un canal de mensajería proporcionado por un operador móvil debe continuar siendo un canal fuera de banda viable para tokens 2FA.

Para un análisis más detallado, encontré una publicación de blog informativa de Frederik Mennes que brinda más detalles sobre qué tipos de escenarios, especialmente para dispositivos multipropósito, deben cumplir con PSD2 SCA.

PSD2 SCA no debe tomarse a la ligera, pero muchas soluciones 2FA ya implementadas deberían funcionar; sin embargo, también sabemos que muchos comerciantes en línea aún no brindan soluciones que cumplan con PSD2 SCA. Al momento de escribir este artículo, todavía hay tiempo suficiente para incorporar SCA en los flujos de trabajo de pago.

SAP Authentication 365 es una solución que proporciona una solución en la nube basada en API para permitir que las empresas implementen SCA compatible con PSD2. El servicio móvil SAP Authentication 365 es un servicio integral que le permite implementar un servicio de autenticación de dos factores (2FA) multicanal de forma rápida y segura, con autenticación adaptada a su negocio digital.

Ayuda a proteger la identidad y los datos de los clientes de su empresa al habilitar la autenticación a través de SMS, correo electrónico, notificaciones automáticas o tokens de software TOTP. La API REST de SAP simplifica la generación y autenticación de códigos de validación o autenticación y brinda flexibilidad y capacidades para permitir la implementación de una estrategia SCA compatible con PSD2.