¿Por qué 3DS sigue fracasando en LATAM y qué hace el enrutamiento inteligente al respecto?

Si tu equipo lleva meses depurando fallas de autenticación 3DS en mercados latinoamericanos, es posible que esté resolviendo el problema equivocado. Las tasas de rechazo elevadas, el alto abandono en el paso de autenticación y el rendimiento inconsistente de aprobaciones entre países rara vez tienen su origen en una capa de autenticación defectuosa. Su origen está en el destino al que se envían las transacciones y en la capa de enrutamiento que toma esa decisión.

Esta página explica por qué 3DS se comporta de manera diferente en América Latina, por qué tratarlo como un problema de cumplimiento normativo es un error de diagnóstico, y cómo la orquestación de pagos le da a los equipos de pagos la inteligencia de enrutamiento necesaria para recuperar ese revenue antes de que desaparezca.

‍

¿Por qué la autenticación 3DS falla con más frecuencia en América Latina que en otras regiones?

3D Secure fue diseñado para trasladar la responsabilidad por fraude y agregar una capa de autenticación adicional en transacciones sin presencia de tarjeta. En teoría, funciona en cualquier mercado. En la práctica, su tasa de éxito depende en gran medida de la infraestructura técnica del banco emisor y en América Latina esa infraestructura es profundamente desigual.

Muchos emisores en Brasil, México, Colombia y Argentina tienen una implementación 3DS inconsistente. Algunos tienen servidores ACS (Access Control Servers) mal configurados, altas tasas de falsos positivos en su scoring de fraude, o fallas en la entrega de OTP cuando las redes móviles no son confiables. Otros no han completado la migración a 3DS2, lo que significa que las transacciones siguen activando flujos 3DS1 con alta fricción. El resultado: un cliente legítimo intenta realizar una transacción real, el desafío falla o se agota el tiempo, y la transacción es rechazada. El cliente abandona. El equipo de pagos ve un evento de rechazo y asume que la autenticación falló. Pero la causa más profunda es que la transacción fue enrutada hacia un PSP cuya trayectoria 3DS pasa por ese emisor débil.

El fallo no está en la capa de autenticación. Está más arriba, en la decisión de enrutamiento que determinó qué PSP manejaría esa transacción.

‍

¿Cómo se ve un problema de enrutamiento cuando se confunde con un problema de 3DS?

El error de diagnóstico más común es hacer pattern-matching sobre la señal de fallo en lugar de sobre su origen. Un Head of Payments detecta tasas elevadas de step-up 3DS para un rango de BIN específico en Brasil, lo interpreta como un problema de configuración de autenticación y pasa semanas trabajando con el equipo técnico del PSP para ajustar los parámetros de autenticación. La tasa de aprobación mejora marginalmente y luego revierte.

El problema es que el rango de BIN en cuestión pertenece a un emisor doméstico que tiene una alta tasa de desafío cuando las transacciones fluyen a través de un adquirente específico, pero una tasa significativamente menor cuando se enrutan a través de un adquirente local diferente o cuando 3DS se omite mediante network tokenization. La capa de enrutamiento nunca consideró esto. Envió todas las transacciones al mismo PSP independientemente del origen del BIN, porque las reglas de enrutamiento estaban configuradas por país, no por rendimiento del emisor.

Este es el vacío diagnóstico central: la lógica de enrutamiento tradicional es demasiado gruesa para diferenciar el rendimiento a nivel de la interacción emisor-PSP. Las plataformas de orquestación de pagos que realizan 3DS authentication orchestration enrutan en la intersección de BIN, adquirente, método de pago y datos de rendimiento en tiempo real, no solo por geografía.

‍

¿Cómo reduce el enrutamiento inteligente las fallas 3DS antes de que ocurran?

El enrutamiento inteligente en una capa de orquestación de pagos interviene antes de que la transacción llegue a un muro de autenticación. El motor de orquestación evalúa varias señales en tiempo real: el rango de BIN de la tarjeta y su tasa histórica de desafío 3DS con diferentes adquirentes, si la transacción califica para una exención 3DS (como exenciones por bajo valor bajo marcos regulatorios locales o exenciones por análisis de riesgo de transacción), y si la network tokenization permitiría omitir el desafío por completo mediante una credencial de pago confiable.

Cuando el motor de enrutamiento detecta que un BIN específico tiene alta probabilidad de activar un desafío 3DS fallido a través del Adquirente A, puede redirigir la transacción al Adquirente B, donde ese BIN tiene un perfil de aprobación mediblemente mejor, antes de que se active ningún desafío. Alternativamente, si la transacción cumple los criterios para una solicitud de exención 3DS, la capa de enrutamiento aplica esa exención automáticamente y enruta hacia un adquirente que la soporte.

El resultado es que la mayoría de los clientes nunca ven una pantalla de desafío en los caminos de alta fricción. Quienes sí la ven son atendidos a través de un PSP cuya integración 3DS con su emisor específico tiene buen historial de rendimiento.

‍

¿Puede un equipo de pagos identificar qué transacciones están fallando en el paso 3DS específicamente por enrutamiento y no por configuración de autenticación?

Sí, y aquí es donde el análisis en la capa de orquestación se vuelve esencial. La mayoría de los dashboards a nivel de PSP muestran razones de rechazo agregadas: "falla de autenticación", "no honrar", "tarjeta bloqueada". No exponen la señal a nivel de interacción que revelaría una causa de enrutamiento.

Una plataforma de orquestación con analítica unificada puede segmentar los motivos de rechazo por PSP, rango de BIN, método de autenticación y estado de exención de forma simultánea. Si un equipo de pagos ve que las fallas 3DS para un cluster de BIN específico se concentran en un adquirente pero están ausentes en otro, el diagnóstico es claro: es un problema de enrutamiento, no de autenticación. La solución es un cambio en la regla de enrutamiento, ejecutable en minutos, no un proyecto de integración de semanas con el equipo de autenticación del PSP.

‍

¿Este problema es específico de algún país de América Latina o es regional?

El problema es regional pero con distribución desigual. Brasil tiene el mayor volumen de problemas de enrutamiento relacionados con 3DS porque su mercado doméstico de tarjetas (dominado por Elo y BINs domésticos de Visa/Mastercard) tiene una variabilidad significativa entre emisores en la calidad de implementación 3DS. El ecosistema PIX, por el contrario, omite 3DS por completo, lo que es una razón más por la que los equipos de pagos que operan en Brasil deberían estar enrutando una mayor proporción de transacciones elegibles a través de los rieles de PIX en lugar de flujos 3DS basados en tarjeta.

México experimenta alta fricción 3DS en transacciones enrutadas a través de adquirentes internacionales cuando hay emisores domésticos involucrados. Colombia y Argentina tienen patrones similares, con complejidad adicional por restricciones cambiarias y requisitos de autenticación regulatorios locales que interactúan de forma impredecible con los flujos 3DS estándar.

En todos los casos, la resolución sigue la misma lógica: enrutar a nivel de la interacción emisor-adquirente, aplicar exenciones donde estén disponibles y usar tokenización para reducir la frecuencia de activación de desafíos. Esto requiere una capa de orquestación, no cambios en la capa de autenticación.