Autenticação dinâmica e orquestração de verificação com DEUNA

A orquestração de pagamentos não deve se limitar à escolha de um processador.

Em muitas pilhas de pagamentos do mundo real, a decisão mais difícil não é apenas onde para enviar uma transação, mas quanto de autenticação ou verificação deve ser exigido antes que o pagamento seja autorizado, repetido, aprovado ou recusado.

É aí que a DEUNA cria alavancagem.

O mecanismo de roteamento da DEUNA pode ser estendido além da seleção do processador para orquestrar decisões de autenticação dinâmica e verificação de transações dentro do fluxo de pagamento. Isso permite que os comerciantes reajam aos resultados da fraude, ao comportamento do emissor, aos atributos da transação, ao contexto do usuário e aos sinais de resposta do gateway, inserindo o controle correto somente quando ele agrega valor.

O resultado é uma arquitetura mais adaptativa:

• menos falsos positivos
• menos dependência de regras de rejeição estática
• proteção mais forte nas transações que realmente precisam dela
• melhor equilíbrio entre controle de fraude e conversão
• política antifraude mais consistente em PSPs e mercados

O que este guia cobre#

Esta página explica como o DEUNA pode ser usado para orquestrar controles de autenticação e verificação, como:

• Autenticação EMV 3DS completa
• Padrões 3DS somente dados/somente compartilhamento de dados
• Experiências de autenticação baseadas em senha Mastercard
• Provedores de biometria e verificação de identidade como verificação baseada em rosto ou dispositivo
• Orquestração de revisão manual aproveitando os recursos de análise de analistas de provedores de fraude
• Orquestração AVS padronizada normalizar as respostas de verificação de endereço do emissor e aplicar uma política de rejeição universal

Este não é apenas um recurso de roteamento de pagamento. É um arquitetura de decisão onde a autenticação e a verificação da transação se tornam controles configuráveis na estratégia de pagamento do comerciante.

---

Por que isso é importante#

Muitos comerciantes ainda operam com um modelo rígido:

• mecanismo de fraude diz aprovar → enviar para o processador
• mecanismo de fraude diz rejeitar → recusar o pagamento
• gateway retorna uma resposta AVS → cada PSP expõe isso de maneira diferente e o comerciante lida com isso de forma inconsistente ou ignora

Esse modelo é simples, mas caro.

Tende a produzir três problemas ao mesmo tempo:

1. Falsos positivos: clientes legítimos são rejeitados porque o conjunto de regras é muito agressivo.
2. Fricção desnecessária: todos os casos que parecem arriscados são tratados como igualmente perigosos, mesmo quando um passo mais leve poderia recuperar o pagamento com segurança.
3. Controles pós-autorização fragmentados: AVS e sinais de resposta semelhantes variam de acordo com o gateway, dificultando a aplicação de uma política unificada de fraude.

DEUNA permite que os comerciantes substituam essa decisão binária por um fluxo mais matizado:

• aprovar diretamente quando a confiança for alta
• avance com uma autenticação mais forte quando a confiança estiver baixa
• use caminhos mais leves de compartilhamento de dados quando o comerciante quiser preservar a conversão
• aplicar verificação biométrica ou nativa do dispositivo quando a certeza da identidade for mais importante do que apenas o risco do cartão
• padronizar os resultados do AVS e decidir se uma autorização ainda deve ser aceita ou negada com base em uma política universal

Isto é especialmente valioso para comerciantes que operam em diferentes geografias, emissores, perfis de risco e segmentos de clientes.

---

A abordagem DEUNA#

A DEUNA permite que os comerciantes tratem a autenticação e a verificação como controles de transação conectáveis.

Em vez de conectar um comportamento estático ao checkout, os comerciantes podem definir uma lógica de roteamento como:

• se o provedor antifraude aprovar, prossiga diretamente para a autorização
• se o provedor antifraude rejeitar, não perca imediatamente o pagamento
• avaliar o motivo da rejeição, valor da transação, nível de confiança do cliente, comportamento do emissor, mercado ou conjunto de regras do comerciante
• invocar dinamicamente a melhor etapa de autenticação para esse cenário
• assim que a resposta de pagamento retornar, padronize os artefatos de verificação do emissor e do gateway, como AVS, e aplique uma política universal
• reinserir a transação no fluxo de decisão do comerciante com evidências mais fortes ou contexto mais rico

Isto transforma a DEUNA num plano de controle para ambos:

• roteamento de pagamento
• roteamento de autenticação
• padronização de verificação de resposta e aplicação de políticas

Essa combinação é poderosa porque mantém a lógica de decisão do comerciante centralizada em uma camada de orquestração, em vez de espalhá-la por PSPs, ferramentas antifraude, tabelas de códigos AVS específicas de gateway e lógica de checkout personalizada.

---

Arquitetura de referência#

Abaixo está uma arquitetura conceitual simples.

DEUNADiagrama de fluxoAmpliar

Interpretação arquitetônica

Neste modelo, a DEUNA fica entre a criação da intenção de checkout e o resultado final do pagamento.

Ele pode ingerir sinais de vários sistemas, avaliar a lógica de roteamento e determinar se a transação deve:

• continuar sem nenhuma etapa adicional
• ser enriquecido com dados adicionais
• ser intensificado para uma autenticação mais forte do titular do cartão
• ser encaminhado através de um controle adicional de verificação de identidade antes do envio do pagamento
• ser encaminhado para uma fila de revisão manual do provedor de fraude quando uma decisão humana for mais apropriada do que uma recusa automática
• ter sinais de verificação de gateway, como AVS, normalizados e interpretados consistentemente após a resposta de autorização

Esta é a principal diferença arquitetônica: autenticação e verificação não são mais recursos isolados. Eles se tornam parte da orquestração de transações.

---

Controles de autenticação e verificação que a DEUNA pode orquestrar#

1. Autenticação EMV 3DS completa#

Quando uma autenticação mais forte é necessária, a DEUNA pode encaminhar a transação para um fluxo EMV 3DS completo antes da autorização.

Os gatilhos típicos incluem:

• rejeição antifraude ou pontuação de risco grave
• alto valor de transação
• comprador pela primeira vez ou sinais fracos de confiança do cliente
• alterações suspeitas de dispositivo, velocidade ou localização
• condições do emissor, BIN ou mercado associadas a maior pressão de fraude
• requisito comercial ou regulatório para autenticação mais forte do cliente

Quando usar

Full 3DS normalmente é a escolha certa quando o comerciante deseja um prova mais forte da legitimidade do titular do cartão antes de tentar a autorização.

É especialmente útil quando o comerciante está disposto a introduzir algum atrito em troca de:

• maior confiança na transação
• melhor controle de fraude
• potenciais vantagens de estorno e responsabilidade, dependendo da rede e do contexto da transação

Função de design DEUNA

O papel da DEUNA não se limita a “3DS ligado ou desligado”.

Ele pode usar critérios de roteamento como:

• limites de valor da transação
• emissor ou segmento BIN
• código de decisão antifraude
• posse do cliente ou nível de confiança
• indústria ou país do comerciante
• comportamento de fallback após um declínio anterior

Isso permite que os comerciantes apliquem o 3DS seletivamente, em vez de indiscriminadamente.

---

2. Padrões 3DS Somente Dados / Somente Compartilhamento de Dados#

Nem toda transação suspeita deve ser inserida em um fluxo 3DS totalmente compatível com desafios.

Em alguns casos, o comerciante deseja preservar a conversão e ao mesmo tempo fornecer ao emissor um contexto mais rico. É aí que Somente dados ou Somente compartilhamento de dados padrões se tornam úteis.

O que é isso

Este é um caminho mais leve, onde os dados de transações e clientes são compartilhados por meio de trilhos ou construções de programas relacionados ao 3DS, mas o comerciante é não realizar autenticação completa do titular do cartão da mesma forma que um step-up 3DS padrão.

Quando usar

Este caminho é útil quando:

• o valor é baixo ou economicamente tolerante a algum risco adicional
• a transação é quase arriscada e não é claramente fraudulenta
• o comerciante deseja melhorar a tomada de decisão do emissor sem adicionar atrito significativo no checkout
• o objetivo é preservar a conversão em vez de forçar um desafio
• o comerciante está disposto a reter mais exposição a fraudes em troca de uma experiência de usuário mais leve

Valor da arquitetura

Do ponto de vista da DEUNA, isto é importante porque adiciona uma camada intermediária entre:

• difícil aprovar
• rejeição difícil

Oferece aos comerciantes um caminho de recuperação mais suave para transações que não justificam um desafio total, mas que ainda beneficiam de um contexto adicional do emitente.

Por outras palavras, DEUNA pode encaminhar algum tráfego para:

• autenticação completa
• enriquecimento leve
• ou nenhum avanço

com base na estratégia do comerciante.

---

3. Experiências de autenticação baseadas em senha Mastercard#

As experiências baseadas em senha da Mastercard representam um modelo de autenticação mais recente que pode reduzir a dependência de fluxos pesados de OTP e tornar a segurança mais nativa do dispositivo.

O que significa arquitetonicamente

Para os comerciantes, isto introduz uma opção de autenticação adicional que pode ser mais adequada do que os padrões de desafio tradicionais em algumas jornadas de checkout.

Em vez de tratar as chaves de acesso como um silo de produtos separado, a DEUNA pode posicioná-las como outro ramificação de autenticação conectável dentro da lógica de roteamento onde existe suporte ao ecossistema.

Quando usar

Os possíveis casos de uso incluem:

• transações suspeitas em que o comerciante deseja uma prova mais forte sem uma experiência OTP tradicional
• jornadas de cartão registrado ou de usuário recorrente que se beneficiam da autenticação nativa do dispositivo
• cenários de UX premium onde minimizar o atrito é importante, mas a força da identidade ainda precisa ser alta
• mercados ou programas onde o forte alinhamento de autenticação é importante

Por que cabe bem no DEUNA

As chaves de acesso são um forte exemplo de por que a orquestração de pagamentos deve evoluir além da troca de processador.

Um comerciante moderno pode querer decidir de forma dinâmica:

• se deve usar 3DS
• se deve usar um caminho de enriquecimento mais leve
• se deve usar um método de autenticação nativo do dispositivo
• se deve enviar diretamente para autorização

Essa decisão pertence naturalmente a um mecanismo de roteamento como o DEUNA.

---

4. Provedores de biometria e verificação de identidade#

Alguns comerciantes precisam de uma certeza de identidade mais forte do que os modelos de risco de cartão por si só podem fornecer.

Nesses casos, a DEUNA pode orquestrar provedores biométricos ou de verificação de identidade como controles condicionais dentro do fluxo de pagamento.

Os exemplos incluem provedores que podem oferecer suporte:

• verificação facial
• verificações de atividade
• verificações de posse de dispositivo
• correspondência de identidade com registros de clientes conhecidos

Quando usar

Isso é particularmente útil em cenários como:

• risco de aquisição de conta
• compras de valor muito alto
• usuários iniciantes suspeitos
• categorias de produtos regulamentados ou sensíveis
• fluxos comerciais em que a pessoa que realiza a transação deve estar mais fortemente ligada a uma identidade conhecida

Valor da arquitetura

Esses provedores não precisam ser forçados a passar por todo o tráfego de pagamento.

A DEUNA pode usá-los seletivamente quando um padrão de transação justificar uma etapa de verificação mais centrada na identidade. Isto torna-os económica e operacionalmente viáveis ​​como parte de uma estratégia de decisão escalonada.

---

5. Orquestração de revisão manual#

Nem todas as transações arriscadas devem ser automaticamente negadas e nem todos os casos limítrofes devem ser forçados a uma autenticação mais forte do cliente.

Para alguns comerciantes, o caminho certo é enviar as transações selecionadas para um fila de revisão manual alimentado pela plataforma de fraude já existente. A DEUNA pode tratar isso como outro ramo de orquestração no fluxo de decisão de pagamento.

O que isso significa

Neste modelo, a DEUNA encaminha a transação para um provedor de fraude que oferece suporte à revisão do analista ou ao gerenciamento de casos. O fornecedor pode então colocar o pedido em estado de revisão para que um analista ou equipe de operações antifraude possa tomar a decisão final.

Isto é especialmente relevante para fornecedores como:

• filas de revisão de provedores de fraude suportados que retornam uma decisão de revisão à DEUNA
• Certificar, cuja plataforma e orientação recente destacam a experiência humana, o gerenciamento centralizado de casos, a atribuição de analistas e as regras de escalonamento como parte dos fluxos de trabalho operacionais de análise de fraudes

Quando usar

A revisão manual costuma ser apropriada quando:

• a transação é de alto valor ou operacionalmente sensível
• o sinal de fraude é ambíguo e não claramente fraudulento
• o cliente é estrategicamente importante e o comerciante deseja evitar um forte declínio
• o pedido contém características que são melhor avaliadas por um analista de fraude do que por uma regra estática
• o comerciante já opera uma equipe de operações antifraude e deseja que a DEUNA inclua casos nesse processo

Valor da arquitetura

A revisão manual não é a mesma coisa que EMV 3DS, chaves de acesso ou verificação biométrica. É melhor compreendido como um caminho de validação humana dentro do mesmo modelo de orquestração.

Isso ainda o torna extremamente valioso na DEUNA porque o comerciante pode decidir dinamicamente:

• quando uma transação deve ser aprovada automaticamente
• quando deve avançar para a autenticação do cliente
• quando deveria ir para verificação de identidade
• e quando a melhor próxima ação for a revisão do analista em vez de perder o pagamento

Padrões típicos de orquestração

Os exemplos incluem:

• a pontuação antifraude cai em uma faixa de revisão → enviar para revisão manual em vez de recusa imediata
• usuário iniciante com valor de pedido excepcionalmente alto → enviar para análise do analista antes da captura ou atendimento
• transação suspeita, mas não conclusiva → combinar pontuação upstream com revisão manual
• resultado inaceitável do AVS em um pedido estrategicamente importante → escalar para revisão em vez de negação geral
• Cenário de alto risco de companhia aérea, viagens, emissão de passagens ou produtos digitais → permitir que uma equipe de fraude aplique julgamento específico do comerciante

Tratamento de resultados

Assim que o fornecedor de fraude devolver um resultado de revisão, a DEUNA pode encaminhar o próximo passo em conformidade, por exemplo:

• aprovar e continuar a autorização, captura ou atendimento de acordo com o fluxo do comerciante
• rejeitar e pare a transação
• escalar para um caminho de autenticação ou verificação de identidade mais forte se o comerciante quiser um modelo híbrido

Esta é mais uma razão pela qual DEUNA não é apenas um roteador de processador. Torna-se a camada de coordenação entre sistemas automatizados de fraude, operações de revisão humana e execução de pagamentos.

---

6. Orquestração AVS e gerenciamento AVS padronizado#

O Serviço de Verificação de Endereço (AVS) é um sinal central de controle de fraude que verifica se o endereço de cobrança enviado pelo cliente corresponde ao endereço registrado no banco emissor.

O desafio para os comerciantes não é se o AVS é útil. O desafio é que os PSPs e gateways expõem o AVS de forma diferente:

• cada PSP pode retornar seu próprio conjunto de códigos AVS brutos
• a semântica da resposta varia de acordo com o gateway e o adquirente
• os comerciantes acabam mantendo mapeamentos fragmentados e regras de decisão inconsistentes

A DEUNA simplifica isso tratando o AVS como um camada de orquestração padronizada, não apenas um campo específico do gateway.

O que DEUNA faz

Quando as transações são processadas através de PSPs suportados e os dados AVS são devolvidos, a DEUNA pode:

• recuperar a resposta AVS bruta do PSP ou gateway
• normalizar essa resposta em um modelo de código DEUNA AVS único
• permitir que os comerciantes definam uma política universal de fraude usando códigos DEUNA AVS
• aplicar automaticamente essa política em todas as estratégias de pagamento configuradas que recebem dados AVS

Isso dá aos comerciantes uma linguagem única e consistente de controle de fraudes, em vez de manter uma interpretação AVS por fornecedor.

Por que isso é importante arquitetonicamente

AVS não substitui o 3DS ou a verificação de identidade. Desempenha um papel diferente.

AVS é melhor entendido como um sinal de verificação retornado no caminho de resposta de pagamento que ainda pode afetar materialmente o resultado final da transação.

Isso o torna altamente valioso em uma arquitetura DEUNA porque os comerciantes podem combinar:

• controles de pré-autorização, como pontuação de fraude e autenticação intensificada
• controles pós-resposta, como interpretação AVS padronizada e regras de negação automática

Isso cria uma pilha de decisões mais completa.

Padronização DEUNA AVS

Diferentes gateways expõem o AVS de maneira diferente, o que dificulta uma estratégia unificada de fraude.

A DEUNA resolve isso padronizando os códigos AVS brutos do fornecedor em um conjunto comum de Códigos DEUNA AVS que são mais fáceis de entender e mais fáceis de operacionalizar.

Essa padronização permite que os comerciantes criem uma política de fraude que pode ser reutilizada em vários gateways sem reconstruir a lógica de cada um deles.

Negação automática de transação

Um dos usos mais fortes do DEUNA AVS é a capacidade de interromper automaticamente transações que parecem muito arriscadas, mesmo quando o gateway ou processador as aceitaria.

Por exemplo, os comerciantes podem configurar códigos DEUNA AVS específicos para:

• sempre permita
• sempre nego
• escalar para ação posterior, como revisão, roteamento alternativo ou verificação adicional

Isso significa que a política do comerciante pode substituir a aceitação do gateway cego quando o resultado do AVS não atender à tolerância de risco do comerciante.

Quando usar

A orquestração AVS é especialmente útil quando os comerciantes desejam:

• aplicar uma política de fraude em vários PSPs
• reduza o manuseio de código AVS específico do gateway dentro do código do aplicativo
• bloqueie incompatibilidades de endereços arriscadas de forma rápida e consistente
• combinar verificação de endereço de cobrança com estratégia mais ampla de risco e autenticação
• melhorar o controle de fraudes sem forçar uma autenticação mais forte em todas as transações

Posicionando AVS dentro de uma estratégia DEUNA

Um padrão forte é usar AVS como camada complementar junto com a autenticação dinâmica.

Por exemplo:

• transação de baixo risco + bom resultado AVS → aprovar normalmente
• transação de risco moderado + resultado AVS fraco → negar ou escalar de acordo com a política
• rejeição antifraude + comerciante quer caminho de recuperação → avançar com 3DS antes da autorização
• autorização aprovada + resultado AVS inaceitável → negar automaticamente com base na política DEUNA AVS

É aqui que a DEUNA acrescenta valor arquitetónico real: as decisões de autenticação e a verificação da resposta ao pagamento podem viver no mesmo modelo de orquestração.

Defina regras de negação automática no DEUNA Admin

Um fluxo operacional típico pode ser documentado como:

1. Faça login em Administrador DEUNA.
2. Navegue até Gerenciamento de erros.
3. Abra Configurações AVS.
4. Selecione os códigos DEUNA AVS que representam riscos inaceitáveis para o seu negócio.
5. Salve a configuração.

Uma vez configurada, essa política pode ser aplicada de forma consistente em transações processadas por meio de estratégias suportadas onde os dados AVS estão disponíveis.

---

Como os arquitetos de soluções devem pensar sobre isso#

Uma boa implementação não é “adicionar mais autenticação em todos os lugares”.

Uma boa implementação define um escada de decisão.

Escada de decisão recomendada

Nível 1 — Autorização direta
Use para padrões repetíveis, confiáveis e de baixo risco, onde a conversão deve permanecer o mais simples possível.

Nível 2 — Enriquecimento leve
Use caminhos somente dados/somente compartilhamento de dados quando o contexto do emissor for útil, mas um desafio completo for muito caro para conversão.

Nível 3 — Autenticação forte do titular do cartão
Use o 3DS completo quando o risco aumentar materialmente ou quando for necessária uma prova mais forte do titular do cartão.

Nível 4 – Validação humana
Use a revisão manual quando o sinal for ambíguo e um analista de fraude puder tomar uma decisão de negócios melhor do que uma regra estática.

Nível 5 – Maior certeza de identidade
Use controles biométricos ou de verificação de identidade quando a transação exigir confiança além das verificações padrão da camada de pagamento.

Nível 6 – Aplicação de verificação de resposta
Use a aplicação padronizada da política AVS para decidir se uma autorização ainda deve ser aceita, negada ou escalada após o retorno da resposta de pagamento.

Este modelo em camadas ajuda os comerciantes a evitar três erros comuns de arquitetura:

• uso excessivo de autenticação forte em tráfego que não justifica isso
• subutilização de caminhos de aumento recuperáveis e inadimplência em quedas bruscas
• permitir que a semântica AVS específica do gateway fragmente a política de fraude entre provedores

---

Exemplos de padrões de decisão#

Padrão A — Recuperando rejeições antifraude#

Objetivo: resgatar boas transações que de outra forma seriam recusadas.

Exemplo de política:

• se o antifraude rejeitar e o valor for alto → acionar o 3DS completo
• se o antifraude for rejeitado e o valor for baixo → tente o caminho somente dados
• se o antifraude for rejeitado e o comerciante tiver forte confiança no retorno do usuário → tente o caminho habilitado para chave de acesso, quando compatível
• se as rejeições antifraude e a certeza da identidade do usuário forem críticas → acionar a verificação biométrica

Este é um dos exemplos mais claros do valor da DEUNA: uma rejeição de fraude não tem de ser o fim da transação.

Padrão B — Segmentação de confiança do usuário#

Objetivo: evite aplicar as mesmas regras a todos os clientes.

Exemplo de política:

• usuário repetido confiável → autorização direta ou enriquecimento leve apenas
• usuário repetido com dispositivo anormal ou comportamento geográfico → senha ou 3DS
• usuário iniciante com cesta alta → 3DS completo
• usuário iniciante com compra sensível à identidade → verificação biométrica

Padrão C — Estratégia de autenticação consciente de custos#

Objetivo: alinhe a profundidade da autenticação com a economia da transação.

Exemplo de política:

• cesta de baixo valor → preserve a UX, use primeiro o enriquecimento de luz
• cesta de valor médio com risco moderado → 3DS seletivo
• cesta de alto valor ou alvo de fraude de alta margem → avanço mais forte por padrão
• ordem estrategicamente importante, mas ambígua → revisão manual em vez de rejeição automática

Isso ajuda os comerciantes a evitar a aplicação uniforme do custo da autenticação forte em todo o tráfego.

Padrão D — Revisão manual para transações ambíguas#

Objetivo: evite quedas desnecessárias quando um analista humano puder agregar valor.

Exemplo de política:

• se o provedor de fraude retornar a pontuação do intervalo de revisão → enviar a transação para revisão manual
• se o pedido inicial de alto valor tiver sinais mistos → rotear para a fila do analista
• se a revisão for aprovada → continuar de acordo com o fluxo do comerciante
• se a revisão for rejeitada → negar transação ou bloquear cumprimento

Isto é especialmente útil para comerciantes que já operam analistas de fraude e desejam que a DEUNA orquestre a transferência em vez de tratar a revisão como um sistema totalmente separado.

Padrão E – Política universal de rejeição de AVS em PSPs#

Objetivo: padronizar o tratamento de risco de endereço de cobrança entre provedores.

Exemplo de política:

• se o gateway retornar o código AVS que o DEUNA mapeia para correspondência completa → permitir
• se o gateway retornar o código AVS que a DEUNA mapeia como incompatibilidade parcial → avaliar de acordo com a política do comerciante
• se o gateway retornar o código AVS que a DEUNA mapeia para incompatibilidade de alto risco ou padrão indisponível que o comerciante bloqueou → negar automaticamente
• se o comerciante quiser um tratamento mais suave para alguns segmentos → escalar para revisão ou ação posterior em vez de negação geral

Isso permite que o comerciante gerencie uma política AVS em gateways de pagamento, em vez de construir uma tabela de códigos por integração.

Padrão F — Autenticação combinada, revisão e decisão AVS#

Objetivo: use controles diferentes em momentos diferentes do fluxo da transação.

Exemplo de política:

• rejeição antifraude antes da autorização → recuperar com 3DS
• autorização bem-sucedida com resultado AVS inaceitável → negar pós-resposta de acordo com a política da DEUNA
• usuário recorrente confiável com histórico forte e AVS aceitável → aprova com mínimo atrito
• usuário iniciante com correspondência de endereço fraca e cesta alta → intensificação mais forte ou postura de negação mais rígida

Este padrão demonstra que a melhor estratégia de fraude muitas vezes não é um controlo, mas vários controlos coordenados sob uma camada de orquestração.

---

Entradas que DEUNA pode usar na lógica de roteamento#

Uma implementação robusta geralmente combina vários insumos em vez de depender apenas de uma pontuação de risco.

As entradas típicas incluem:

• decisão antifraude, pontuação ou motivo de rejeição
• histórico do cliente e nível de confiança
• valor do pagamento e perfil da cesta
• tipo de produto ou sensibilidade à fraude do pedido
• BIN, emissor, tipo de cartão ou país
• anomalias de dispositivo ou sessão
• padrões de velocidade
• políticas verticais do comerciante
• requisitos específicos de geografia
• histórico de aprovação ou resultados de fraude por segmento
• Resultados AVS retornados por PSPs ou gateways suportados
• faixas de revisão de provedores de fraude, filas ou resultados de revisão manual

Isso permite que o DEUNA atue como um mecanismo de decisão centralizado em vez de codificar a lógica dentro de cada integração de provedor.

---

Considerações de implementação#

1. Mantenha as decisões centralizadas#

A política de autenticação e verificação deve residir na camada de orquestração e não ser fragmentada em código de front-end, configurações de PSP e ferramentas de fraude de forma independente.

2. Separar a pontuação de risco da seleção de ações#

Uma pontuação de fraude por si só não define a melhor ação.

A camada de orquestração deve traduzir os sinais de risco na ação correta para aquela transação, como:

• aprovar
• enriquecer
• intensificar
• verificar identidade
• aplicar negação ou escalonamento baseado em AVS
• caminho para revisão manual
• tentar novamente ou retornar

3. Projeto para observabilidade#

Os comerciantes devem medir o desempenho de cada filial, incluindo:

• taxa de recuperação de transações anteriormente rejeitadas
• aumento de autorização por caminho de autenticação
• taxa de fraude por caminho
• taxa de desafio e taxa de abandono, quando aplicável
• impacto na conversão por segmento de usuário
• Taxa de incompatibilidade AVS por PSP e segmento
• taxa de negação impulsionada pela política AVS padronizada
• economia do custo de recuperação

4. Evite regras estáticas de tamanho único#

Uma regra que funciona bem para usuários iniciantes de alto valor pode ser prejudicial para clientes recorrentes de baixo valor.

A DEUNA é mais eficaz quando os comerciantes segmentam a estratégia por risco e contexto de negócios.

5. Trate os artefatos de autenticação com cuidado#

Quando o 3DS faz parte do fluxo, as implementações devem lidar com os dados de autenticação de acordo com as regras atuais da rede de cartões, do provedor de pagamento e de conformidade. Não dependa do armazenamento a longo prazo de valores de autenticação criptográfica, como CAVV ou AAV. DEUNA passa o resultado da autenticação necessária para o fluxo de autorização suportado; os registros e análises do comerciante não devem reter criptogramas brutos.

6. Trate o AVS como um sinal, não como a única fonte da verdade#

AVS é valioso, mas não deve ser interpretado isoladamente.

As melhores implementações avaliam AVS juntamente com:

• histórico do usuário
• valor da transação
• pontuação antifraude
• comportamento do dispositivo
• padrões de fraude específicos do mercado

É exatamente por isso que o AVS pertence a um modelo de orquestração, e não a uma regra de gateway autônoma e codificada.