¿Tu stack de pagos cumple con PSD2? Lo que sigue sorprendiendo a los equipos en 2026

La mayoría de los equipos de pagos creen que resolvieron el cumplimiento de pagos PSD2 SCA cuando activaron 3DS2. No fue así. Lo que hicieron fue trasladar la complejidad una capa más abajo, hacia la lógica de exenciones, la secuenciación MIT y el comportamiento de autenticación del lado del emisor que ningún dashboard de PSP muestra con claridad. Vemos las consecuencias cada semana: caídas en la tasa de aprobación que nadie puede explicar, pérdidas de conversión atribuidas al "comportamiento del emisor" y hallazgos de auditoría SCA que solo aparecen cuando se añade un nuevo mercado.

Conclusiones clave

• Activar 3DS2 cumple el requisito técnico de SCA, pero la lógica de exenciones mal configurada es donde los merchants realmente pierden puntos en la tasa de aprobación.
• Las transacciones iniciadas por el merchant quedan fuera del alcance de SCA, pero la autenticación inicial del mandato debe superar SCA; de lo contrario, los emisores rechazarán los cobros posteriores.
• Las exenciones TRA (Transaction Risk Analysis) se sitúan a nivel de adquirente y dependen de mantener las tasas de fraude por debajo de los umbrales de la EBA. Tus decisiones de enrutamiento afectan directamente a las exenciones que puedes reclamar.
• PSD3 y el Reglamento de Servicios de Pago trasladan más responsabilidad por fraude hacia los PSP e introducen obligaciones más estrictas de Verificación del Beneficiario. Los merchants que usan servicios de iniciación de pagos deben comenzar sus evaluaciones de brechas ahora.
• El enrutamiento multi-PSP es una palanca infrautilizada para la optimización de SCA: distintos adquirentes tienen diferentes umbrales TRA, lo que significa que la misma transacción enrutada a través de un proveedor diferente puede desbloquear un flujo sin fricción.

¿Qué exige realmente el cumplimiento PSD2 SCA en 2026?

La Autenticación Reforzada de Clientes (SCA) de PSD2 exige que los pagos electrónicos remotos con tarjeta en la UE y el Reino Unido utilicen al menos dos factores de autenticación independientes: algo que el cliente sabe, tiene o es. EMV 3DS2 es el mecanismo técnico principal para las transacciones sin tarjeta presente, y cuando el ACS de un emisor presenta un desafío multifactor, la transacción cumple el estándar SCA.

Ese es el punto de partida. La complejidad operativa reside en todo lo que se construye sobre él: qué transacciones están en alcance, cuáles califican para exenciones y qué ocurre cuando un emisor no acepta tu solicitud de exención.

SCA se aplica a transacciones con tarjeta no presente en las que tanto el pagador como el proveedor de servicios de pago están domiciliados en el Espacio Económico Europeo o el Reino Unido. Las transacciones con un solo tramo en alcance, donde solo una de las partes está sujeta a la norma, se sitúan en una zona gris que los emisores gestionan de forma inconsistente. Lo vemos con frecuencia en merchants con entidades domiciliadas en la UE que atienden a clientes en mercados con geografía de emisores mixta.

Los cuatro errores de SCA que siguen apareciendo en producción

Los fallos de SCA más comunes en producción no son fallos técnicos; son fallos de configuración en la lógica de exenciones, la secuenciación MIT y el enrutamiento de respaldo. Cada uno es prevenible con la infraestructura adecuada, pero cada uno también requiere visibilidad sobre todo tu stack de PSP, no solo el dashboard de un adquirente.

Tratar las exenciones de SCA como reglas permanentes

Las exenciones de SCA no son estáticas. Las exenciones de análisis de riesgo de transacción (TRA) requieren que tu adquirente mantenga las tasas de fraude por debajo de los umbrales establecidos por la Autoridad Bancaria Europea. Si tu tasa de fraude supera el umbral en un período determinado, las exenciones TRA dejan de estar disponibles para ese adquirente, y cada transacción que dependía de ellas desencadenará un desafío o un rechazo suave.

A partir de nuestras integraciones en verticales de e-commerce y marketplaces, vemos cómo los merchants descubren esto solo cuando la conversión cae de forma inesperada tras un pico de fraude. Para cuando se detecta la caída, la ventana de exención ya se ha perdido durante días. La elegibilidad para exenciones requiere monitorización activa, no una revisión trimestral.

Vale la pena tener en un mismo lugar las principales exenciones disponibles bajo PSD2 y su alcance:

• Transacciones de bajo importe por debajo de 30 €, sujetas a límites acumulados de cinco transacciones o 100 € antes de que se requiera SCA.
• Listas de beneficiarios de confianza, donde el cliente ha incluido explícitamente a un merchant en la lista blanca con su emisor.
• Pagos corporativos que utilizan procesos y protocolos de pago dedicados, confirmados como de bajo riesgo.
• Exenciones TRA para umbrales de valor de transacción bajo, medio y alto, cada uno de los cuales requiere tasas de fraude por debajo del 0,13 %, 0,06 % y 0,01 % respectivamente.
• Transacciones recurrentes después del primer mandato autenticado con SCA.

Configurar incorrectamente las transacciones iniciadas por el merchant

Las transacciones iniciadas por el merchant quedan fuera del alcance de SCA. Las suscripciones, los cargos diferidos y los cobros de cuotas a partir del primer pago califican como MIT, y aplicarles 3DS genera fricción innecesaria y a veces rompe el flujo por completo. El error que vemos con mayor frecuencia se da en la dirección contraria: los merchants omiten la autenticación SCA en la configuración inicial del mandato y luego se preguntan por qué los emisores rechazan los cargos MIT posteriores.

El pago de establecimiento del mandato debe superar SCA. Esa primera transacción ancla todos los cargos futuros de la serie. Si se omite, se rechaza con un decline suave o se enruta a través de un PSP que no lo marca correctamente como acuerdo recurrente, la cadena MIT se rompe a nivel del emisor. Esto es especialmente frecuente cuando los merchants migran a un nuevo adquirente a mitad del ciclo de vida de una suscripción y no reautentican los mandatos existentes.

Aplicar 3DS de forma uniforme a todas las transacciones

Aplicar 3DS a todas las transacciones no es una gestión de riesgos conservadora. Es un impuesto a la conversión que recae sobre tus mejores clientes. Los compradores habituales y de confianza en categorías de bajo riesgo no necesitan un desafío. Añadir uno reduce las tasas de finalización y le indica al emisor que no tienes inteligencia de riesgo a nivel de transacción.

Con base en nuestra infraestructura, el enfoque correcto superpone Risk Conditions sobre la lógica de 3DS. Las transacciones de dispositivos conocidos, patrones de baja velocidad y perfiles de clientes de confianza deben fluir sin un desafío 3DS. Las señales sospechosas, los dispositivos nuevos, los valores atípicos de alto importe y las inconsistencias geográficas deben activarlo. El producto 3DS de Yuno admite lógica de condiciones personalizadas que enruta las transacciones por vías de desafío o sin fricción basándose en señales reales, no en reglas generales.

Ignorar la gestión de rechazos suaves del emisor

Cuando un emisor rechaza una solicitud de exención, devuelve un rechazo suave con un indicador de autenticación requerida. Los merchants que no están configurados para gestionar esta respuesta pierden la transacción por completo. La respuesta correcta es volver a presentar la transacción a través del desafío 3DS. Sin lógica de respaldo automatizada, esa recuperación nunca ocurre.

Este es un problema especialmente grave en entornos multi-PSP donde cada proveedor gestiona los rechazos suaves de forma diferente. Hemos visto casos en los que un adquirente reintenta automáticamente, otro descarta la transacción y un tercero genera un error que queda sin gestionar durante horas. La orquestación centralizada cierra esa brecha aplicando una lógica de respaldo consistente en todos los adquirentes del stack.

¿Cómo afecta el enrutamiento multi-PSP a los resultados de SCA?

Las decisiones de enrutamiento y los resultados de SCA están directamente relacionados porque la elegibilidad para las exenciones TRA es específica del adquirente, no del merchant. Un adquirente con una tasa de fraude consistentemente baja tiene acceso a exenciones TRA de mayor valor que otro adquirente en tu stack puede no tener.

Esto significa que la misma transacción enrutada a través de distintos adquirentes puede tener resultados de autenticación materialmente diferentes. Una ruta activa un flujo sin fricción. Otra activa un desafío. Una tercera hace un rechazo suave y requiere un reintento. Los datos de la plataforma de Yuno muestran que el enrutamiento consciente de exenciones, que dirige las transacciones al adquirente mejor posicionado para reclamar una exención determinada, mejora las tasas de flujo sin fricción en los mercados de la UE sin ningún cambio en el UX de checkout del merchant.

Este es un conocimiento que solo emerge cuando tienes visibilidad multi-PSP en un único lugar. Un solo adquirente no puede comparar su propia elegibilidad para exenciones con la de un competidor. Yuno sí puede, porque vemos el panorama completo de todos los proveedores en tu stack. Payment Concierge muestra estas diferencias a nivel de adquirente en tiempo real, para que los equipos de operaciones de pago puedan actuar sobre ellas en lugar de descubrirlas en un análisis post-mortem.

¿Qué cambian PSD3 y el PSR para los merchants que ya operan con stacks conformes a PSD2?

PSD3 no es una versión renombrada de PSD2; es una expansión estructural que desplaza la responsabilidad por fraude, amplía el alcance de SCA en escenarios específicos e introduce nuevas obligaciones para los usuarios de servicios de iniciación de pagos. Los merchants que traten PSD3 como una actualización incremental se verán sorprendidos cuando los plazos de transición se ajusten.

Los cambios más significativos desde el punto de vista operativo incluyen:

• Mayor traslado de la responsabilidad por fraude hacia los PSP, con una rendición de cuentas más explícita cuando se producen estafas de pagos push autorizados a través de canales de iniciación de pagos.
• La Verificación del Beneficiario pasa a ser obligatoria para los flujos de cuenta a cuenta, con los estados miembros de la zona euro ya obligados a soportarla desde octubre de 2025.
• Requisitos más estrictos en torno a los escenarios de ingeniería social, donde los merchants y los PSP deben demostrar la debida diligencia cuando los clientes son manipulados para autorizar pagos fraudulentos.
• Reglas de SCA más claras para los métodos de pago sin tarjeta, cerrando las brechas que PSD2 dejó abiertas para wallets y pagos basados en cuenta.
• Derechos ampliados para que los PSP compartan información sobre fraude entre instituciones, lo que cambia la dinámica de la selección de herramientas de prevención del fraude.

Para los merchants que actualmente utilizan servicios de iniciación de pagos junto con los carriles de tarjeta, el marco de responsabilidad es lo más urgente que revisar. Las disposiciones de responsabilidad por fraude de PSD3 crean una exposición que no existía bajo PSD2 para ciertos tipos de transacciones.

Cómo gestiona Yuno la infraestructura de cumplimiento SCA

El producto 3DS de Yuno ofrece a los merchants control total sobre cuándo y cómo se aplica la autenticación, sin necesidad de ingeniería personalizada para cada mercado o adquirente. La lógica de condiciones personalizadas enruta las transacciones basándose en la puntuación de riesgo, la geografía, el estado del cliente y los patrones de velocidad.

Los clientes de confianza evitan la fricción. Las señales sospechosas activan verificaciones por capas. Y el respaldo ante rechazos suaves se gestiona automáticamente en todos los adquirentes del stack, para que una solicitud de exención rechazada no se convierta en una transacción perdida. La capa Risk Conditions de Yuno se sitúa antes de 3DS, filtrando las transacciones conocidas como buenas antes de que lleguen al paso de autenticación y bloqueando a los actores conocidos como malos antes de que consuman recursos del PSP.

El resultado es un enfoque por capas que hace lo que el 3DS general no puede: proteger la conversión para los clientes legítimos mientras se mantienen las tasas de fraude que permiten conservar las exenciones TRA disponibles. Los datos de la plataforma de Yuno muestran una reducción del fraude del 29 % para los merchants que usan Risk Conditions combinado con el enrutamiento inteligente de 3DS.

Para la transición a PSD3, la infraestructura de Yuno ya está diseñada para gestionar las obligaciones de Verificación del Beneficiario y las condiciones de SCA ampliadas que introduce el reglamento. Los merchants en Yuno no necesitan rediseñar su stack de autenticación cuando PSD3 entre en vigor. La capa de configuración absorbe el cambio.

La auditoría práctica que todo responsable de pagos debe realizar ahora

Antes de que los plazos de PSD3 se compriman aún más, vale la pena completar tres auditorías en tu stack actual.

• Mapea cada tipo de transacción contra la taxonomía de exenciones y exclusiones de SCA. Confirma que los mandatos MIT están correctamente autenticados en el momento de la configuración. Identifica cualquier flujo de transacción donde falten indicadores de exención o estén aplicados incorrectamente.
• Comprueba las tasas de fraude a nivel de adquirente frente a los umbrales TRA actuales de la EBA. Si algún adquirente en tu stack se acerca a un techo de umbral, construye la lógica de enrutamiento para desplazar el volumen antes de que se pierda la elegibilidad para exenciones.
• Prueba tus rutas de respaldo ante rechazos suaves. Activa un rechazo suave deliberado en staging y confirma que el reintento automatizado a través del desafío 3DS funciona correctamente en todos los adquirentes. Si no es así, estás perdiendo transacciones en producción ahora mismo.

Estas tres comprobaciones requieren menos de una semana con las herramientas adecuadas. Sin visibilidad centralizada sobre tu stack de PSP, cada una requiere extraer datos de dashboards separados, reconciliar formatos y tomar decisiones con información incompleta. Ahí es donde la mayoría de los equipos pierden tiempo, y donde la mayoría de las brechas de SCA permanecen ocultas por más tiempo.