Autenticación reforzada (SCA) y 3D Secure: cuándo se exige, exenciones y conversión

La Directiva Europea de Servicios de Pago (PSD2) transformó los cobros en comercio electrónico al introducir la autenticación reforzada del cliente, conocida habitualmente como SCA (*Strong Customer Authentication*). Esta exigencia normativa obliga a verificar la identidad del pagador mediante al menos dos factores independientes entre tres categorías posibles: algo que sabe (como una contraseña o PIN), algo que posee (como un teléfono móvil verificado mediante una notificación en la aplicación bancaria) y algo que es (biometría facial o dactilar).

Para articular este mecanismo en los pagos con tarjeta en la web, la industria bancaria y las marcas internacionales desarrollaron el estándar 3D Secure en sus versiones 2.x. Aunque este protocolo reduce el fraude de forma drástica, añade pasos en la interacción del usuario. Comprender cuándo es obligatoria la SCA, cómo funcionan las exenciones técnicas y qué consecuencias tiene sobre el abandono en la pasarela de pago resulta imprescindible para cualquier negocio digital.

Ámbito de aplicación: operaciones dentro y fuera de la norma

La exigencia de SCA no afecta a todos los movimientos dinerarios. La normativa comunitaria acota su obligatoriedad a los pagos electrónicos remotos iniciados por el ordenante (*Customer-Initiated Transactions* o CIT) en los que tanto el banco emisor de la tarjeta como la entidad adquirente que procesa el cobro operen dentro del Espacio Económico Europeo (EEE).

Quedan automáticamente al margen de la SCA los siguientes supuestos:

• **Operaciones fuera de la zona comunitaria (*one-leg out*)**: cuando el banco emisor de la tarjeta o el adquirente del comercio se encuentra fuera del EEE (por ejemplo, un comprador con tarjeta estadounidense que adquiere un servicio en una web española).
• Cobros por venta a distancia clásica (MOTO): transacciones gestionadas mediante órdenes por correo o teléfono (*Mail Order / Telephone Order*), tramitadas en entornos manuales sin intervención directa del usuario en un formulario web interactivo.
• Transacciones iniciadas por el comercio (MIT): cobros en los que el usuario no está presente en el momento de la ejecución, como las renovaciones automáticas de suscripciones o los cobros variables por consumo. En estos casos, la primera transacción en la que el usuario introduce y valida la tarjeta sí debe superar la SCA para registrar el mandato; los cargos posteriores quedan fuera del ámbito de la SCA siempre que sigan ese acuerdo previo, un aspecto crítico en la renovación automática de suscripciones.

El catálogo de exenciones bajo la PSD2

Para evitar que cada pequeña compra exija abrir la aplicación del banco, la normativa permite que los comercios y las entidades adquirentes soliciten exenciones formales. No obstante, la concesión final de la exención siempre corresponde al banco emisor de la tarjeta, que analiza el riesgo antes de autorizar el cobro o forzar el paso de autenticación.

Pagos de bajo importe

Las transacciones remotas inferiores a 30 euros pueden beneficiarse de una exención directa. Sin embargo, el banco emisor monitoriza el uso acumulado: si el cliente realiza cinco pagos consecutivos sin SCA bajo esta exención, o si la suma de cobros sucesivos supera los 100 euros, la pasarela exigirá obligatoriamente autenticar la siguiente compra.

Análisis de riesgo de la transacción (TRA)

La exención por análisis de riesgo (*Transaction Risk Analysis*) permite obviar la SCA en importes más elevados (hasta 100, 250 o 500 euros) siempre que el índice general de fraude de la entidad adquirente o del emisor se sitúe por debajo de umbrales muy estrictos fijados por ley (0,13 %, 0,06 % y 0,01 % respectivamente). Si el procesador mantiene una tasa de fraude reducida, puede marcar la operación para que fluya sin fricción.

Beneficiarios de confianza (*whitelisting*)

El titular de la tarjeta tiene derecho a incluir a un comercio concreto en su lista de empresas de confianza a través de la aplicación de su propio banco. Una vez superada la primera compra con SCA e incorporado el comercio a dicha lista, las transacciones futuras quedan exentas de autenticación adicional, salvo que el banco detecte indicios de riesgo anómalo.

Fricción, abandono y transferencia de responsabilidad

El protocolo 3D Secure 2 contempla dos vías de procesamiento técnico: el flujo sin fricción (*frictionless flow*), en el que el banco emisor evalúa cientos de parámetros del dispositivo y del contexto para autorizar el cobro en milisegundos sin mostrar pantallas intermedias, y el flujo con reto (*challenge flow*), en el que se abre la ventana bancaria para validar la operación con biometría o clave temporal.

Cada vez que un cobro se desvía hacia un *challenge*, la probabilidad de que el cliente abandone el proceso de compra aumenta. Retrasos en la recepción del mensaje SMS, fallos al abrir la aplicación bancaria o dudas sobre la seguridad de la redirección provocan caídas medibles en la conversión en los pagos online.

Sin embargo, la autenticación introduce una ventaja operativa determinante: el traspaso de responsabilidad (*liability shift*). Cuando una transacción supera con éxito la SCA a través de un *challenge* 3D Secure, la responsabilidad financiera ante un eventual contracargo por fraude se traslada íntegramente del comercio al banco emisor. Si el comercio solicita una exención por TRA y el emisor la aprueba sin fricción, las reglas de las marcas determinan habitualmente quién asume el coste del contracargo si la operación resulta fraudulenta. Por el contrario, si el emisor rechaza la exención solicitada, devolverá un código específico (*soft decline*), lo que obliga a la pasarela a reiniciar la llamada solicitando un *challenge* de inmediato sin perder la venta.

Conclusión

La gestión de la SCA no debe plantearse como un dilema cerrado entre seguridad absoluta y ventas fluidas. Las plataformas de cobro modernas analizan el perfil de cada transacción para solicitar exenciones justificadas cuando los importes y los niveles de riesgo lo permiten, gestionando los *soft declines* de manera transparente para que el usuario complete la autenticación solo cuando la normativa o la prevención del fraude lo hacen estrictamente necesario.