Foro de preguntas y respuestas de PSD2

Busque más de 40 preguntas sobre temas como autenticación, seguridad de aplicaciones móviles de enlace dinámico y más

¿Cuáles son las sanciones si los PSP no cumplen con las nuevas regulaciones RTS para noviembre de 2018?

PSD2 es una directiva europea que todos los estados miembros de la UE deben adoptar. Los proveedores de servicios de pago deben cumplir con los requisitos de PSD2 para ser legalmente reconocidos como proveedores de servicios de pago con derecho a prestar servicios en la UE.

¿La EBA publicará una guía de evaluación de RTS en SCA y CSC similar a la guía del BCE publicada en 2014?

No tenemos información que confirme o niegue que la EBA emita una guía de evaluación similar.

¿Es SMS compatible con PSD2?

Uno de los objetivos de EBA en su RTS era mantenerse neutral en cuanto a la tecnología para proporcionar el mayor espacio posible para la innovación. El desafío era no ser muy prescriptivo al especificar los requisitos. En última instancia, RTS no prohíbe ninguna tecnología específica, sin embargo, algunas de las prácticas existentes ya no serán totalmente compatibles con los requisitos de SCA. Podemos decir que los SMS pueden ser vistos como un elemento de posesión, ya que normalmente solo pueden ser leídos por el destinatario del mensaje SMS. Entonces, en teoría, el SMS cumple con el requisito del elemento de posesión y, por lo tanto, puede usarse como un componente básico de una solución de firma de transacciones.

Para cumplir con los requisitos de Enlace Dinámico, el mensaje SMS debe incluir la información de pago, es decir, la cantidad de dinero e información sobre el beneficiario, además del código de autenticación. Los requisitos de enlace dinámico también indican que la confidencialidad e integridad de la información de pago debe protegerse. Esto podría implicar que la información de pago necesita ser encriptada. Sin embargo, descifrar el contenido de un mensaje SMS requeriría una aplicación en la tarjeta SIM del teléfono móvil o en el teléfono, lo cual no es práctico.

Al final, el uso de SMS implica tener un alto nivel de seguridad para el dispositivo del usuario, protección contra el fraude de intercambio de SIM, protección contra la posible intercepción y uso indebido de SMS. En realidad hoy, estos son desafíos muy difíciles. Las diferentes autoridades competentes tienen actualmente diferentes opiniones sobre el uso de SMS. Varias autoridades desalientan el uso de SMS, mientras que otras lo permiten. Monitoreamos estas opiniones y actualizaremos estas preguntas frecuentes cuando haya una decisión clara.

¿Se puede contar el móvil y el token como dos canales y cumplir con PSD2?

Según PSD2, el mecanismo de autenticación debe construirse a partir de dos de los tres elementos de autenticación posibles, es decir, algo que solo el usuario tiene, algo que solo el usuario sabe y algo que solo el usuario es.

¿Cuándo usarías el código de autenticación? ¿Lo consideras como un segundo factor?

El código de autenticación siempre debe usarse para autenticar a un usuario. El código de autenticación debe ser generado por un mecanismo de autenticación que se construye a partir de dos de los tres elementos de autenticación posibles, es decir, algo que solo el usuario tiene, algo que solo el usuario conoce y algo que solo el usuario es.

¿El protocolo 3D seguro para tarjetas es suficiente para SCA o es obligatorio?

3D Secure es, de hecho, un protocolo que los PSP pueden utilizar para crear una solución que cumpla con los requisitos de SCA para pagos con tarjeta.

¿Qué categoría de los tres elementos de SCA puede darle a OTP por SMS? ¿Es esto conocimiento o posesión?

El usuario recibe el mensaje SMS normalmente en un teléfono personal, por lo que este sería un elemento de posesión.

¿Podría aclarar el alcance de PSD2? ¿Son solo pagos por Internet (basados en el navegador en línea)? Si no, ¿qué más?

PSD2 cubre pagos basados en navegador y móviles.

¿Puede contarnos más sobre cómo implementa el análisis de comportamiento? ¿Es una extensión de DP4APPS SDK?

La autenticación de comportamiento de OneSpan es una extensión de OneSpan Mobile Security Suite. La autenticación de comportamiento permite no solo probar con precisión y sin problemas la identidad del usuario, sino que también puede detectar comportamientos específicos, por ejemplo, ataques de bot. Más información está disponible aquí.

Los clientes de OneSpan Mobile Security Suite pueden aprovechar su implementación existente agregando solo los nuevos componentes necesarios de la solución. Para lograr la mejor combinación de seguridad y facilidad de uso, hoy es importante combinar los tres elementos: 

  1. Seguridad de aplicaciones móviles con recolección de datos del dispositivo cliente 
  2. Marco de autenticación multifactorial y biométrico y canal seguro para una comunicación segura 
  3. El software de análisis de fraude y riesgo para analizar las entradas de los usuarios, los dispositivos, el comportamiento y aplicar la toma de decisiones en tiempo real a través de múltiples canales. El conjunto de soluciones de OneSpan cubre todas estas áreas. 

 

Más información sobre Cumplimiento de PSD2 .

¿Hay alguna guía sobre si la validación cuando se usa la biometría debería ocurrir en el lado del servidor o del lado del cliente?

Las Normas Técnicas Regulatorias (RTS) sobre Autenticación Fuerte del Cliente no especifican si la verificación biométrica debe realizarse en el lado del cliente o del servidor. Entonces ambas opciones están permitidas.

¿OneSpan ha recibido garantías formales del BCE con respecto al cumplimiento de sus tokens con PSD2 RTS?

En este momento, no existe un programa formal de certificación para productos específicos bajo PSD2. Como tal, OneSpan no puede obtener una garantía formal. Sin embargo, OneSpan analiza el cumplimiento de sus productos de manera informal con las autoridades competentes para asegurarse de que interpretamos correctamente el RTS y para garantizar que nuestros productos cumplan.

¿Tiene la intención de etiquetar cada modelo de token (p. Ej. DP310) con una indicación de cumplimiento PSD2?

OneSpan actualmente no planea hacer esto. Además, no existe un programa de certificación formal para soluciones de autenticación fuertes bajo PSD2.

¿Son compatibles los dispositivos de hardware de autenticación pin-pad OneSpan?

Los requisitos de vinculación dinámica en el RTS establecen que el código de autenticación debe calcularse sobre cierta información de transacción, incluida la cantidad de dinero e información sobre el beneficiario (por ejemplo, el número de cuenta bancaria del beneficiario).

Además, el pagador debe conocer esta información de transacción. Finalmente, la confidencialidad, integridad y autenticidad de la información de la transacción debe estar protegida en todo momento. Con base en estos requisitos, podemos decir lo siguiente sobre el uso de dispositivos de hardware de autenticación de PIN-pad:

  • Este dispositivo proporciona un nivel de seguridad de elementos de conocimiento y posesión muy alto 
  • Este dispositivo proporciona una manera para que el usuario final ingrese la cantidad y los detalles del beneficiario e los incluya en la generación de un código de autenticación único 
  • El usuario conoce las acciones con dicho dispositivo. Por lo tanto, el hardware Digipass con PIN-pad, si se usa con el modo de firma de datos de transacción, cumple con los requisitos de enlace dinámico.

¿La vinculación dinámica es lo mismo que la firma de transacciones?

Sí lo es. El término "enlace dinámico" es utilizado por PSD2 y el RTS en SCA.

¿Significa esto que OneSpan proporciona la vinculación dinámica, en lugar de una entidad separada, como el PSP?

Es responsabilidad de la PSP realizar una autenticación sólida de sus usuarios. OneSpan puede proporcionar a los PSP productos y servicios para realizar una autenticación sólida.

El RTS requiere la separación de canales entre la aplicación que utilizará la transmisión OTP y la OTP. ¿Cómo ve el cumplimiento de 1AA?

El borrador final de RTS ya no requiere segregación de canales. Como se indicó en los comentarios en el borrador final de RTS, este lenguaje fue eliminado del borrador de RTS, porque era confuso.

¿Cómo cumple con el requisito del artículo 2 (2) A) cuando un cliente realiza varios pagos juntos a diferentes beneficiarios?

Para pagos masivos, el código de autenticación debe calcularse en función de la cantidad total de dinero de todos los pagos combinados y en función de los números de cuenta de todos los beneficiarios.

¿OneSpan tiene soluciones para generar enlaces dinámicos en casos donde los clientes no están dispuestos a usar teléfonos inteligentes?

Hoy, OneSpan ofrece soluciones de autenticación a más de 2,000 bancos en todo el mundo, con varios casos de uso, necesidades comerciales, grupos de usuarios y requisitos reglamentarios. Esto es posible, porque OneSpan ofrece una amplia gama de soluciones que pueden cubrir todas las necesidades posibles. Por ejemplo, OneSpan proporciona dispositivos muy fáciles de usar que cumplen con PSD2 con pantallas grandes, botones e incluso comandos de voz para usuarios mayores: Digipass 301

Opcionalmente, en el espacio SWYS, una opción popular es usar uno de los dispositivos de gama alta con un teclado de goma robusto: Digipass 770

Este dispositivo no necesita una entrada exhaustiva del usuario, solo necesita la aprobación del cliente y una breve entrada del PIN. Los estudios de aceptación de usuarios realizados por los clientes de OneSpan muestran una tasa de adopción muy alta y una disminución esencial en las llamadas al servicio de asistencia de los usuarios al cambiar a esta tecnología.

Para la autenticación por SMS usando un proceso 3DS, ¿aún necesitamos incluir detalles de pago cuando un ACS genera el OTP y lo distribuye al número de teléfono móvil registrado?

Nuestra interpretación de los requisitos de enlace dinámico en el borrador final de RTS es que la información de pago debe incluirse en el mensaje SMS para la autenticación del pago.

Tenemos un hardware Digipass 275 con 5 números que se pueden usar como respuesta de desafío para la vinculación dinámica. ¿Cumple esto con los enlaces dinámicos?

Es muy probable que esto cumpla con el borrador final de RTS.

¿OneSpan Go 6 Digipass cumple con RTS con respecto al requisito de vinculación dinámica para pagos de alto valor?

En general, los Go-tokens no generan códigos de autenticación sobre la información de pago (como la cantidad de dinero). Por este motivo, no se puede utilizar para el enlace dinámico, que siempre se requiere para pagos superiores a 500 euros.

¿Cómo las soluciones basadas en hardware, como los tokens OTP, proporcionan enlaces dinámicos con transacciones individuales?

En general, los usuarios pueden ingresar información de pago, como la cantidad de dinero y el número de cuenta del beneficiario, en tokens de hardware. Esto puede suceder a través del teclado del token, a través de un cable USB o escaneando un código visual. El token de hardware puede usar la información de pago para calcular un código de autenticación de acuerdo con los requisitos de enlace dinámico.

¿La fuente de alimentación tiene que ver los detalles del pago (cantidad y cuenta) en el token? ¿Lo que ves es lo que firmas?

"Ver lo que firma" en los tokens de hardware se puede utilizar para cumplir con el requisito de enlace dinámico, pero no es la única opción. Es muy probable que también se muestren los datos en una aplicación móvil.

¿Podría ser más específico sobre las posibilidades de autorización / firma de transacciones múltiples? ¿La vinculación dinámica permite múltiples transacciones / beneficiarios?

El borrador final de RTS establece que, en el caso de pagos masivos, el código de autenticación debe calcularse sobre la cantidad total de dinero de los pagos, así como la información sobre los beneficiarios de los diversos pagos.

¿Sigue siendo necesaria la vinculación dinámica para pagos inferiores a 30 euros en caso de implementación de la solución de supervisión de transacciones?

No, no se requiere vinculación dinámica para pagos por debajo de 30 EUR, siempre que el monto acumulado o el número de transacciones de pago electrónico remotas iniciadas por el pagador desde la última aplicación de autenticación de cliente fuerte no exceda, respectivamente, de 100 o cinco EUR transacciones individuales consecutivas de pagos electrónicos remotos.

Si se usan exenciones, ¿es correcto que se pueda omitir el SCA en total y no solo el enlace dinámico?

Ese es nuestro entendimiento también.

¿Cuál es la opinión de OneSpan sobre el RTS para la banca corporativa?

El RTS en SCA proporciona requisitos mínimos de seguridad para autenticar a los usuarios. En el caso de la banca corporativa, los usuarios generalmente realizan pagos de montos relativamente altos. Por lo tanto, esperamos que los bancos protejan sus aplicaciones de banca corporativa con mecanismos de autenticación más fuertes que los requeridos por el RTS en SCA.

¿Cuáles son los requisitos si el cliente ya tiene una lista de beneficiarios certificados con SA pero tiene que hacer una transferencia de dinero con un valor diferente?

Como se indica en el Artículo 13 del borrador final de RTS, no se requiere SCA para pagos a beneficiarios confiables. Para conocer las condiciones precisas, consulte el artículo en sí.

El RTS permite la autenticación de un solo factor solo después del primer intento. 2FA se debe usar cada 9 días. Esto es diferente de lo que ha recomendado en el pasado. ¿Por favor explique?

El artículo 10 del borrador final de RTS establece que los proveedores de servicios de pago no están exentos de la aplicación de una autenticación de cliente sólida a los pagadores que desean consultar su saldo o consultar su historial de pagos de los últimos 90 días si se cumple alguna de las siguientes condiciones :

  • El usuario del servicio de pago accede por primera vez en línea al saldo de su cuenta o al historial de pagos desde los primeros 90 días del párrafo 1
     
  • La última vez que el usuario del servicio de pago accedió en línea a su historial de pagos de los últimos 90 días del párrafo 1 y se aplicó una autenticación de cliente sólida hace más de 90 días.

¿Pueden los pagos ser incluidos en la lista blanca? Si validamos el destino de la lista blanca y luego permitimos pagos sin DL a ese destino, ¿debería ser suficiente?

El artículo 13 del borrador final de RTS permite que el proveedor de servicios de pago no realice una autenticación sólida del cliente si el pagador inicia una transacción de pago en la que el beneficiario se incluye en una lista de beneficiarios de confianza previamente creados. Ver el Artículo 13 para los detalles.

¿Es necesario volver a empaquetar OneSpan Mobile App Shielding con la aplicación de banca móvil cada vez que hay una actualización de versión?

Hay dos partes de esta pregunta:

  • Cada vez que el PSP está a punto de lanzar su aplicación móvil al mercado de aplicaciones, se debe aplicar el blindaje de la aplicación para proteger la aplicación. La buena noticia es que la envoltura de protección de la aplicación tarda varios segundos y, por lo tanto, no afecta los ciclos de lanzamiento de la aplicación de la PSP.
     
  • Debido a que la solución OneSpan Mobile App Shielding se actualiza regularmente para defenderse de las amenazas móviles en evolución, también se recomienda que los PSP protejan sus aplicaciones con la última versión para garantizar el mayor nivel de protección posible.

¿El blindaje de la aplicación cubre la protección de clonación?

OneSpan Mobile Security Suite ofrece una función de enlace de dispositivos que ofrece protección de clonación para aplicaciones móviles.

¿Necesita protección de aplicaciones móviles cuando utiliza una solución de SMS? Aplicación SIM?

El dispositivo móvil donde llega el SMS también puede contener una aplicación de autenticación (en el escenario 1aa o 2aa), donde se debe ingresar el SMS. Esta aplicación necesitaría ser protegida usando el blindaje de la aplicación móvil.

¿Hay alguna preocupación de seguridad adicional con la implementación de APP2APP vs push?

En nuestra opinión, estos son dos enfoques igualmente seguros que, en última instancia, dependen de la misma tecnología subyacente del canal de comunicación seguro. Los vemos óptimos con diferentes modelos de uso. Muchos de los bancos implementarán la aplicación de autenticación que funcionaría en la siguiente configuración: 

Cuando la transacción se inicia dentro de la aplicación de banca móvil, el enlace de comunicación de App2App se establecerá hacia la aplicación de autenticación instalada en el mismo dispositivo. Esto proporciona la capacidad de cambiar automáticamente entre dos aplicaciones, lo que mejora la experiencia del usuario. 

Cuando la transacción se inicia en el navegador web desde otro dispositivo (PC o tableta), la notificación PUSH se enviará a la aplicación de autenticación instalada en el dispositivo móvil del usuario. Alternativamente, con casi la misma experiencia de usuario, se puede utilizar el proceso de escaneo óptico y firma. 

Puede encontrar más información sobre las soluciones de Cronto aquí: Signo de Cronto

Para App2App con canal de comunicación seguro, el intercambio de datos entre las aplicaciones se realiza a través de backend en un formato cifrado.

¿Es la plataforma universal de Windows (UWP) y las tabletas de Windows una plataforma de solución viable para SCA en una configuración 2AA de 1AA? ¿El sandboxing es diferente entre iOS y Android?

Las técnicas de sandboxing de la Plataforma universal de Windows (UWP) son similares a las de Android e iOS. UWP adoptó muchos de los conceptos de Android e iOS. Windows 10 Mobile permite ejecutar solo aplicaciones para UWP, por lo que los mecanismos de sandboxing tienen una fuerza comparable a la de Android e iOS aquí. Windows 10 estándar permite ejecutar aplicaciones UWP y Windows normales, por lo que el sandboxing es menos fuerte que Android o iOS.

Cuando la transacción se inicia desde la aplicación TPP, ¿cuál de los casos de uso presentados parece más probable que se use?

Cuando el usuario usa una aplicación TPP, lo más probable es que veamos uno de los siguientes tres casos de uso: 

  • PUSH notificación del banco a la aplicación de autenticación proporcionada por la institución financiera. Esto no necesita una integración específica entre las partes.
     
  • Comunicación App2App entre una aplicación TPP y una aplicación de autenticación proporcionada por la institución financiera. Esto requiere una integración mínima del servicio de autenticación entre TPP y la institución financiera. 
     
  • Marco de seguridad móvil integrado en la aplicación TPP. Esto implica que TPP no dependerá de la implementación de la autenticación por parte de la institución financiera, sino que proporcionará la suya. 

En las tres opciones, los TPP y las instituciones financieras deberán recopilar datos de entrada de los dispositivos del usuario y realizar un análisis exhaustivo en múltiples aplicaciones, canales y puntos finales para una evaluación completa del riesgo. La mejor opción es implementar un software de riesgo dedicado, como OneSpan Risk Analytics, que proporciona: 

  • Detección en tiempo real de fraudes sofisticados 
     
  • Procesamiento de grandes cantidades de puntos de datos para detectar comportamientos anormales del usuario, transacciones sospechosas y navegación atípica en la aplicación de pago 
     
  • Puntuación precisa de riesgos y mitigación de amenazas en todos los dispositivos móviles comunes (por ejemplo, teléfonos móviles y tabletas) 
     
  • Operaciones invisibles para los usuarios finales, que mitigan el fraude y proporcionan la mejor experiencia de usuario posible.
     

Si se usa la autenticación de dos aplicaciones, ¿ambas aplicaciones móviles deben usar el sistema operativo sandboxing y el blindaje de la aplicación móvil?

El sistema operativo aplica el sandboxing (p. Ej. Android o iOS) del dispositivo móvil para cada aplicación que se ejecute en el dispositivo. El blindaje de la aplicación móvil debe aplicarse a la aplicación de autenticación.

¿Digipass SDK está disponible / es compatible con nativescript?

Si, este es el caso.

¿Podría dar más detalles sobre la comunicación segura que ofrece OneSpan Mobile Security Suite? ¿Qué se usa para asegurarlo? ¿Qué se requiere en el servidor?

La funcionalidad de comunicaciones seguras de OneSpan Mobile Security Suite brinda la capacidad de crear un canal de comunicación seguro entre la aplicación y el servidor, protegiendo la confidencialidad, integridad y autenticidad de toda la información de pago. OneSpan Mobile Security Suite viene con SDK del lado del cliente y del lado del servidor para establecer el canal seguro. De esta manera, los PSP pueden configurar fácilmente un canal seguro sin tener que gestionar la complejidad del canal seguro ellos mismos.

Si el identificador de hardware, la huella digital y el pin deben combinarse para una aplicación, ¿hay alguna recomendación para un algoritmo HMAC?

Recomendamos utilizar algoritmos HMAC estándar, como HMAC-SHA256 o HMAC-SHA3.

Para cumplir con la situación 2AA, ¿deben protegerse ambas aplicaciones mediante el blindaje de la aplicación móvil? ¿O solo la aplicación de autenticación?

La aplicación de autenticación debe protegerse con protección de aplicaciones móviles. La aplicación bancaria puede estar protegida, pero no se requiere en el borrador final de RTS.

¿Cómo ve el uso de los parámetros de comportamiento como factores de autenticación?

Sí, vemos esto como un posible elemento de inherencia. Los comentarios de la EBA al borrador final de RTS también indican que esto es posible.

¿OneSpan tiene una solución para usar el factor de 'inherencia' (biometría) como elemento de autenticación?

Sí, OneSpan Mobile Security Suite admite la autenticación biométrica basada en huellas digitales, escaneo facial y el comportamiento del usuario.

¿Puedes hablar de TRA para pagos masivos?

En caso de pagos masivos, el código de autenticación para SCA debe calcularse en función de la cantidad total de dinero de todos los pagos combinados y en función de los números de cuenta de todos los beneficiarios. No hay disposiciones específicas sobre TRA para pagos a granel.

¿Puede una solución de prevención de OneSpan reunir todo tipo de transacciones, incluyendo: banca electrónica, tarjeta, pos, banca móvil, billeteras, etc.?

Sí, OneSpan Risk Analytics se puede utilizar para analizar transacciones para diferentes tipos de canales de pago.

¿Es la solución OneSpan una solución basada en la nube? Y si es así, ¿privado o público?

OneSpan Risk Analytics está disponible en las instalaciones y en la nube. La versión en la nube está alojada por OneSpan.

¿OneSpan Risk Analytics cumple con los requisitos de RTS?

Sí, OneSpan Risk Analytics puede realizar análisis de riesgo de transacción de acuerdo con los requisitos del borrador final de RTS.

¿Todos los PSP requieren TRA, incluso si planean usar SCA para todas las transacciones? Si es así, ¿cuál es la razón detrás de este requisito?

De hecho, los PSP siempre necesitan usar TRA, incluso si usan SCA. TRA proporciona una segunda capa de seguridad junto a SCA. TRA es útil para protegerse contra los ataques de ingeniería social, mediante los cuales un adversario intenta convencer al usuario genuino de confirmar un pago utilizando SCA cuando el pago es realmente fraudulento.

¿Las directivas o directrices definen ciertos mandatos para las soluciones 2AA y 1AA en caso de pérdida o robo del medio físico?

El borrador final de RTS establece que el procedimiento de autenticación debe incluir, en general, mecanismos de monitoreo de transacciones para detectar intentos de usar las credenciales de seguridad personalizadas del usuario de un servicio de pago que se perdieron, fueron robadas o malversadas. Esto se aplica a todas las soluciones de autenticación, no solo a las de la categoría 2aa o 1aa.

Contáctenos

¿Tienes otras preguntas sobre PSD2? Obtenga la información que necesita rápidamente.