O TVR, o TSI e Como um Terminal Decide te Recusar

💡 TL;DR (Too Long; Didn't Read)

O motor de decisão em 90 segundos:

O TVR (Terminal Verification Results, tag 95, 5 bytes) é uma lista corrente de tudo que deu errado ou notável durante a transação — cada bit é o resultado de uma checagem.

O TSI (Transaction Status Information, tag 9B, 2 bytes) registra quais funções foram executadas. O TVR diz "o que aconteceu"; o TSI diz "o que sequer tentamos".

O veredicto é lógica bit a bit pura. O terminal faz AND do TVR com códigos de ação — IAC (Issuer Action Codes, do cartão) e TAC (Terminal Action Codes, da configuração do adquirente) — para Denial, Online e Default.

Casamento em Denial → AAC (recusa offline). Casamento em Online num terminal capaz de ir online → ARQC (vai online). Nenhum casamento → TC (aprova offline).

Noventa por cento das investigações "por que isso foi recusado / por que foi online" terminam no instante em que você decodifica o TVR e o alinha aos códigos de ação. Esta é essa habilidade.

Na primeira parte desta série descrevi uma transação com chip como o terminal montando um retrato do cartão, tag por tag, até ter o suficiente para decidir. Este artigo é sobre a decisão em si — a etapa que o EMV chama de Terminal Action Analysis — e sobre as duas tags que carregam o estado em que ela opera. Se você já encarou uma recusa que não conseguia explicar, ou viu uma transação de valor baixo inexplicavelmente ir online e adicionar latência, a resposta estava quase certamente escrita em cinco bytes que você não decodificou: o Terminal Verification Results, tag 95.

O bonito desta fase é que não há mágica nela. Depois de toda a leitura, autenticação e checagem de PIN, o veredicto aprovar/online/recusar se reduz a um AND bit a bit. Aprenda os layouts de bits e a regra do AND e você prevê a decisão de um terminal no papel, o que significa que consegue depurar um em produção. Tudo aqui é EMVCo Book 3, §10.7 e Anexos C5/C6 — cito a estrutura, não reproduzo a especificação.

Dois campos de bits, duas perguntas diferentes

Mantenha estes separados, porque engenheiros os confundem constantemente.

O TVR (tag 95) responde "o que deu errado, ou o que merece sinalização?" Seus cinco bytes são um catálogo de desfechos negativos e notáveis: a autenticação offline falhou, a aplicação expirou, exigia-se PIN mas não havia teclado, o valor excedeu o floor limit, a autenticação do emissor falhou. Um TVR recém-inicializado é todo zeros — uma transação limpa. Bits são ligados conforme as checagens produzem resultados preocupantes. No TVR, bits ligados são má notícia (ou pelo menos notícia).

O TSI (tag 9B) responde uma pergunta diferente: "quais funções nós sequer executamos?" Seus dois bytes registram que a autenticação de dados offline foi executada, que a verificação do portador foi executada, que o gerenciamento de risco do terminal foi executado, e assim por diante. O TSI não é sobre passar ou falhar; é sobre tentado ou pulado. Você precisa dele porque "o bit de SDA-falhou no TVR é zero" é ambíguo — o SDA passou, ou o SDA nunca rodou? O TSI desambigua: cheque seu bit de "autenticação de dados offline foi executada" e você sabe em qual mundo está.

Decodificando o TVR, byte a byte

Vamos decodificar um real. Suponha que um terminal apresente 95 05 00 00 00 80 00 — tag 95, comprimento 5, valor 00 00 00 80 00. Cinco bytes, cada um um campo de bits. Aqui está o mapa dos bits que você vai efetivamente encontrar, agrupados por byte e por preocupação.

Byte 1 — Autenticação de Dados Offline. O bit mais alto (b8) significa a autenticação de dados offline não foi executada. Abaixo dele: SDA falhou (b7), dados do ICC ausentes (b6), cartão aparece no arquivo de exceções do terminal (b5), DDA falhou (b4), CDA falhou (b3). Este byte é onde um cartão clonado ou adulterado, ou uma cadeia de certificados quebrada, se anuncia.

Byte 2 — Restrições de Processamento. ICC e terminal têm versões diferentes da aplicação (b8), aplicação expirada (b7), aplicação ainda não vigente (b6), serviço solicitado não permitido para este produto de cartão (b5), cartão novo (b4). O bit de "serviço não permitido" é o culpado usual atrás de "este cartão funciona em todo lugar, menos aqui" — um cartão doméstico recusado num terminal internacional, codificado em um bit.

Byte 3 — Verificação do Portador. A verificação do portador não teve sucesso (b8), CVM não reconhecido (b7), limite de tentativas de PIN excedido (b6), exigia-se PIN mas o teclado está ausente ou quebrado (b5), exigia-se PIN, o teclado existe, mas o PIN não foi digitado (b4), PIN online digitado (b3). Este byte é o registro forense da fase de CVM da Parte 1.

Byte 4 — Gerenciamento de Risco do Terminal. Transação excede o floor limit (b8), limite inferior consecutivo offline excedido (b7), limite superior consecutivo offline excedido (b6), transação selecionada aleatoriamente para processamento online (b5), lojista forçou a transação para online (b4). Nenhum desses é uma "falha" — são razões pelas quais um terminal quer o emissor no circuito.

Byte 5 — Emissor / Conclusão. TDOL padrão usado (b8), autenticação do emissor falhou (b7), processamento de script falhou antes do GENERATE AC final (b6), processamento de script falhou depois dele (b5). Em perfis contactless os bits inferiores deste byte carregam resultados de resistência a relay. Este byte é escrito majoritariamente após a troca online.

Agora decodifique nosso exemplo 00 00 00 80 00. Bytes 1, 2, 3 e 5 são zero — sem problemas de autenticação, sem questões de restrição, sem preocupações de CVM, sem falhas de emissor/script. O byte 4 é 0x80 = 1000 0000, então b8 está ligado: a transação excedeu o floor limit. Essa é a história inteira que este TVR conta: um cartão perfeitamente saudável cujo valor cruzou o teto offline. Nada falhou. Mas esse único bit ligado está a ponto de mandar a transação para online, e entender por que exige os códigos de ação.

Os códigos de ação: IAC e TAC

Um bit ligado no TVR é um fato, não uma decisão. "Floor limit excedido" não significa nada até que algo o mapeie para uma consequência. Esse mapeamento é o trabalho dos códigos de ação, e há duas fontes deles — a parte que confunde as pessoas.

Os TAC (Terminal Action Codes) são configurados pelo adquirente no terminal. Expressam o apetite de risco do adquirente: "para meus terminais, estas condições devem recusar, estas devem ir online, estas são o padrão". Os IAC (Issuer Action Codes) vivem no cartão e são lidos na fase de READ RECORD da Parte 1 (tags 9F0D IAC-Denial, 9F0E IAC-Online, 9F0F IAC-Default). Expressam o apetite de risco do emissor para seus próprios cartões.

Ambos vêm nos mesmos três sabores, e cada um é uma máscara de 5 bytes com exatamente o mesmo layout de bits do TVR:

Denial (TAC-Denial, IAC-Denial 9F0D): condições sob as quais a transação deve ser recusada offline, sem nem consultar o emissor.
Online (TAC-Online, IAC-Online 9F0E): condições sob as quais a transação deve ser enviada online para decisão do emissor.
Default (TAC-Default, IAC-Default 9F0F): condições sob as quais agir quando o terminal não pode ir online (terminal só-offline, ou tentativa online falhou).

Como os códigos de ação compartilham o layout do TVR, "este TVR dispara este código de ação" é um único AND bit a bit: alinhe os dois campos de 5 bytes e veja se algum bit está ligado em ambos.

A lógica AND que produz o veredicto

Aqui está o algoritmo que o terminal executa de fato. Vale memorizar porque é pequeno e é o jogo inteiro.

Leia de cima para baixo. Denial primeiro: faça AND do TVR com IAC-Denial e TAC-Denial; se qualquer um produzir resultado diferente de zero, o terminal solicita um AAC e a transação recusa offline — o emissor nunca é contatado. Online em segundo: se o terminal pode ir online, faça AND do TVR com IAC-Online e TAC-Online; resultado diferente de zero significa solicitar um ARQC e rotear ao emissor. Default em terceiro: relevante apenas quando o terminal não pode ir online — faça AND contra os códigos Default para decidir entre recusar e aprovar offline. Se nada casar em nenhum estágio, o terminal solicita um TC e aprova offline.

Note a prioridade: Denial domina Online, que domina Default. Um bit que aparece nas máscaras de Denial e de Online vai recusar, porque Denial é checado primeiro. Essa ordenação não é acidental — é como o sistema garante que "nunca deve aprovar" sempre vence "deveria consultar o emissor".

Dois exemplos resolvidos

Vamos rodar nosso TVR de floor limit por ele. TVR = 00 00 00 80 00. Suponha códigos de ação típicos: TAC-Denial = 00 00 00 00 00 (este adquirente não recusa nada puramente offline), TAC-Online com o b8 do byte 4 ligado (floor-limit-excedido deve ir online), e os valores de IAC do cartão não forçando recusa.

Denial: 00 00 00 80 00 AND 00 00 00 00 00 = 0; AND IAC-Denial = 0. Sem recusa.
Online (terminal capaz de ir online): 00 00 00 80 00 AND TAC-Online (00 00 00 80 00) = 00 00 00 80 00 ≠ 0. Casou.
Veredicto: solicita ARQC, vai online.

Essa é a explicação completa para "por que meu café de R$ 20 foi online?". O valor cruzou o floor limit, o bit de floor limit ligou no byte 4 do TVR, e o TAC-Online do adquirente mapeou esse bit para "vá online". Sem falha, sem fraude — apenas configuração encontrando aritmética.

Agora um exemplo mais sombrio. Suponha que a autenticação de dados offline falhou num terminal só-offline (um bloqueio de transporte público, digamos). SDA falhou → b7 do byte 1 do TVR ligado → TVR = 40 00 00 00 00. O IAC-Denial do cartão tem o b7 do byte 1 ligado (emissores rotineiramente dizem "se a autenticação do meu cartão falhar, recuse — não tente nem ir online").

Denial: 40 00 00 00 00 AND IAC-Denial (40 00 00 00 00) = 40 00 00 00 00 ≠ 0. Casou.
Veredicto: solicita AAC, recusa offline. O emissor nunca é contatado, corretamente — um cartão cuja autenticação falhou não deveria ter segunda chance de um bloqueio que não pode verificá-lo online.

Dois bits ligados, dois bytes diferentes, dois desfechos opostos, ambos completamente determinados por AND. É por isso que decodificar o TVR é a habilidade de depuração de maior alavancagem no EMV do lado do terminal.

Cicatrizes de batalha

O cartão ainda pode anular o terminal. A Terminal Action Analysis produz uma solicitação — o P1 do primeiro GENERATE AC. O cartão executa sua própria Card Action Analysis e pode rebaixar: você solicita um TC, o cartão devolve um ARQC ou um AAC com base no seu estado interno de risco e na sua avaliação de IAC. Então "o TVR disse aprovar" e "a transação aprovou" são afirmações diferentes. Sempre confirme o desfecho no Cryptogram Information Data devolvido (tag 9F27), não na sua própria pré-decisão.

Códigos de ação vazios são uma decisão, não uma ausência. Um TAC-Denial todo zeros não significa "padrões seguros" — significa "não recuse nada offline, aconteça o que acontecer", incluindo um CDA que falhou. TAC-Denial todo zeros mal configurado com um caminho capaz de offline é exposição real a fraude. Os códigos de ação são política de segurança; trate os vazios como achado, não como padrão.

O byte 5 do TVR é escrito tarde. Os bits de autenticação do emissor e de processamento de script no byte 5 são ligados após a troca online, durante o processamento do segundo generate AC. Se você tirar um retrato do TVR antes de ir online e tratá-lo como final, vai perder falhas de autenticação do emissor por completo. Decodifique o TVR que volta com a conclusão, não apenas o da primeira decisão.

Onde isto se encaixa

Você agora entende a decisão. O que ainda não viu é o que o ARQC realmente é — o criptograma que o terminal solicita quando esta lógica diz "vai online". Essa é a Parte 4: construir um Application Cryptogram a partir do zero, com chaves de teste reais, para que a afirmação que o emissor valida deixe de ser uma caixa-preta. E os campos de bits que você decodificou aqui são exatamente o tipo de estrutura que o Dicionário de Tags EMV do gsstk já detalha por tag — 95 (TVR) e 9B (TSI) — com um Decodificador TVR/TSI dedicado no roadmap para transformar cinco bytes hex numa lista em português das condições ligadas, a diferença entre adivinhar uma recusa e lê-la.

Leitura Relacionada no gsstk

O Que Realmente Acontece Quando Você Insere um Chip — Parte 1: onde o TVR é populado ao longo da transação.
Lendo BER-TLV à Mão — e Por Que Você Não Deveria — Parte 2: parsear as tags antes de decodificar seus bits.
ARQC a Partir do Zero: Criptogramas de Aplicação Sem Caixa-Preta — Parte 4: o que "ir online" de fato envia.

Ferramentas: decodifique os dois campos de bits em suas páginas de tag — 95 (TVR) e 9B (TSI) — mais os códigos de ação do emissor 9F0D / 9F0E / 9F0F no Dicionário de Tags EMV.

Arquivado em: EMV · Payments · POS · Acquiring · Contactless

Este artigo foi arquitetado por humanos e sintetizado com assistência de IA sob a persona Nexus (AI).