Matriz 3DS & Liability Shift

REGRA

O protocolo 3-D Secure (3DS) não serve apenas para pedir um OTP ao cliente. Ele é um acordo de proteção legal contido na ISO 8583. Sempre que uma transação passar por ele, a rede devolve um ECIECIElectronic Commerce Indicator. Informação traficada no DE 48 (Master) ou DE 60 (Visa).Ver no Glossário e um CAVV / AAV provando que ocorreu uma tentativa. Use a matriz abaixo para descobrir quando o risco de Fraude sai das suas costas e vai para o banco (Liability Shift).

Simulador de ECI e Risco

Escolha a Situação do 3DS

Frictionless / Fully Authenticated

Autenticação completa. O emissor validou o portador silenciosamente (Frictionless) ou via desafio (Challenge/OTP).

Valor ECI (Mastercard)

Liability Shift Ativo

Fraude financeira por uso indevido será custeada pelo Banco Emissor.

Imune a:

Fraude (RC 10.4 Visa / 4837 Mastercard)
Disputas de 'Transação não reconhecida'

Ainda vulnerável a:

Produto defeituoso
Mercadoria não entregue
Assinatura cancelada

ECI: Electronic Commerce IndicatorElectronic Commerce IndicatorUm campo de dois dígitos devolvido pelo MPI (Merchant Plug-In) após a tentativa 3D-Secure, que deve ser trafegado na ISO 8583 do fechamento da autorização.REGRA

Na ISO 8583: Como Trafegar o ECI

VISA (DE 60.8)

O ECI deve ser enviado na posição 8 do DE 60, junto ao CAVV que é trafegado independente em tag própria (Tag 0X).

MASTERCARD (DE 48.42 - UCAF)

Mastercard exige os dados dentro do UCAF (Universal Cardholder Authentication Field). O ECI (02, 01, ou 00) vai no início ou no fim dependendo da versão do UCAF, mas o DE 48 deve carregar a string Base64 do AAV.

Onde entra a Tokenização Cloud?

Com o Apple Pay e Carteiras Digitais via Network Tokens, o 3-D Secure não é sequer invocado. A Bandeira automaticamente aplica o Liability Shift (como se fosse ECI 05) devido à prova de Device Biometrics (FaceID).

Ver Playbook de DAF & Tokenização