Autenticación dinámica
Orquestación dinámica de autenticación y verificación con DEUNA
En esta página
- Qué cubre esta guía
- Por qué esto importa
- El enfoque DEUNA
- Arquitectura de referencia
- Controles de autenticación y verificación que DEUNA puede orquestar
- 1. Autenticación EMV 3DS completa
- 2. Patrones 3DS Solo datos/Solo datos compartidos
- 3. Experiencias de autenticación basadas en claves de acceso de Mastercard
- 4. Proveedores de verificación de identidad y biometría
- 5. Orquestación de revisión manual
- 6. Orquestación AVS y gestión AVS estandarizada
- Cómo deberían pensar los arquitectos de soluciones sobre esto
- Ejemplos de patrones de decisión
- Patrón A: Recuperación de rechazos antifraude
- Patrón B: segmentación de confianza del usuario
- Patrón C: estrategia de autenticación consciente de los costos
- Patrón D: revisión manual de transacciones ambiguas
- Patrón E: Política de rechazo universal de AVS en todos los PSP
- Patrón F: autenticación, revisión y decisión AVS combinadas
- Entradas que DEUNA puede utilizar en la lógica de enrutamiento
- Consideraciones de implementación
- 1. Mantenga centralizadas las decisiones
- 2. Separar la puntuación de riesgos de la selección de acciones
- 3. Diseño para la observabilidad
- 4. Evite reglas estáticas y únicas
- 5. Trate los artefactos de autenticación con cuidado
- 6. Trate a AVS como una señal, no como la única fuente de verdad.
Orquestación dinámica de autenticación y verificación con DEUNA
La orquestación de pagos no debe limitarse a elegir un procesador.
En muchas pilas de pagos del mundo real, la decisión más difícil no es sólo donde para enviar una transacción, pero ¿Cuánta autenticación o verificación? debe ser requerido antes de que el pago sea autorizado, reintentado, aprobado o rechazado.
Ahí es donde DEUNA crea influencia.
El motor de enrutamiento de DEUNA se puede extender más allá de la selección del procesador para orquestar Decisiones dinámicas de autenticación y verificación de transacciones. dentro del flujo de pago. Esto permite a los comerciantes reaccionar ante los resultados del fraude, el comportamiento del emisor, los atributos de las transacciones, el contexto del usuario y las señales de respuesta de la puerta de enlace insertando el control correcto solo cuando agrega valor.
El resultado es una arquitectura más adaptable:
- menos falsos positivos
- Menos dependencia de las reglas de rechazo estático.
- mayor protección en las transacciones que realmente la necesitan
- mejor equilibrio entre control del fraude y conversión
- Política de fraude más consistente en todos los PSP y mercados.
Qué cubre esta guía#
Esta página explica cómo se puede utilizar DEUNA para organizar controles de autenticación y verificación como:
- Autenticación EMV 3DS completa
- Patrones 3DS solo datos/solo datos compartidos
- Experiencias de autenticación basadas en claves de acceso de Mastercard
- Proveedores de verificación de identidad y biométrica como la verificación basada en rostro o dispositivo
- Orquestación de revisión manual aprovechar las capacidades de revisión de analistas de proveedores de fraude
- Orquestación AVS estandarizada Normalizar las respuestas de verificación de direcciones de los emisores y aplicar una política de rechazo universal.
Esta no es sólo una función de enrutamiento de pagos. es un arquitectura de toma de decisiones donde la autenticación y la verificación de transacciones se convierten en controles configurables en la estrategia de pago del comerciante.
Por qué esto importa#
Muchos comerciantes todavía operan con un modelo rígido:
- motor de fraude dice aprobar → enviar al procesador
- motor de fraude dice rechazar → rechazar el pago
- la puerta de enlace devuelve una respuesta AVS → cada PSP la expone de manera diferente y el comerciante la maneja de manera inconsistente o la ignora
Ese modelo es simple, pero caro.
Suele producir tres problemas al mismo tiempo:
- Falsos positivos: los clientes legítimos son rechazados porque el conjunto de reglas es demasiado agresivo.
- Fricción innecesaria: todo caso que parezca arriesgado se trata como igualmente peligroso, incluso cuando un paso más ligero podría recuperar el pago de forma segura.
- Controles posteriores a la autorización fragmentados: AVS y señales de respuesta similares varían según la puerta de enlace, lo que dificulta la aplicación de una política de fraude unificada.
DEUNA permite a los comerciantes reemplazar esa decisión binaria con un flujo más matizado:
- aprobar directamente cuando la confianza es alta
- Intensifique una autenticación más sólida cuando la confianza sea baja.
- Utilice rutas más ligeras para compartir datos cuando el comerciante quiera preservar la conversión.
- aplicar verificación biométrica o nativa del dispositivo cuando la certeza de la identidad importa más que el riesgo de la tarjeta por sí solo
- estandarizar los resultados de AVS y decidir si una autorización aún debe aceptarse o denegarse según una política universal
Esto es especialmente valioso para los comerciantes que operan en diferentes geografías, emisores, perfiles de riesgo y segmentos de clientes.
El enfoque DEUNA#
DEUNA permite a los comerciantes tratar la autenticación y la verificación como controles de transacciones conectables.
En lugar de incorporar un comportamiento estático al proceso de pago, los comerciantes pueden definir una lógica de enrutamiento como:
- Si el proveedor antifraude lo aprueba, continúe directamente con la autorización.
- Si el proveedor antifraude lo rechaza, no pierda inmediatamente el pago.
- evaluar el motivo del rechazo, el monto de la transacción, el nivel de confianza del cliente, el comportamiento del emisor, el mercado o el conjunto de reglas comerciales
- invocar dinámicamente el mejor paso de autenticación para ese escenario
- una vez que regrese la respuesta de pago, estandarizar los artefactos de verificación del emisor y de la puerta de enlace, como AVS, y aplicar una política universal
- reingresar la transacción en el flujo de decisión del comerciante con evidencia más sólida o un contexto más rico
Esto convierte a DEUNA en un avión de control para ambos:
- ruta de pago
- enrutamiento de autenticación
- Estandarización de verificación de respuesta y aplicación de políticas.
Esa combinación es poderosa porque mantiene la lógica de toma de decisiones del comerciante centralizada en una capa de orquestación en lugar de dispersarla entre PSP, herramientas antifraude, tablas de códigos AVS específicas de la puerta de enlace y lógica de pago personalizada.
Arquitectura de referencia#
A continuación se muestra una arquitectura conceptual simple.
Interpretación arquitectónica
En este modelo, DEUNA se sitúa entre la creación de la intención de pago y el resultado final del pago.
Puede ingerir señales de múltiples sistemas, evaluar la lógica de enrutamiento y determinar si la transacción debe:
- continuar sin ningún paso adicional
- enriquecerse con datos adicionales
- avanzar hacia una autenticación más sólida del titular de la tarjeta
- pasar por un control adicional de verificación de identidad antes del envío del pago
- ser enviado a una cola de revisión manual del proveedor de fraude cuando una decisión humana es más apropiada que un rechazo automático
- Tener señales de verificación de puerta de enlace, como AVS, normalizadas e interpretadas de manera consistente después de la respuesta de autorización.
Esta es la diferencia arquitectónica clave: la autenticación y la verificación ya no son características aisladas. Se convierten en parte de la orquestación de transacciones.
Controles de autenticación y verificación que DEUNA puede orquestar#
1. Autenticación EMV 3DS completa#
Cuando se requiere una autenticación más sólida, DEUNA puede enrutar la transacción a un flujo EMV 3DS completo antes de la autorización.
Los desencadenantes típicos incluyen:
- rechazo antifraude o puntuación de riesgo severo
- alto valor de transacción
- Comprador primerizo o señales débiles de confianza del cliente.
- cambios sospechosos de dispositivo, velocidad o ubicación
- emisor, BIN o condiciones de mercado asociadas con una mayor presión de fraude
- requisito comercial o regulatorio para una autenticación más sólida del cliente
Cuando usarlo
La 3DS completa suele ser la opción correcta cuando el comerciante quiere una prueba más sólida de la legitimidad del titular de la tarjeta antes de intentar la autorización.
Es especialmente útil cuando el comerciante está dispuesto a introducir alguna fricción a cambio de:
- mayor confianza en la transacción
- mejor control del fraude
- Posibles ventajas en materia de devolución de cargo y responsabilidad según la red y el contexto de la transacción.
Rol de diseño de DEUNA
El papel de DEUNA no se limita a “encender o apagar 3DS”.
Puede utilizar criterios de enrutamiento como:
- umbrales de monto de transacción
- emisor o segmento BIN
- código de decisión antifraude
- antigüedad del cliente o nivel de confianza
- vertical comercial o país
- comportamiento de retroceso después de una caída anterior
Esto permite a los comerciantes utilizar 3DS de forma selectiva en lugar de indiscriminadamente.
2. Patrones 3DS Solo datos/Solo datos compartidos#
No todas las transacciones sospechosas deben incluirse en un flujo 3DS con capacidad de desafío completo.
En algunos casos, el comerciante quiere preservar la conversión y al mismo tiempo ofrecer al emisor un contexto más rico. Ahí es donde Sólo datos o Solo compartir datos Los patrones se vuelven útiles.
¿Qué es?
Este es un camino más ligero donde los datos de transacciones y clientes se comparten a través de rieles o construcciones de programas relacionados con 3DS, pero el comerciante es no realizar la autenticación completa del titular de la tarjeta de la misma manera que un step-up estándar de 3DS.
Cuando usarlo
Esta ruta es útil cuando:
- la cantidad es baja o económicamente tolerante a algún riesgo adicional
- la transacción tiene un riesgo límite y no es claramente fraudulenta
- el comerciante quiere mejorar la toma de decisiones del emisor sin agregar fricciones significativas en el proceso de pago
- El objetivo es preservar la conversión en lugar de forzar un desafío.
- el comerciante está dispuesto a mantener una mayor exposición al fraude a cambio de una experiencia de usuario más ligera
Valor de la arquitectura
Desde la perspectiva de la DEUNA, esto es importante porque agrega una capa intermedia entre:
- aprobar duro
- rechazo duro
Brinda a los comerciantes un camino de recuperación más suave para transacciones que no justifican un desafío completo pero que aún se benefician de un contexto adicional del emisor.
En otras palabras, DEUNA puede dirigir parte del tráfico a:
- autenticación completa
- enriquecimiento ligero
- o ningún paso adelante en absoluto
basado en la estrategia del comerciante.
3. Experiencias de autenticación basadas en claves de acceso de Mastercard#
Las experiencias basadas en claves de acceso de Mastercard representan un modelo de autenticación más nuevo que puede reducir la dependencia de flujos intensivos de OTP y hacer que la seguridad sea más nativa del dispositivo.
Qué significa arquitectónicamente
Para los comerciantes, esto introduce una opción de autenticación adicional que puede ser más adecuada que los patrones de desafío tradicionales en algunos procesos de pago.
En lugar de tratar las claves de acceso como un silo de productos separado, DEUNA puede posicionarlas como otro rama de autenticación conectable dentro de la lógica de enrutamiento donde existe soporte del ecosistema.
Cuando usarlo
Los posibles casos de uso incluyen:
- Transacciones sospechosas en las que el comerciante quiere pruebas más sólidas sin una experiencia OTP tradicional.
- viajes con tarjeta registrada o de usuario recurrente que se benefician de la autenticación nativa del dispositivo
- Escenarios de UX premium en los que minimizar la fricción es importante pero la solidez de la identidad aún debe ser alta
- mercados o programas donde es importante una fuerte alineación de autenticación
Por qué le queda bien a DEUNA
Las claves de acceso son un claro ejemplo de por qué la orquestación de pagos debe evolucionar más allá del cambio de procesador.
Es posible que un comerciante moderno desee decidir dinámicamente:
- si usar 3DS
- si se debe utilizar una ruta de enriquecimiento más ligera
- si se debe utilizar un método de autenticación nativo del dispositivo
- si enviar directamente a la autorización
Esa decisión pertenece naturalmente a un motor de enrutamiento como DEUNA.
4. Proveedores de verificación de identidad y biometría#
Algunos comerciantes necesitan una certeza de identidad más sólida que la que pueden proporcionar los modelos de riesgo de tarjeta por sí solos.
En esos casos, DEUNA puede orquestar proveedores biométricos o de verificación de identidad como controles condicionales dentro del flujo de pago.
Los ejemplos incluyen proveedores que pueden respaldar:
- verificación facial
- controles de vida
- controles de posesión del dispositivo
- coincidencia de identidad con registros de clientes conocidos
Cuando usarlo
Esto es particularmente útil en escenarios como:
- riesgo de adquisición de cuenta
- compras de muy alto valor
- usuarios sospechosos por primera vez
- categorías de productos regulados o sensibles
- Flujos comerciales en los que la persona que realiza la transacción debe estar más fuertemente vinculada a una identidad conocida.
Valor de la arquitectura
No es necesario imponer a estos proveedores en todo el tráfico de pagos.
DEUNA puede utilizarlos de forma selectiva cuando un patrón de transacción justifique un paso de verificación más centrado en la identidad. Esto los hace económica y operativamente viables como parte de una estrategia de decisión escalonada.
5. Orquestación de revisión manual#
No todas las transacciones riesgosas deben rechazarse automáticamente, y no todos los casos límite deben verse obligados a una autenticación más sólida del cliente.
Para algunos comerciantes, el camino correcto es enviar transacciones seleccionadas a un cola de revisión manual impulsado por la plataforma de fraude que ya está en la pila. DEUNA puede tratar esto como otra rama de orquestación en el flujo de decisiones de pago.
Qué significa
En este modelo, DEUNA dirige la transacción a un proveedor de fraude que respalda la revisión de analistas o la gestión de casos. Luego, el proveedor puede colocar el pedido en estado de revisión para que un analista o un equipo de operaciones antifraude pueda tomar la decisión final.
Esto es especialmente relevante para proveedores como:
- colas de revisión de proveedores de fraude respaldadas que devuelven una decisión de revisión a DEUNA
- Acreditar, cuya plataforma y orientación reciente destacan la experiencia humana, la gestión centralizada de casos, la asignación de analistas y las reglas de escalamiento como parte de los flujos de trabajo operativos de revisión de fraude.
Cuando usarlo
La revisión manual suele ser apropiada cuando:
- la transacción es de alto valor o operativamente sensible
- la señal de fraude es más ambigua que claramente fraudulenta
- El cliente es estratégicamente importante y el comerciante quiere evitar una fuerte caída.
- la orden contiene características que un analista de fraude juzga mejor que una regla estática
- El comerciante ya opera un equipo de operaciones de fraude y quiere que DEUNA incluya casos en ese proceso.
Valor de la arquitectura
La revisión manual no es lo mismo que EMV 3DS, claves de acceso o verificación biométrica. Se entiende mejor como un camino de validación humana dentro del mismo modelo de orquestación.
Eso todavía lo hace extremadamente valioso en DEUNA porque el comerciante puede decidir dinámicamente:
- cuando una transacción debe ser aprobada automáticamente
- Cuándo debería avanzar hacia la autenticación del cliente
- cuando debe ir a la verificación de identidad
- y cuándo la mejor siguiente acción es la revisión del analista en lugar de perder el pago
Patrones de orquestación típicos
Los ejemplos incluyen:
- la puntuación antifraude cae en una banda de revisión → enviar a revisión manual en lugar de rechazo inmediato
- usuario nuevo con un valor de pedido inusualmente alto → enviar a la revisión del analista antes de la captura o cumplimiento
- transacción sospechosa pero no concluyente → combine la puntuación ascendente con la revisión manual
- resultado AVS inaceptable en una orden estratégicamente importante → escalar a revisión en lugar de negación general
- Escenario de aerolínea, viajes, emisión de boletos o productos digitales de alto riesgo → permitir que un equipo antifraude aplique un criterio específico para el comerciante
Manejo de resultados
Una vez que el proveedor de fraude devuelve el resultado de la revisión, DEUNA puede encaminar el siguiente paso en consecuencia, por ejemplo:
- aprobar y continuar con la autorización, captura o cumplimiento de acuerdo con el flujo comercial
- rechazar y detener la transacción
- escalar a una ruta de autenticación o verificación de identidad más sólida si el comerciante desea un modelo híbrido
Esta es una razón más por la que DEUNA no es sólo un enrutador de procesador. Se convierte en la capa de coordinación entre los sistemas de fraude automatizados, las operaciones de revisión humana y la ejecución de pagos.
6. Orquestación AVS y gestión AVS estandarizada#
El Servicio de Verificación de Dirección (AVS) es una señal central de control de fraude que verifica si la dirección de facturación enviada por el cliente coincide con la dirección registrada en el banco emisor.
El desafío para los comerciantes no es si AVS es útil. El desafío es que los PSP y los gateways exponen los AVS de manera diferente:
- Cada PSP puede devolver su propio conjunto de códigos AVS sin procesar.
- La semántica de respuesta varía según la puerta de enlace y el adquirente.
- los comerciantes terminan manteniendo asignaciones fragmentadas y reglas de decisión inconsistentes
DEUNA simplifica esto al tratar el AVS como un capa de orquestación estandarizada, no solo un campo específico de la puerta de enlace.
Que hace DEUNA
Cuando las transacciones se procesan a través de PSP compatibles y se devuelven datos AVS, DEUNA puede:
- recuperar la respuesta AVS sin procesar de la PSP o puerta de enlace
- normalizar esa respuesta en una modelo de código único DEUNA AVS
- permita a los comerciantes definir una política universal contra el fraude utilizando códigos DEUNA AVS
- aplicar automáticamente esa política en cada estrategia de pago configurada que reciba datos AVS
Esto les brinda a los comerciantes un lenguaje de control de fraude único y consistente en lugar de mantener una interpretación AVS por proveedor.
Por qué esto es importante arquitectónicamente
AVS no reemplaza a 3DS ni a la verificación de identidad. Juega un papel diferente.
AVS se entiende mejor como un señal de verificación devuelta en la ruta de respuesta de pago que todavía puede afectar materialmente el resultado final de la transacción.
Eso lo hace muy valioso en una arquitectura DEUNA porque los comerciantes pueden combinar:
- controles previos a la autorización, como puntuación de fraude y autenticación intensificada
- controles posteriores a la respuesta, como interpretación AVS estandarizada y reglas de denegación automática
Esto crea una pila de decisiones más completa.
Estandarización de AVS de Deuna
Las distintas puertas de enlace exponen los AVS de forma diferente, lo que dificulta una estrategia de fraude unificada.
DEUNA resuelve esto estandarizando los códigos AVS de proveedores sin procesar en un conjunto común de Códigos AVS DEUNA que sean más fáciles de entender y de poner en práctica.
Esa estandarización permite a los comerciantes crear una política antifraude que se puede reutilizar en múltiples puertas de enlace sin reconstruir la lógica para cada una.
Rechazo automático de transacciones
Uno de los usos más importantes de DEUNA AVS es la capacidad de detener automáticamente transacciones que parecen demasiado riesgosas, incluso cuando la puerta de enlace o el procesador las aceptarían.
Por ejemplo, los comerciantes pueden configurar códigos DEUNA AVS específicos para:
- siempre permitir
- siempre negar
- escalar para acciones posteriores, como revisión, ruta alternativa o verificación adicional
Esto significa que la política del comerciante puede anular la aceptación ciega de la puerta de enlace cuando el resultado del AVS no cumple con la tolerancia al riesgo del comerciante.
Cuando usarlo
La orquestación AVS es especialmente útil cuando los comerciantes quieren:
- aplicar una política antifraude en varios PSP
- Reducir el manejo del código AVS específico de la puerta de enlace dentro del código de la aplicación.
- bloquear las discrepancias de direcciones riesgosas de forma rápida y consistente
- combine la verificación de la dirección de facturación con una estrategia de autenticación y riesgo más amplia
- Mejorar el control del fraude sin forzar una autenticación más sólida en cada transacción.
Posicionamiento de AVS dentro de una estrategia DEUNA
Un patrón sólido es utilizar AVS como capa complementaria junto con la autenticación dinámica.
Por ejemplo:
- transacción de bajo riesgo + buen resultado AVS → aprobar normalmente
- transacción de riesgo moderado + resultado AVS débil → negar o escalar según la política
- rechazo antifraude + el comerciante quiere una ruta de recuperación → avanzar con 3DS antes de la autorización
- autorización aprobada + resultado AVS inaceptable → denegar automáticamente según la política AVS de DEUNA
Aquí es donde DEUNA agrega un valor arquitectónico real: las decisiones de autenticación y la verificación de la respuesta de pago pueden vivir en el mismo modelo de orquestación.
Establecer reglas de denegación automática en DEUNA Admin
Un flujo operativo típico se puede documentar como:
- Inicia sesión en Administrador DEUNA.
- Navegue a Gestión de errores.
- Acceda a Configuración de AVS.
- Seleccione los códigos DEUNA AVS que representen un riesgo inaceptable para su negocio.
- Guarde la configuración.
Una vez configurada, esa política se puede aplicar de manera consistente en todas las transacciones procesadas a través de estrategias admitidas donde los datos AVS están disponibles.
Cómo deberían pensar los arquitectos de soluciones sobre esto#
Una buena implementación no es "agregar más autenticación en todas partes".
Una buena implementación define un escalera de decisiones.
Escalera de decisión recomendada
Nivel 1: autorización directa
Úselo para patrones repetibles, confiables y de bajo riesgo donde la conversión debe ser lo más fluida posible.
Nivel 2: enriquecimiento ligero
Utilice rutas de Solo datos/Solo para compartir datos cuando el contexto del emisor sea útil pero un desafío completo sea demasiado costoso para la conversión.
Nivel 3: autenticación sólida del titular de la tarjeta
Utilice 3DS completo cuando el riesgo aumente materialmente o cuando se requiera una prueba más sólida del titular de la tarjeta.
Nivel 4: Validación humana
Utilice la revisión manual cuando la señal sea ambigua y un analista de fraude pueda tomar una mejor decisión comercial que una regla estática.
Nivel 5: mayor certeza de identidad
Utilice controles biométricos o de verificación de identidad cuando la transacción requiera confianza más allá de los controles estándar de la capa de pago.
Nivel 6: Aplicación de la verificación de respuesta
Utilice la aplicación de políticas AVS estandarizadas para decidir si una autorización aún debe aceptarse, denegarse o escalarse después de que llegue la respuesta de pago.
Este modelo escalonado ayuda a los comerciantes a evitar tres errores de arquitectura comunes:
- abusar de la autenticación fuerte en el tráfico que no lo justifica
- subutilizar las vías de avance recuperables y caer en fuertes caídas
- permitir que la semántica AVS específica de la puerta de enlace fragmente la política de fraude entre proveedores
Ejemplos de patrones de decisión#
Patrón A: Recuperación de rechazos antifraude#
Objetivo: rescatar buenas transacciones que de otro modo serían rechazadas.
Política de ejemplo:
- si el antifraude rechaza y el monto es alto → activar 3DS completo
- si el sistema antifraude lo rechaza y el monto es bajo → intente la ruta Solo datos
- si el antifraude se rechaza y el comerciante tiene una gran confianza del usuario que regresa → pruebe la ruta habilitada con clave de acceso cuando sea compatible
- si los rechazos antifraude y la certeza de la identidad del usuario es fundamental → activar la verificación biométrica
Este es uno de los ejemplos más claros del valor de DEUNA: un rechazo por fraude no tiene por qué ser el final de la transacción.
Patrón B: segmentación de confianza del usuario#
Objetivo: Evite aplicar las mismas reglas a todos los clientes.
Política de ejemplo:
- usuario repetidor de confianza → autorización directa o enriquecimiento ligero únicamente
- usuario repetido con dispositivo o comportamiento geográfico anormal → clave de acceso o 3DS
- usuario primerizo con cesta alta → 3DS completo
- usuario nuevo con compra sensible a la identidad → verificación biométrica
Patrón C: estrategia de autenticación consciente de los costos#
Objetivo: alinear la profundidad de la autenticación con la economía de las transacciones.
Política de ejemplo:
- canasta de bajo valor → preservar la UX, usar enriquecimiento ligero primero
- cesta de valor medio con riesgo moderado → 3DS selectivo
- canasta de alto valor o objetivo de fraude de alto margen → incremento más fuerte por defecto
- orden estratégicamente importante pero ambigua → revisión manual en lugar de rechazo automático
Esto ayuda a los comerciantes a evitar aplicar el costo de una autenticación sólida de manera uniforme en todo el tráfico.
Patrón D: revisión manual de transacciones ambiguas#
Objetivo: Evite caídas innecesarias cuando un analista humano pueda agregar valor.
Política de ejemplo:
- si el proveedor de fraude devuelve la puntuación del rango de revisión → enviar la transacción a revisión manual
- si la primera orden de alto valor tiene señales mixtas → ruta a la cola de analistas
- si la revisión se aprueba → continuar según el flujo de comerciantes
- si la revisión rechaza → rechazar la transacción o bloquear el cumplimiento
Esto es especialmente útil para los comerciantes que ya operan analistas de fraude y quieren que DEUNA organice la transferencia en lugar de tratar la revisión como un sistema completamente separado.
Patrón E: Política de rechazo universal de AVS en todos los PSP#
Objetivo: estandarizar el manejo de riesgos de direcciones de facturación entre proveedores.
Política de ejemplo:
- si la puerta de enlace devuelve el código AVS que DEUNA asigna para que coincida completamente → permitir
- si la puerta de enlace devuelve un código AVS que DEUNA asigna a una discrepancia parcial → evaluar de acuerdo con la política del comerciante
- si la puerta de enlace devuelve un código AVS que DEUNA asigna a una falta de coincidencia de alto riesgo o un patrón no disponible que el comerciante ha bloqueado → rechazar automáticamente
- si el comerciante quiere un manejo más suave para algunos segmentos → escalar a revisión o acción posterior en lugar de una denegación general
Esto permite al comerciante administrar una política AVS en todas las pasarelas de pago en lugar de crear una tabla de códigos por integración.
Patrón F: autenticación, revisión y decisión AVS combinadas#
Objetivo: utilizar diferentes controles en diferentes momentos del flujo de transacciones.
Política de ejemplo:
- rechazo antifraude antes de la autorización → recuperar con 3DS
- autorización exitosa con resultado AVS inaceptable → negar respuesta posterior según política DEUNA
- usuario recurrente confiable con un historial sólido y AVS aceptable → aprobar con mínima fricción
- usuario nuevo con coincidencia de dirección débil y canasta alta → postura de avance más fuerte o postura de negación más estricta
Este patrón demuestra que la mejor estrategia de fraude a menudo no es un control, sino varios controles coordinados bajo una capa de orquestación.
Entradas que DEUNA puede utilizar en la lógica de enrutamiento#
Una implementación sólida generalmente combina múltiples entradas en lugar de depender de una sola puntuación de riesgo.
Las entradas típicas incluyen:
- decisión antifraude, puntuación o motivo de rechazo
- Historial del cliente y nivel de confianza.
- monto del pago y perfil de la cesta
- tipo de producto o sensibilidad al fraude del pedido
- BIN, emisor, tipo de tarjeta o país
- anomalías del dispositivo o de la sesión
- patrones de velocidad
- políticas verticales comerciales
- requisitos específicos de la geografía
- resultados históricos de aprobación o fraude por segmento
- Resultados AVS devueltos por PSP o puertas de enlace compatibles
- Bandas de revisión de proveedores fraudulentos, colas o resultados de revisión manual
Esto permite a DEUNA actuar como un motor de decisión centralizado en lugar de codificar la lógica dentro de la integración de cada proveedor.
Consideraciones de implementación#
1. Mantenga centralizadas las decisiones#
La política de autenticación y verificación debe residir en la capa de orquestación, no estar fragmentada en el código de interfaz, la configuración de PSP y las herramientas de fraude de forma independiente.
2. Separar la puntuación de riesgos de la selección de acciones#
Una puntuación de fraude por sí sola no define la mejor acción.
La capa de orquestación debe traducir las señales de riesgo en la acción correcta para esa transacción, como por ejemplo:
- aprobar
- enriquecer
- intensificar
- verificar identidad
- aplicar denegación o escalada basada en AVS
- ruta a la revisión manual
- reintentar o retroceder
3. Diseño para la observabilidad#
Los comerciantes deben medir el desempeño de cada sucursal, incluyendo:
- tasa de recuperación de transacciones previamente rechazadas
- aumento de autorización por ruta de autenticación
- tasa de fraude por ruta
- tasa de desafío y tasa de abandono cuando corresponda
- impacto de la conversión por segmento de usuarios
- Tasa de desajuste de AVS por PSP y segmento
- tasa de denegación impulsada por la política AVS estandarizada
- economía de costo de recuperación
4. Evite reglas estáticas y únicas#
Una regla que funciona bien para los usuarios primerizos de alto valor puede ser perjudicial para los clientes habituales de bajo valor.
DEUNA es más eficaz cuando los comerciantes segmentan la estrategia por riesgo y contexto empresarial.
5. Trate los artefactos de autenticación con cuidado#
Cuando 3DS es parte del flujo, las implementaciones deben manejar los datos de autenticación según las reglas actuales de red de tarjetas, proveedores de pagos y cumplimiento. No dependa del almacenamiento a largo plazo de valores de autenticación criptográfica como CAVV o AAV. DEUNA pasa el resultado de autenticación requerido al flujo de autorización admitido; Los registros y análisis de los comerciantes no deben conservar criptogramas sin procesar.
6. Trate a AVS como una señal, no como la única fuente de verdad.#
AVS es valioso, pero no debe interpretarse de forma aislada.
Las mejores implementaciones evalúan AVS junto con:
- historial de usuario
- valor de transacción
- puntuación antifraude
- comportamiento del dispositivo
- patrones de fraude específicos del mercado
Esta es exactamente la razón por la que AVS pertenece dentro de un modelo de orquestación en lugar de ser una regla de puerta de enlace codificada e independiente.