Trilha 2 e o Service Code: O Que a Tarja Magnética Ainda Conta ao Chip

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

Trilha 2 em 90 segundos:

• Track 2 Equivalent Data (tag 57) é a trilha da tarja magnética carregada dentro do chip: PAN, um separador, validade (AAMM), um service code de 3 dígitos e dados discricionários, empacotados em nibbles.
• O service code são três dígitos que silenciosamente decidem interchange, roteamento de autorização e se um PIN é esperado — e seu primeiro dígito é por que a tarja de um cartão com chip diz "use o chip".
• Os dados discricionários carregam valores de verificação do emissor (CVV/CVC da tarja, PVKI/PVV para verificação de PIN) — e são exatamente o que você nunca deve logar.
• Luhn valida o dígito verificador do PAN em poucas linhas e pega a maioria dos erros de digitação e capturas malformadas antes de você gastar uma ida à rede com elas.
• A Trilha 2 é legado na origem e onipresente na prática; você vai parseá-la muito depois de a própria tarja desaparecer.

A tarja magnética deveria estar morta e, em certo sentido, está — mas seu modelo de dados sobreviveu a ela. Quando um cartão com chip apresenta os dados da conta, ele o faz num campo chamado Track 2 Equivalent Data, tag 57, que é precisamente o layout da trilha 2 da tarja magnética reproduzido no chip. Aprenda a lê-lo uma vez e você lê uma passagem de tarja, uma leitura de chip e metade dos campos dentro de uma mensagem de autorização, porque todos falam este formato. Este é um guia campo a campo, com atenção particular ao service code de três dígitos que a maioria dos engenheiros ignora e que silenciosamente governa como cada transação é roteada e restringida. Segue a ISO/IEC 7813 e o EMVCo Book 3; cito a estrutura, não o texto da especificação.

A forma da Trilha 2

A Trilha 2 é compacta por desenho — a tarja tinha capacidade limitada, então o formato é denso. Na tag 57 do chip ela é empacotada em dois dígitos por byte (nibbles BCD), terminada por um nibble de preenchimento. Disposta logicamente, é:

PAN  =  'D'  AAMM  SSS  DadosDiscricionarios  ['F' pad]
 │      │     │     │          │
 │      │     │     │          └─ dados do emissor: CVV/CVC, PVKI, PVV etc.
 │      │     │     └─ service code de 3 dígitos
 │      │     └─ validade: ano, mês
 │      └─ separador de campo (hex 'D')
 └─ Primary Account Number (até 19 dígitos)

O separador de campo é o nibble hex D — ele marca o fim do PAN, que tem comprimento variável. Tudo depois dele é fixo em forma: quatro dígitos de validade como AAMM, três dígitos de service code, então dados discricionários preenchendo o resto, completados com nibbles F até fechar o byte. Então o parse inteiro é: leia dígitos até bater num D, esse é o PAN; os quatro seguintes são a validade; os três seguintes são o service code; o resto, menos os F finais, são dados discricionários. Não há campo de comprimento dentro da trilha 2 — o separador e os offsets fixos são a gramática.

Um exemplo resolvido. Suponha que a tag 57 decodifique para a string de dígitos:

4761739001010119 D 2512 201 1234567890

O PAN é 4761739001010119 (16 dígitos, terminando no D), o cartão expira em 2025-12 (AAMM = 2512), o service code é 201, e 1234567890 são dados discricionários. Quatro fatos, um campo. Note que a validade é AAMM — ano primeiro — que é o bug de transposição mais comum quando alguém monta dados de teste à mão.

O service code faz mais do que você pensa

Aqueles três dígitos depois da validade são a parte menos lida do cartão. Cada dígito é um código independente e, juntos, influenciam interchange, autorização e verificação do portador.

Primeiro dígito — interchange e tecnologia. 1 = interchange internacional. 2 = interchange internacional, ICC (chip) preferencial — o cartão tem chip e ele deve ser usado. 5 = interchange nacional. 6 = nacional, ICC preferencial. 7 = privado. 9 = teste. Os cartões com chip que você manuseia quase todos começam com 2 ou 6, e esse dígito inicial é a tarja dizendo ao terminal: "eu tenho um chip — só caia para mim se for obrigado". É por isso que um service code 201 numa transação de tarja é sinal de fraude: um cartão com chip sendo passado na tarja quando sua própria tarja manda usar o chip.

Segundo dígito — processamento de autorização. 0 = normal. 2 = deve ser autorizado online pelo emissor. 4 = autorizado pelo emissor, salvo acordo bilateral. Este dígito é uma dica de roteamento: um 2 aqui significa "não me aprove offline".

Terceiro dígito — serviços e PIN. Este agrupa serviços permitidos com expectativas de PIN. 0 = sem restrições, PIN obrigatório. 1 = sem restrições. 2 = apenas bens e serviços, PIN obrigatório. 3 = apenas ATM, PIN obrigatório. 4 = apenas dinheiro. 5 = apenas bens e serviços, sem PIN obrigatório. 6 = sem restrições, PIN obrigatório. 7 = apenas bens e serviços, PIN obrigatório. Então o mesmo cartão pode dizer "sempre exija PIN" ou "bens e serviços sem PIN", em um dígito.

Leia nosso service code de exemplo 201: interchange internacional com chip preferencial (2), autorização normal (0), sem restrições e sem PIN obrigatório (1). Esse é um perfil padrão de cartão internacional com chip. Uma vez que você lê os três dígitos, um service code deixa de ser ruído e se torna uma declaração compacta de como o emissor quer que este cartão seja tratado.

Dados discricionários: a parte que você não deve guardar

Depois do service code vêm os dados discricionários — definidos pelo emissor, e a razão pela qual o PCI existe. Na tarja magnética este campo carrega o CVV/CVC (o valor de verificação do cartão codificado na tarja, distinto do CVV2 impresso no verso) e, para esquemas de verificação de PIN, o PVKI (PIN Verification Key Index) e o PVV (PIN Verification Value). São valores criptográficos que o emissor usa para validar o cartão e o PIN.

A regra é absoluta: você não armazena dados discricionários após a autorização, e nunca loga dados completos de trilha. O CVV da tarja e o PVV são exatamente os segredos que permitem a um fraudador reproduzir uma tarja funcional. O PCI-DSS proíbe retê-los após a autorização, e todo vazamento real de dados de cartão de consequência envolveu alguém guardando dados de trilha que não tinha nada que guardar. Ao parsear a tag 57, trate a cauda de dados discricionários como radioativa: use-a no momento se precisar, e descarte.

Luhn: a validação mais barata que você está pulando

Antes de enviar um PAN a qualquer lugar, uma checagem custa quase nada e pega a maioria das capturas malformadas: o algoritmo de Luhn (ISO/IEC 7812), a fórmula do dígito verificador que todo número de cartão válido satisfaz. Percorra os dígitos da direita para a esquerda; dobre cada segundo dígito; se um dígito dobrado passar de 9, subtraia 9; some tudo; um PAN válido faz o total ser múltiplo de 10.

luhn_ok(pan):
    total = 0
    dobrar = falso
    para cada dígito d do mais à direita ao mais à esquerda:
        x = d
        se dobrar:
            x = d * 2
            se x > 9: x = x - 9
        total = total + x
        dobrar = não dobrar
    retorne total % 10 == 0

Luhn não diz que o cartão é real, ativo ou tem saldo — apenas que o número é internamente consistente. Mas transforma uma classe de lixo (um dígito transposto, uma captura truncada, um PAN de teste digitado errado) numa rejeição local em vez de uma ida-e-volta de autorização desperdiçada e uma recusa confusa. São quatro linhas. Rode na borda.

Cicatrizes de batalha

A validade é AAMM, não MMAA. A tarja e a tag 57 colocam o ano primeiro. Inverta e você vai "expirar" todo cartão válido e passar todo cartão de fato expirado. Este é o bug de trilha 2 mais comum e ele sobrevive à revisão de código porque as duas ordens parecem plausíveis.

Um service code 2xx numa passagem de tarja é uma história. Quando você vê um service code chip-preferencial chegando de um modo de entrada por tarja, algo forçou um fallback — um chip quebrado, um downgrade malicioso ou uma tarja clonada. Não é automaticamente fraude, mas é automaticamente digno de um segundo olhar, e adquirentes maduros pontuam isso.

O CVV da tarja não é o CVV2 impresso. São valores diferentes, calculados de formas diferentes e morando em lugares diferentes — o CVV da tarja nos dados discricionários, o CVV2 impresso no painel de assinatura para cartão não presente. Confundi-los no seu modelo de dados leva a armazenar o segredo errado ou validar contra o errado. Mantenha-os distintos, e não mantenha nenhum além do que a transação exige.

Onde isto se encaixa

A Trilha 2 são os dados de conta que o fluxo da transação lê do cartão e que o ISO 8583 carrega ao emissor. Ela é envelopada em BER-TLV como tudo o mais, então a habilidade de parsing da Parte 2 te leva até o campo; este artigo te leva para dentro dele. Resolva 57 (Track 2 Equivalent Data) e 5A (PAN) no dicionário de tags enquanto avança.

Leitura Relacionada no gsstk

• O Que Realmente Acontece Quando Você Insere um Chip — onde a tag 57 é lida do cartão.
• Lendo BER-TLV à Mão — e Por Que Você Não Deveria — parseando a tag que contém este campo.
• ISO 8583 Ainda Está em Todo Lugar — para onde a Trilha 2 viaja como DE 35.

Ferramentas: resolva 57 (Track 2 Equivalent Data) e 5A (Application PAN) no Dicionário de Tags EMV.

Arquivado em: EMV · Payments · POS · Acquiring · Card Issuing

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