Manual Operacional

MANUAL OPERACIONAL
Autorização de Transações EMV (Full Grade)

Versão 5.0 | 12 de maio de 2022
As informações contidas neste documento são restritas e de propriedade da Elo Serviços

S.A., instituidora dos Arranjos de Pagamento Elo. É vedada a reprodução, a divulgação parcial
ou total e/ou a publicação deste material sem o consentimento prévio e por escrito da Elo
Serviços S. A
Autorização de Transações EMV (Full Grade) – Versão 5.0
Controle de Versões
Processo
Descrição da alteração Versão Data
envolvido
Manual Completo • Novo manual 1.0 24/11/2014
Validação de • Inclusão de seção exclusiva para ataque

1.1 02/02/15
Criptogramas “man-in-the-middle”
• Atualização para contemplar as mudanças

Aceitação da aplicação de pagamento internacional:
1.2 27/02/15
Internacional CVR
ARQC
Manual Completo • Alteração no template do Manual 1.3 07/04/15
• Detalhamento do local do CVR para

CVR 1.4 03/12/15
aplicação Doméstica e Internacional
Estrutura da 9F10 • Ajuste na seção, de 1.1.1 para 3.1.2
(Local CVR) – • Ajuste no Issuer Application Data, de “09- 1.5 11/01/16
Internacional 32” para “09-16”
• Ajuste no nome da Seção 06, para
Validação de “Recomendações adicionais para

1.6 30/03/16
Criptogramas autorização”.
• Descrição do cálculo ARPC.
Validação de
• Inclusão do cálculo do Criptograma tipo 15 2.0 03/05/18
Criptograma 15
12/05/2022 Este documento é restrito e de propriedade da Elo Serviços S.A. Pag. 2/97
Processo
Descrição da alteração Versão Data
envolvido
CD-CVM (DC)
• Inclusão das tags DC e 9F53
CL-CRV (9F53) • Detalhamento das possíveis estruturas da 3.0 15/08/18
tag 9F10.
ZIP MODE
• Descritivo sobre a obrigatoriedade da

Introdução
validação do ARQC
ATC • Alteração no detalhamento das origens do
4.0 27/07/2020
CL-CRV (9F53) ATC
• Detalhamento de cada bit do CL-CVR
ZIP MODE
• Inclusão do cálculo do Criptograma DCVV
Adicionada seção
• Adicionada seção inteira adicionando as
para chip Elo 2.0
especificidades do chip Elo 2.0. 5.0 12/05/2022
Alterada descrição
• Adicionada descrição detalhada do ATC.
do ATC.
Sumário
3.2.1 Marcações de Exemplos ............................................................................ 9
4.1.1 CVR e TVR ................................................................................................ 10

4.1.2 ATC ........................................................................................................... 10
4.1.3 CVM (Cardholder Verification Method) List ........................................... 11
4.1.4 CD-CVM ‘DC’ ............................................................................................ 11
4.1.5 Issuer Application Data (IAD) ‘9F10’ ....................................................... 12
4.9.1 TVR – Byte 1 ............................................................................................. 42

4.9.2 TVR – Byte 2 ............................................................................................. 44
4.9.3 TVR – Byte 3 ............................................................................................. 45
4.9.4 TVR – Bytes 4 e 5...................................................................................... 48
4.10.1 ARQC - Authorization Request Cryptogram........................................... 50

4.10.2 ARPC - Authorization Response Cryptogram ......................................... 51
4.11.1 Cálculo para ARQC Doméstico e ARQC Internacional ............................ 53
4.12.1 DCVV – Dynamic Card Verification Value ............................................... 54

4.12.2 Cálculo para DCVV Internacional ............................................................ 55
4.12.3 Método de derivação para chave AUKDCVV .......................................... 56
5.1.1 CVR e TVR ................................................................................................ 59

5.1.2 ATC ........................................................................................................... 59
5.1.3 CVM (Cardholder Verification Method) List ........................................... 59
5.1.4 CD-CVM ‘DC’ ............................................................................................ 60
5.1.5 Issuer Application Data (IAD) ‘9F10’ ....................................................... 60
5.5.1 TVR – Byte 1 ............................................................................................. 83

5.5.2 TVR – Byte 2 ............................................................................................. 86
5.5.3 TVR – Byte 3 ............................................................................................. 87
5.5.4 TVR – Bytes 4 e 5...................................................................................... 89
5.6.1 ARQC - Authorization Request Cryptogram........................................... 90

5.6.2 ARPC - Authorization Response Cryptogram ......................................... 91
5.7.1 Cálculo para ARQC Doméstico e ARQC Internacional ............................ 93
5.8.1 DCVV – Dynamic Card Verification Value ............................................... 94

5.8.2 Cálculo para DCVV Internacional ............................................................ 94
5.8.3 Método de derivação para chave AUKDCVV .......................................... 95
Indicadores de Atuação
O mapa de impactos e atuação tem o objetivo de indicar as ações devidas de acordo

com cada situação específica para cada um dos tópicos elencados por Parceiro.
• Regulatório: obrigatoriamente deve ser desenvolvido pelo participante, por

exigência dos órgãos reguladores.
• Mandatório: obrigatoriamente deve ser desenvolvido pelo participante
• Equiparado: obrigatoriamente deve ser desenvolvido pelo Participante, se ele já

possuir a funcionalidade, o serviço ou o produto com outro arranjo de pagamento;
• Opcional: o participante pode optar ou não por desenvolver.
• Informativo: não requer desenvolvimento pelo participante – apenas informativo
Quadro de Indicadores
Informativo
Mandatório
Regulatório
Equiparado
Opcional
Emissores X
Credenciadores X
Marcações de Revisão
Para facilitar a análise do documento pelos Participantes dos Arranjos de Pagamento

Elo, as alterações estarão grafadas da seguinte forma:
• Vermelho tachado (Vermelho tachado) – Indica a exclusão do texto no documento,

ou seja, os textos grafados em vermelho e tachados foram excluídos da versão do
manual e indicam que os procedimentos operacionais não são mais aplicáveis.
• Verde (Verde normal) – Indica a inclusão do texto no documento, ou seja, os textos
grafados em verde foram incluídos na versão do manual e indicam que os
procedimentos operacionais são aplicáveis e estarão vigentes na data de vigência
indicada no manual.
Na próxima versão deste documento os textos tachados em vermelho serão

removidos e os textos em verde serão atualizados para a cor do contexto.
Introdução
A solução determinante para evitar fraudes e maximizar a segurança, é baseada na

implantação completa das funcionalidades EMV e na validação Online, esta implantação é
conhecida como Full Grade. Para o Emissor tornar-se Full Grade se faz necessário validar o
ARQC e gerar o ARPC, bem como avaliar os parâmetros adicionais que seguem na transação.
A validação de ARQC é mandatória para todos os Emissores Elo.
Nas seções decorrentes apresentaremos estes parâmetros, as particularidades Elo e

como analisá-los.
O manual é dividido em duas sessões contemplando as necessidades para os modelos

de implementação do chip Elo 1.0 e Chip Elo 2.0.
Chip Elo 1.0: Chip que possui a tecnologia Pure para a aplicação Contato Doméstico e
as demais utilizam aplicação DPAS. Também referido como Modelo de Implementação 1.0
Chip Elo 2.0: Chip que possui a tecnologia DPAS para todas as aplicações. Também
referido como Modelo de Implementação 2.0
Público-alvo
A Elo produz essa documentação para todos os seus parceiros que utilizam o sistema
de autorização, como Estabelecimentos Comerciais, Credenciadores, Subcredenciadores,
Redes de ATM, Emissores e seus respectivos agentes, incluindo Processadoras.
Guia de Utilização do Manual
Esta seção tem o objetivo de auxiliar a compreensão e utilização do manual, de modo

que os padrões adotados sejam facilmente identificados dentro do documento.
3.2.1 Marcações de Exemplos
Para garantir que os exemplos não sejam confundidos com o real conteúdo das
informações do documento pelos Participantes dos Arranjos de Pagamento Elo,
alguns dos exemplos estarão formatados da seguinte forma:
• Bordas pontilhadas, com fundo Cinza.
Obs.: Nem todos os exemplos do Manual serão apresentados desta maneira, apenas
aqueles que pretende-se destacar.
Modelo de Implementação Elo 1.0
Elementos EMV
4.1.1 CVR e TVR
Os elementos Card Verification Results (CVR) e Terminal Verification Results (TVR) são
fontes de informações importantes para verificação da transação corrente.
Recomenda-se avaliar todos os status (bits), bem como compará-los entre estas duas
TAGS para obter a melhor avaliação para decisão.
4.1.2 ATC
O ATC (Application Transaction Counter) é um contador gerado pela aplicação de

pagamento a cada tentativa de transação, sendo que este valor é enviado no DE55
para transações presenciais com Chip, no DE122 para transações in-app ou nas
Trilhas para transações do tipo ZIP/MST, permitindo ao Emissor o acompanhamento
da evolução incremental deste contador e a detecção de Fraudes como o Replay-
Attack.
O modelo de implementação Elo 1.0 possui a seguinte estrutura de ATC:
1 ATC para aplicação Crédito Doméstico Contato.
1 ATC para aplicação Débito Doméstico Contato.
1 ATC para aplicação Crédito Doméstico Sem Contato.
1 ATC para aplicação Débito Doméstico Sem Contato.
1 ATC para aplicação Crédito Internacional Contato, Sem Contato e Zip Mode.
1 ATC para aplicação Débito Internacional Contato e Sem Contato (Débito

Internacional não possui Sem Contato no cartão Múltiplo)
4.1.3 CVM (Cardholder Verification Method) List
O “CVM List” está presente no cartão e é definido no template Elo, este contém as
instruções para verificação do portador (Como, Onde e Quando). Confrontar este
valor e suas possibilidades com os status equivalentes no CVR e TVR são
recomendados para identificar ataques do tipo “man-in-the-middle”.
4.1.4 CD-CVM ‘DC’
O “Consumer Device - Cardholder Verification Method” está presente em transações

sem contato ou CNP (in-app) quando realizadas/autenticadas por um dispositivo,
indicando o método aplicado. Esta TAG estará contida no IAD da TAG 9F10 para
transações sem contato.
Byte Bit Descrição
0001 = NFC 0100 = IN APP
0010 = BLE 0101 = 3D – Secure

8-4
0011 = QR
Code
01 0000 = No 0011 = 0110 = Facial

CD CVM Pattern recognition
0001 = 0100 = 0111 = Local

4-1
Password Crypto PIN Passcode
0010 = 0101 = Retina 1000 = Other

Fingerprint Scan biometric
4.1.5 Issuer Application Data (IAD) ‘9F10’
O IAD contém dados proprietários da aplicação Elo a serem transmitidos ao Emissor

em uma transação online (no pedido de autorização) e após a conclusão da transação
na Liquidação.
Esta tag é a concatenação dos elementos de dados internos do cartão listados nas
tabelas a seguir e no IDD.
Se presente, o IDD permite que a aplicação transmita dados adicionais online para
tags que não estão disponíveis na solicitação de autorização, através do IADOL.
Formato: binário, comprimento variável (até 32 bytes)
4.1.5.1 Estrutura 9F10 para Contato Doméstico
Length of the EMVCo defined part of Issuer Application

01
Data –value = ‘0F’
08-
02 IAD Format Code: CCD Version 4.1 IAD Format (‘A‘)
05
04- Cryptogram Version Number (CVR): CCD Version 4.1

01 Cryptogram Version Number (‘5’)
03 Derivation Key Index
04-08 Card Verification Result (CVR) *
09-16 Card counters area
17 Length of Issuer Discretionary Data field in IAD. Set to ‘0F’.
18-32 Issuer Discretionary Data area
*Note que são 5 bytes para o CVR na interface contato para transação
doméstica
4.1.5.2 Estrutura 9F10 no Contato Internacional
Byte Descrição
01 Derivation Key Index (DKI)
02 Cryptogram Version Number (CVN)
03-08 Card Verification Result (CVR) **
Issuer Application Data (IAD) – Informação condicional,

09-16
vide template de perso
** Note que são 6 bytes para o CVR na interface contato para transação internacional
4.1.5.3 Estrutura 9F10 no Sem Contato para Doméstico e Internacional
Byte Descrição
03-10 Card Verification Result (CL-CVR) ***
Issuer Application Data (IAD)
Estrutura do IAD
11-16 Cartão Vide template de perso do cartão
Byte 11 Valor da tag ‘DC’
Mobile Byte 12-14 Valor fixo ‘000000’
Byte 15-16 Valor do Form Factor
***Note que são 8 bytes para o CVR na interface sem contato, para transação
doméstica e internacional
4.1.5.4 Form Factor (parte da tag ‘9F10’)
O Form Factor é parte do Issuer Discretionary Data do Issuer Application Data (9F10),
quando ativado/presente na tag IADOL da aplicação de pagamento.
A posição varia de acordo com a interface:
• Contato vide template de Personalização, particularizado por Emissor

• Sem contato vide estrutura da tag 9F10
Form
Descrição Interface
Factor
00 Contact Interface (Contact-only Card) Contact
10 Contactless Interface (Dual-Interface Card) Dual-Interface
Contactless Interface (Contactless-only

11 Contactless
Card)
20 Contactless Interface (Mobile HCE) Contactless
Contactless Interface (Mobile APAY-

2ª Contactless
Google)
Contactless Interface (Mobile SPAY-

2F Contactless
Samsung)
2E Contactless Interface (Mobile EPAY-Apple) Contactless
Aplication Descrição
00 Não informado na tag 9F10 (não utilizado)
10 Crédito
11 Débito
Detalhamento do CVR (Card Verfication Results)
O Card Verification Results (CVR) é um elemento EMV com informações proprietárias

da aplicação de pagamento, sendo distinto por tipo de transação (Doméstico e
Internacional), Interface (Contato, sem contato) e Origem (Cartão, Dispositivo).
Este elemento é utilizado para informar ao emissor o status do cartão para

determinadas condições ocorridas durante as transações. Em tempo de autorização
da transação, este dado é transmitido como parte do Issuer Application Data ‘IAD’ da
TAG ‘9F10’, contida no DE55.
CVR Doméstico para Contato – Byte 1
Abaixo, informamos o mapa de bits do CVR gerado durante o 1st GAC, detalhando as
possibilidades por status presentes nesta TAG durante a autorização da transação pelo
Host.
Application Cryptogram type returned in 2nd GENERATE AC
Nota: Em tempo de verificação para autorização da transação online

8-7
(Byte1, Bit 6-5 com valor ‘10’), o valor esperado para este status é
‘10’.
1
Application cryptogram type returned in 1st GENERATE AC
6-5
Nota: Em tempo de verificação para autorização da transação online, o
valor esperado para este status é ‘10’.
1= CDA performed [1st or 2nd Generate AC]
Notas:
• Quando o cartão e terminal estiverem mutuamente aptos a

realizar esta verificação, o valor ‘1’ é esperado.
• Para verificar a capacidade do cartão, vide Template de
4
Personalização Elo.
• Para comparar o status do terminal, vide TVR (Byte1, Bit3 com
valor ‘1’)
• Cabe ao emissor, decidir a obrigatoriedade do CDA quando a
realização deste for possível pelo Cartão e não for possível pelo
Terminal.
1 = Offline DDA performed
Notas:
• Quando o cartão e terminal estiverem mutuamente aptos a

3
realizar esta verificação, o valor ‘1’ é esperado.
• Para verificar a capacidade do cartão, vide Template de
Personalização Elo.
• Para comparar o status do terminal, vide TVR (Byte1, Bit4 com
valor ‘1’)
• Cabe ao emissor, decidir a obrigatoriedade do DDA quando a

realização deste for possível pelo Cartão e não for possível pelo
Terminal.
1 = Issuer authentication not performed

2
(Byte1, Bit6-5 com valor ‘10’), o valor esperado para este status é
‘0’.
1 = Issuer authentication failed

1
(Byte1, Bit6-5 com valor ‘10’), o valor esperado para este status é
‘0’.
Low order nibble of PIN try counter
8-5 Nota: Valor residente no cartão para o “Pin Try Counter”, informação
relevante para gerenciamento do PIN Offline.
1 = Offline PIN verification performed (Plaintext or Enciphered)
Notas:
• Status para informar o modo em que o PIN foi verificado pelo

Cartão.
2 4
• O Modo “Enciphered” é possível somente em cartões CDA ou
DDA.
• O Terminal pode ou não suportar este tipo de verificação.
• Recomenda-se verificar o Template de Personalização Elo para
verificar se esta funcionalidade está ativada para o cartão.
1 = Offline PIN verification performed and not successfully verified
3 Nota: Status para informar que o PIN foi inserido no POS e negado pelo
Cartão.
1 = PIN try limit exceeded
Notas:
• Status para informar que a quantidade de PIN validado off-line

excedeu o limite previsto pelo Emissor na geração do cartão.
• Quando as tentativas de validação off-line do PIN excederem o

limite do Cartão. Haverá dois comportamentos no CVR para
transações oriundas do POS, conforme abaixo:
o Cenário A – O portador digita o PIN (inválido) pela
quarta vez em uma mesma transação.
2
Quando a tentativa de validação de senha Offline esgotar
o “PIN try counter” de forma consecutiva o cartão irá
solicitar a quarta tentativa do PIN para validação Online e
ativar os bits 2, 3 e 4 do CVR.
o Cenário B – O portador não digita o PIN pela quarta vez

e retira o cartão do terminal
Caso o cartão seja retirado do terminal após 3ª tentativa,

a 4ª tentativa em diante irá registrar no CVR este bit
com valor ‘1’ e os bits 4 e 3 com valor ‘0’. Independente
se o PIN digitado está correto neste momento.
• Quando excedido, recomenda-se reiniciar o “PIN try counter”

via CSU ou Script Command.
1 = Last online transaction not completed
1 Nota: Informação referente a última tentativa de transação Online,

indicando se esta foi interrompida.
Este byte contém dados proprietários Elo nos bits 4 à 1, enquanto os bits
restantes foram definidos pela EMVCo.
Recomendamos verificar sistematicamente o bit 3 deste byte (em vermelho).

Trata-se de uma particularidade Elo desenvolvida para identificar ataque do
tipo “man-in-the-middle”.
8 1 = Lower Consecutive Offline Transaction limit exceeded (LCOL)
7 1 = Upper Consecutive Offline Transaction limit exceeded (UCOL)
6 1 = Lower Cumulative Offline Transaction Amount limit exceeded (LCOTA)
5 1 = Upper Cumulative Offline Transaction Amount limit exceeded (UCOTA)

3
4 1 = Maximum Transaction Amount Limit [MTAL] exceeded
3 1 = Terminal erroneously considers PIN Verification successful
2 1 = Wrong Profile Selection Table structure
1 1 = Profile selected using the Profile Selection Table
Tabela 1: CVR – byte 3
• Bits 8 à 4
o Estes bits indicam o status para cada contador e limitador Offline
(gerenciamento de risco do cartão com perfil de operação Offline)
o Para transações financeiras (amount > 0) com cartões SDA, estes
indicadores sempre estarão ativados (valores excedidos).
o Para transações financeiras (amount > 0) com cartões DDA/CDA, estes

indicadores serão ativados conforme limitadores definidos pelo Emissor
pelo template de personalização Elo.
o Note que em autorizações (amount = 0) estes bits não serão ativados.
• Bit 3
o A aplicação do cartão Elo é capaz de verificar se o terminal considerou o PIN
validado indevidamente pelo POS.
o Ocorre quando as informações comunicadas pelo terminal relacionadas à
verificação do titular do cartão, não estão de acordo com o indicador da
validação do PIN Offline da transação atual. Esta verificação usa o elemento
“CVM Results”.
o Identificador do tipo de fraude conhecida como “Man-in-the-middle”
• Bit 2
o Caso este bit esteja com valor ‘1’, pode ter ocorrido uma falha de
personalização dos dados do cartão, seja uma alteração indevida de estrutura
via Script Command ou na origem (bureaux/Personalizadora).
• Bit 1
o Indicativo proprietário Elo, o status neste campo não tem relevância para
autorização da transação.
CVR Doméstico para Contato – Bytes 4 e 5
Low order nibble of Issuer Script Counter

4 8-5
Notas:
• Contador residente no cartão para indicar a quantidade de scripts

recebidos e processados
• Trata-se de um informação relevante para gerenciamento das
informações constantes no cartão, como a administração dos
limitadores Offline.
• Na autorização, o olhar sobre esta informação é recomendado.
1 =Issuer script processing failed on previous transaction
Notas:
• Status para indicar a que houve envio de script na última
4 transação, e que o mesmo foi rejeitado.

• Trata-se de um informação relevante para gerenciamento das
informações constantes no cartão, como a administração dos
limitadores Offline.
• Na autorização, o olhar sobre esta informação é recomendado.
1 = Offline Data Authentication failed on previous transaction
Nota: Recomendamos avaliar esta informação (SDA, DDA ou CDA falhou).

3
A frequência ininterrupta indicará um problema atual no certificado
ou nos dados do cartão. Caso contrário, pode ser uma situação pontual no
terminal da transação anterior.
1 = Go online on next transaction was set
Notas: Trata-se de um status do cartão indicando que houve solicitação

para envio da transação Online em dois momentos:
2 o Durante a primeira utilização, quando o emissor suportar a

ativação do cartão (vide template de personalização)
o Nas demais transações, este status indica que houve
requisição via CSU (da transação anterior) para verificar
online a transação corrente.
1= Unable to go online
1 Nota: Status indicando que houve tentativa de envio da transação anterior

online, porém, sem sucesso.
5 8-1 RFU (‘00’)
CVR Internacional para Contato – Bytes 1 a 6
1 8-7 Em tempo de verificação para autorização da transação online (Bit

6-5 com valor ‘10’), o valor esperado para este status é ‘10’.
Application cryptogram type returned in 1st GENERATE AC
6-5 Em tempo de verificação para autorização da transação online, o

4-1 RFU: ‘0000’
8 1 = DDA Returned (if supported by card)
7 1 = CDA returned in 1st GENERATE AC (if supported by card)
6 1 = CDA returned in 2nd GENERATE AC (if supported by card)
5 1 = Off-line PIN Verification performed

2
4 1 = Off-line Enciphered PIN Verification performed (if supported by card)
3 1 = Off-line PIN Verification Successful
2 1 = CAC-default ignored with CAT3 terminal
1 RFU: ‘0’
8-
Right nibble of Script Counter
5
3
4-
Right nibble of PIN try Counter
1
8 Unable to go on-line during previous transaction
7 Issuer Authentication not performed during previous online transaction.

4
6 Issuer Authentication failed during previous transaction
5 Script received on previous transaction
4 Script failed on previous transaction
3 PTH forced on-line (‘Go online next transaction’)
2 PDOL forced on-line (during GPO)
1 PDOL forced decline (during GPO)
8 Invalid PDOL check
7 Off-line PIN verification failed
6 PIN Try Limit exceeded
Lower Consecutive Offline Transaction limit exceeded (LCOL).

5
Note: May be profile-specific
Upper Consecutive Offline Transaction limit exceeded (UCOL).

4
5 Note: May be profile-specific
Lower Cumulative Offline Transaction Amount limit exceeded (LCOA).

3
Upper Cumulative Offline Transaction Amount limit exceeded (UCOA).

2
Single Transaction Amount limit exceeded (STA).

1
8- ID of PDOL-Decline or PDOL-Online check that forced the transaction to be

6
5 declined or to go online (Only valid if byte 4, bit 2 or 1 of CVR is set).
4-
Transaction profile Identifier (0000 by default)
1
CL-CVR Doméstico e Internacional para Sem contato – Bytes 1 a 8
O CL-CVR é um elemento de dados proprietário usado para informar ao Emissor o

contexto da transação, a decisão do cartão e as condições de exceção ocorridas
durante a transação atual e anterior. Esse elemento de dados permite que o cartão
tome uma decisão sobre risco aceitável para:
• Processar a transação pela interface sem contato;

• Processar a transação offline;
• Processar a transação sem verificação do titular do cartão (CVM/CD-CVM).
O CL-CVR é transmitido ao emissor como parte do Issuer Application Data (tag 9F10).
Nota: Todos os status podem ser específicos do perfil de personalização (Template).
Decisão do Cartão para o Emissor avaliar
1 = Online PIN Required
1 8
Notas:
• Ocorre quando o gerenciamento de risco do cartão requisita a

verificação do PIN Online, vide bit habilitado na TAG ‘DF34’ do
Card Profile.
• O Terminal também pode requisitar a verificação do PIN Online,
conforme o gerenciamento de risco estabelecido pelo adquirente
responsável pelo Terminal.
1 = Signature Required
Notas:
7 verificação da Assinatura, vide bit habilitado na TAG ‘DF35’ do

Card Profile.
• O Terminal também pode requisitar a verificação da Assinatura,
00 = AAC (Transação negada offline pelo Cartão)
01 = TC (Transação aprovada offline pelo Cartão)
10 = ARQC (Transação enviada online para validação do Emissor)

6 -5
11 = RFU (Reservado para uso futuro)
Nota:
• Refere-se a análise de risco gerenciada pelo Cartão, quando a

decisão final sobre Negar Offline, Aprovar Offline ou enviar a
transação Online para validação do Emissor.
1 = PID Limit reached - Transaction approved by reader
4 Nota: Recurso referente à programas de Fidelidade gerenciados pelo Cartão.

Não utilizado pela Elo.
XXX = Script Counter
3-
Nota: Indica o número do script processado durante a última transação
1
contato ou sem contato realizada.
Comparativo entre as TAGS do CAC-CRM e do CAC-CVM
1 = Online Cryptogram Required
Nota:
8 • Requisita a validação transacional com criptograma (TAG 9F26)

presente.
• Se o gerenciamento de risco do cartão não julgar necessário, então
o leitor é habilitado para offline e suporta CDA
1 = Transaction Type required to be processed online with online PIN

CVM
Nota:
7
• Ocorre quando o tipo de transação (Transaction Type) foi
configurado pelo cartão, exigindo o processamento da validação
transacional Online com a verificação do PIN Online.
• Exemplo: compras com reembolso, recarga pré-pago, etc.
1 = Transaction Type required to be processed offline without any

CVM
6
Nota:

configurado pelo cartão, permitindo o processamento da validação
transacional Offline sem a verificação do PIN Online.
• Exemplo: transação de reembolso, pré-pago, emissão de bilhetes,
consulta de saldo offline, etc.
1 = Domestic Transaction
Nota:
5 • Indica se a transação ocorreu em ambiente Doméstico

• A configuração da TAG CL-ACO (vide B1b1) define se o cartão fará
uso do Country Code ou Currency Code para este bit. A
configuração padrão da Elo usa Country Code.
1 = International Transaction
Nota:
4 • Indica se a transação ocorreu em ambiente Internacional.

1 = PIN Try Limit exceeded (Dual-Interface implementation only)
Nota:
• Adicionalmente informa se o “PIN try Limit” da interface de contato

está excedido no cartão.
1 = Confirmation Code Verification performed (Mobile

implementation only)
Nota:
2
• Indica se o Confirmation Code foi requisitado pelo dispositivo.
• O Bit só estará presente quando o Confirmation Code Flag for igual
a ‘1’.
1 = Confirmation Code Verification performed & failed (Mobile

1
Nota:
• Indica se que o Confirmatio Code foi requisitado e falhou.

• O Bit só estará presente quando o Confirmation Code Indicator for
igual a ‘1’
Ações do CVM (Cardholder Verification Method)
1 = CVM Required
Nota:
8
• Indica que o CVM foi solicitado no ato de uma transação, com base
no valor “Reader Contactless CVM” configurado no Terminal.
‘RFU’ (Contactless Card)
‘CD-CVM Local Validation Performed’ (Contactless Mobile / Device

Application)
3
Nota:
7
• Cartão: Não usado (RFU) para cartões Dual-Interface ou apenas
sem contato
• Mobile: Quando a implementação é MOBILE, indica que o
dispositivo realizou o CD-CVM durante a transação.
6 Consecutive CVM Transaction limit 1 exceeded (CVM-Cons 1)
4 Cumulative CVM Transaction Amount limit 1 exceeded (CVM-Cum 1)
2 CVM Single Transaction Amount limit 1 exceeded (CVM-STA 1)
• Bits 6 a 1
o Estes bits indicam o status de cada Contador, acumulador e Limitador
quanto ao Método de Verificação do Portador (CVM) configurado no
cartão. Vide Card Profile para maiores detalhes.
Ações do CRM (Card Risk Management) Parte ½
1 = CDA failed during previous Contactless transaction
Nota:
8
• Indica quando o CDA foi performado na transação anterior, porém
houve falha na validação.
1 = Last Contactless transaction not completed
7 Nota:
• Indica quando houve tentativa de transação anterior, sem sucesso.

4
1 = “Go on-line next transaction” was set by Contact or Contactless

application
Nota:
6 • Indica que algum controlador, limitador e/ou acumulador do cartão

foi excedido em transações anteriores.
• Este indicador também segue ativo (valor = 1) quando o CSU
recebido em transação anterior requisitou “Go on-line next
transaction”
1 = Issuer Authentication failed during previous Contact or

Contactless transaction
5 Nota:
• Indicador que a transação anterior não foi concluída ou foi

concluída e houve falha na autenticação Online.
1 = Script failed on previous Contact or Contactless transaction
Nota:
• Indica que o cartão recebeu um ou mais “Script Command” do Host

4
de Autorização na transação anterior e houve falha no
processamento deste(s) script(s).
• A rejeição de um Script Command não representa que a transação
anterior tenha sido Declinada pelo Cartão.
1 = Invalid PDOL check
Nota:
3
• O PDOL check é uma funcionalidade que habilita a Bandeira e
Emissor especificarem condições de Autorização Transacional,
permitindo a escolha de um perfil (Card Profile) especifico para
Declinar, Aprovar ou Requisitar Aprovação Online da transação.
• Esta funcionalidade é específica por Card Profile, este bit segue com
valor ‘1’ quando ocorrer uma inconsistência na fase GPO da
transação sem contato
1 = PDOL forced online (during GPO)
Nota:
2
• Quando a configuração do PDOL requisita que a transação seja
validada sistematicamente Online.
1 = PDOL forced decline (during GPO)
Nota:
1
negada sistematicamente.
Ações do CRM (Card Risk Management) Parte 2/2
8 Consecutive Contactless Transaction limit exceeded (CL-Cons)
7 Cumulative Contactless Transaction limit exceeded (CL-Cumul)
6 Single Contactless Transaction Amount limit exceeded (CL-STA)
5 Lower Consecutive Offline Transaction limit exceeded (LCOL)

5
4 Upper Consecutive Offline Transaction limit exceeded (UCOL)
3 Lower Cumulative Offline Transaction Amount limit exceeded (LCOA)
2 Upper Cumulative Offline Transaction Amount limit exceeded (UCOA)
1 Single Transaction Amount limit exceeded (STA)
• Bits 8 a 1
o Estes bits indicam o status de cada Contador, Acumulador e Limitador
quanto ao Gerenciamento de Risco Transacional (CRM) configurado no
Informações para o Emissor
XXXX = ID of PDOL-Decline or PDOL-Online check that forced the

8-
6 transaction to be declined or to go online
5
Nota:
• Bit ativo (valor = 1) apenas quando o B4b1 ou B4b2 do CL-CVR

estiver com ‘1’
XXXX = Transaction profile Identifier
Nota:
4-
• ‘0000’ = valor padrão
1
• Funcionalidade disponível para cartões com mais de um Perfil
Transacional habilitado. Qualquer valor diferente de ‘0000’ indica o
perfil que foi atribuído pelo PDOL durante a transação.
Informações do TTQ para o Emissor
8 1 = EMV contact chip supported
7 1 = Offline Contactless Reader
6 1 = Online PIN supported
7
5 1 = Signature supported
4 1 = Issuer Update Processing supported
3-
RFU (Slot reservado para uso futuro)
1
• Bits 8 a 1
Estes bits indicam a capacidade do processamento do Terminal
Informações do PID para o Emissor
XX = Program ID
8- Nota: Recurso referente à programas de Fidelidade gerenciados pelo Cartão.

8
1 Não utilizado pela Elo.
Detalhamento do TVR (Terminal Verfication Results)
O Terminal Verification Results é o status do Terminal sobre a transação corrente, esta

TAG é transmitida no DE55 pela TAG 95.
Ratificamos a importância da comparação entre os indicadores similares do CVR e TVR

para identificação de fraudes (exemplo: wedge attack/man-in-the-middle).
Dentre as diversas informações do TVR, destacamos:
4.9.1 TVR – Byte 1
1 = Offline data authentication was not performed
Nota: Este status indica que não houve a realização do O.D.A.,

8
recomenda-se verificar se o cartão é um produto com validação off-
line SDA, DDA ou CDA.
1 = SDA failed
Notas:
1 • A verificação off-line foi realizada e houve erro na validação. Cabe

ao Emissor decidir sobre a autorização da transação com este
status ativo, bem como avaliar a frequência deste evento para
7
antecipar possíveis problemas.
• Causas prováveis:
o Erro nos dados assinados no cartão;
o Falha/ausência da carga de chaves públicas Elo no
terminal;
o Alteração indevida/não autorizada nos dados assinados do
cartão.
1 = ICC data missing

6
Nota: Dado que o gerenciamento de risco é particular por Emissor, este

indicador pode ser ou não ‘1’. Vide template de personalização Elo
para verificar se este status é esperado para o produto.
5 1 = Card appears on terminal exception file
1 = DDA failed
Notas:
• A verificação off-line foi realizada e houve erro na validação. Cabe

4 antecipar possíveis problemas.
terminal;
cartão, seja na personalização, na transação (man-in-the-
middle) ou por Script.
1 = CDA failed
Notas:
3 • A verificação off-line foi realizada e houve erro na validação. Cabe


terminal;
2-1 RFU
4.9.2 TVR – Byte 2
8 1 = ICC and terminal have different application version
7 1 = Expired Application
6 1 = Application not yet effective
1 = Requested service not allowed for card product
2 5
Nota: Status ativo quando um serviço do terminal (Saque, Compra ou
Serviços) for requisitado pelo Portador e este não for permitido para o
cartão/produto. Vide TAG 9F07 do template de personalização Elo.
1 = New Card
4
Nota: Para os cartões Elo este valor sempre será “0” no TVR, recomenda-
se verificar o status equivalente do CVR para verificar esta condição.
3-
RFU
1
4.9.3 TVR – Byte 3
1 = Cardholder verification was not successful
3 8
Notas:
• Status ativo quando todos os métodos de validação do Portador,

presentes no cartão pela TAG “CVM List (8E)” falharem e/ou não
forem mutuamente aceitos entre Terminal e Cartão
• Recomenda-se verificar a igualdade de status no bit
correspondente do CVR.
1 = Unrecognised CVM
7
Nota: Status ativo quando todos os métodos de validação do Portador,
presentes no cartão pela TAG “CVM List (8E)” não forem
reconhecidos pelo Terminal.
1 = Pin try limit exceeded
Notas:

6
• Recomenda-se avaliar este status, em concordância com os status
de PIN do CVR, a fim de detectar discrepâncias entre Cartão e
Terminal para validação de PIN, sinalizando um possível ataque
“man-in-the-middle”.
1 = Pin entry required and Pin pad not present or not working
5 Notas:
• Status para informar que o PIN Pad (teclado) não está funcional.
• Recomenda-se verificar os métodos suportados pelo cartão como
base para autorização.
1 = Pin entry required, Pin pad present, but Pin was not entered
Notas:
4 • Cabe ao emissor decidir se a digitação do PIN é obrigatória ou não.

1 = Online Pin entered
Notas: Recomenda-se avaliar este status, em concordância com os status de

3
PIN do CVR, a fim de detectar discrepâncias entre Cartão e Terminal para
validação de PIN, sinalizando um possível ataque “man-in-the-middle”.
2-1 RFU
4.9.4 TVR – Bytes 4 e 5
1 = Transaction exceeds floor limit

4 8
1 = Lower consecutive offline limit exceeded
Nota: Para cartões Elo que verificam somente SDA e tem presença
7
desta TAG em sua estrutura, este valor sempre será ‘1’.
Vide Template de Personalização Elo.
1 = Upper consecutive offline limit exceeded
6
1 = Transaction selected randomly for online processing

5
1 = Merchant forced transaction online

4
3-1 RFU
Default TDOL used

5 8
Issuer authentication failed

7
Script processing failed before final GENERATE AC

6
Script processing failed after final GENERATE AC

5
3-1 RFU
Validação de Criptograma (ARQC/ARPC) Tipo 05
A validação dos criptogramas gerados pelo cartão e pelo emissor (EMV - full
grade) é necessária para a prevenção contra tentativas de fraude em transações
bancárias.
O Criptograma Tipo 5 é aplicável somente para transações na interface com

contato.
4.10.1 ARQC - Authorization Request Cryptogram
O criptograma ARQC é gerado pelo cartão durante o 1st Generate AC, quando
a decisão do Cartão for ‘ir online’ este Criptograma é enviado para o emissor
através do DE55 (tag ‘9F26’).
Trata-se de um valor único por transação, portanto, é mandatório para o

Emissor a validação desta TAG.
4.10.1.1 Cálculo para ARQC Doméstico e ARQC Internacional
O algoritmo para o ARQC está especificado no documento EMV Book 2, Parte

IV, seção 8.1.2 “Application Cryptogram Algorithm”. Este algoritmo é comum
para validação do criptograma gerado pela aplicação doméstica e internacional.
4.10.2 ARPC - Authorization Response Cryptogram
O criptograma ARPC tem por finalidade provar ao cartão que a resposta da

transação provém de uma fonte fidedigna (Host Autorizador). Este valor é
gerado pelo emissor e enviado para o cartão na tag 91 (IAD - Issuer
Authentication Data), conforme os formatos apresentados abaixo,
respectivamente para as aplicações doméstica e internacional.
4.10.2.1 Formato Doméstico
TAG 91 – Issuer Authentication Data
Bytes Descrição
1–4 ARPC
5–8 CSU
Proprietary Authentication Data (Informação condicional, vide

8 - 16
template de perso).
4.10.2.2 Formato Internacional
Bytes Descrição
1-8 ARPC
9 - 10 CSU
O criptograma ARPC é verificado pelo cartão, permitindo que o mesmo negue

ou aprove a transação no 2nd Generate AC. Caso o cartão não reconheça o
ARPC, a transação será a negada mesmo que o Authorization Response Code
da Mensagem de Autorização seja “00 - Aprovado”. Ocorrendo desta forma o
Desfazimento da Transação.
4.10.2.3 Cálculo para ARPC Doméstico
A geração do ARPC para a aplicação doméstica, consiste em computar os 04

bytes do ARQC concatenados com CSU Doméstico, conforme especificado no
documento EMV Book 2, seção “ARPC Method 2”.
Nota: Um exemplo do cálculo do ARPC doméstico pode ser obtido através do e-

mail tecnologia@cartaoelo.com.br.
4.10.2.4 Cálculo para ARPC Internacional
A geração do ARPC para a aplicação Internacional, segue os 3 passos abaixo:
a) Concatenar o CSU Internacional adicionando 6 bytes com valor '00' à

direita do CSU, obtendo:
X = (CSU || '00'|| '00' || '00' || '00' || '00' || '00')
b) Calcular:
Y = ARQC EOR X.
c) Calcular o ARPC Como segue,

ARPC = DES3 (SKAC) [Y]
Nota: Um exemplo do cálculo do ARPC internacional pode ser obtido através do

e-mail tecnologia@cartaoelo.com.br.
bancárias.
O Criptograma Tipo 15 é aplicável somente para transações na interface sem

contato.
4.11.1 Cálculo para ARQC Doméstico e ARQC Internacional
A geração do ARQC para interface sem Contato, cuja versão do Criptograma é

15, segue abaixo:
a) Diversificar a MKac, conforme EMV Book 2, seção A1.4.1 “Option A”.

a. O resultado é o DKac
b) Gerar a chave de sessão, conforme EMV Book 2, seção A1.3.1

a. O resultado é o SKac
c) Concatenar a informação abaixo, oriunda do DE55, gerando o

“Cryptogram Input Data”:
a. 9F02 - AMOUNT AUTHORIZED
b. 5F2A - TRANSACTION CURRENCY CODE
c. 9F37 - UN
d. 9F36 - ATC
e. 9F10 - ISSUER APPLICATION DATA
d) ARQC: MAC(SKac) [Cryptogram Input Data]
Nota: Um exemplo do cálculo do ARQC pode ser obtido através do e-mail

tecnologia@cartaoelo.com.br.
Validação do Criptograma (DCVV) Transações ZIP Mode
A validação do criptograma gerado é necessária para a prevenção contra

tentativas de fraude em transações bancárias.
O Criptograma do Tipo DCVV é aplicável somente para transações na interface

sem contato e internacional.
4.12.1 DCVV – Dynamic Card Verification Value
O DCVV é gerado pela interface sem contato D-PAS como um valor exclusivo
para cada transação.
É mandatório para o Emissor a validação desta TAG.
4.12.2 Cálculo para DCVV Internacional
O algoritmo para o cálculo do DCVV é o seguinte:
• Calcule o Track Data Hash concatenando da esquerda para a direita os

dígitos decimais do PAN com a Data de Vencimento. Se o PAN tiver um
número ímpar de dígitos decimais, será preenchido à esquerda com
zero. Execute um cálculo SHA-1 e mantenha os 2 bytes mais à esquerda.
Track Data Hash Darivation Data = [PAN || Data de Vencimento]
Track Data Hash = SHA-1 [Track Data Hash Darivation Data] (considerar
os 2 bytes à esquerda)
• Calcule o DCVV da seguinte maneira:
DCVV Derivation Data = 2-bytes ATC || 1-byte Unpredictable Number ||
1-byte ~Unpredictable Number || 2-bytes Track Data Hash || 2-bytes

~ATC
DCVV = DES3 (AUKDCVV) [DCVV Derivation Data] (considerar os 3

bytes mais à esquerda, cada valor de byte mod 10)
O cartão calcula o DCVV na etapa Initiate Application Processing. Ele armazena

o resultado na tag 9F7E no Registro 1 do SFI 1, a ser recuperado pelo leitor. O
leitor insere o DCVV nos dados da trilha.
Para autenticar o cartão, o sistema de autorização extrai o Unpredictable

Number e o ATC dos dados da trilha, calcula o Track Data Hash, calcula o
AUKDCVV (conforme descrito na seção 7.1.2) e calcula o DCVV conforme
descrito nesta seção. Os resultados são usados para comparar o DCVV
calculado com o DCVV nos dados da trilha. Se o DCVV calculado não for igual
ao DCVV nos dados da faixa, o sistema de autorização deverá recusar a
transação.
Nota: Um exemplo do cálculo do DCVV pode ser obtido através do e-mail

4.12.3 Método de derivação para chave AUKDCVV
O emissor deve gerar e manter uma Issuer Master Key para DCVV (IMKDCVV)
para derivar uma Account Unique Key para DCVV (AUKDCVV). O AUKDCVV é a
ICC Key criada para gerar o DCVV.
O algoritmo para derivar o AUKDCVV é descrito abaixo. Uma criptografia

Triple-DES é executada dependendo do comprimento da chave IMKDCVV.
• Concatene da esquerda para a direita os dígitos decimais do PAN com

a Data de Vencimento, o inverso do PAN, o inverso da Data de
Vencimento. Se o PAN tiver um número ímpar de dígitos decimais, será
preenchido à esquerda com zero. Concatene com o indicador de
preenchimento variável de 1 byte '80' e o menor número de bytes '00'
para obter um comprimento múltiplo de 8 bytes para a criptografia
3DES-CBC.
AUKDCVV Derivation Data = PAN || Data de Vencimento || ~PAN ||

~Data de Vencimento || '80' || '00' adicionados para tornar o
comprimento total dos dados de derivação múltiplo de 8.
• Calcule os dados de derivação obtidos como seguintes:
AUKDCVV = DES3-CBC (IMKDCVV) [AUKDCVV Derivation Data]
O Key Checksum Value pode ser calculado da seguinte forma:
AUKDCVV KCV Derivation Data = '00 00 00 00 00 00 00 00 00'
AUKDCVV KCV = DES3-ECB (AUKDCVV) [AUKDCVV KCV Derivation

Data] considerar os 3 bytes à esquerda.
Recomendações adicionais para autorização.
No intuito de detectar um possível ataque “man-in-the-middle” quanto ao

Offline PIN, recomendamos validar:
• O CVR da aplicação Elo Domestico tem um recurso exclusivo para

detectar este tipo de ataque.
o Byte 3, bit 3 do CVR com valor ‘1’.
• Na ausência do CVR acima (ex.: aplicação internacional), realizar a

avaliação das TAGS 9F34 (CVM Results) e 9F33 (Terminal Capabilities) do
DE55.
o 9F34: Esta TAG indicará se o Offline PIN foi verificado, o CVR
deverá indicar o mesmo.
o 9F33: Esta TAG indicará se o terminal suporta Offline PIN, se o
cartão suportar Offline PIN o TVR deverá indicar que PIN não está
com status “Bypassed” e o CVR também deverá indicar que o
Offline PIN foi verificado com sucesso.
Modelo de Implementação Elo 2.0
Elementos EMV
5.1.1 CVR e TVR
Os elementos Card Verification Results (CVR) e Terminal Verification Results (TVR) são
fontes de informações importantes para verificação da transação corrente.
Recomenda-se avaliar todos os status (bits), bem como compará-los entre estas duas
TAGS para obter a melhor avaliação para decisão.
5.1.2 ATC
O ATC (Application Transaction Counter) é um contador gerado pela aplicação de

pagamento a cada tentativa de transação, sendo que este valor é enviado no DE55
para transações presenciais com Chip, no DE122 para transações in-app ou nas
Trilhas para transações do tipo ZIP/MST, permitindo ao Emissor o acompanhamento
da evolução incremental deste contador e a detecção de Fraudes como o Replay-
Attack.
O modelo de implementação Elo 2.0 possui a seguinte estrutura de ATC:
1 ATC para aplicação Crédito, Doméstico e Internacional, Contato, Sem Contato e Zip
Mode.
1 ATC para aplicação Débito, Doméstico e Internacional, Contato e Sem Contato.
5.1.3 CVM (Cardholder Verification Method) List
O “CVM List” está presente no cartão e é definido no template Elo, este contém as
instruções para verificação do portador (Como, Onde e Quando). Confrontar este
valor e suas possibilidades com os status equivalentes no CVR e TVR são
recomendados para identificar ataques do tipo “man-in-the-middle”.
5.1.4 CD-CVM ‘DC’
O “Consumer Device - Cardholder Verification Method” está presente em transações

sem contato ou CNP (in-app) quando realizadas/autenticadas por um dispositivo,
indicando o método aplicado. Esta TAG estará contida no IAD da TAG 9F10 para
transações sem contato.
0001 = NFC 0100 = IN APP
0010 = BLE 0101 = 3D – Secure

8-4
0011 = QR
Code
01 0000 = No 0011 = 0110 = Facial

CD CVM Pattern recognition
0001 = 0100 = 0111 = Local

4-1
Password Crypto PIN Passcode 5.1.5 Issuer
Application Data
0010 = 0101 = Retina 1000 = Other
(IAD) ‘9F10’
Fingerprint Scan biometric
O IAD contém dados
proprietários da aplicação Elo a serem transmitidos ao Emissor em uma transação
online (no pedido de autorização) e após a conclusão da transação na Liquidação.
Esta tag é a concatenação dos elementos de dados internos do cartão listados nas
tabelas a seguir e no IDD.
Se presente, o IDD permite que a aplicação transmita dados adicionais online para
tags que não estão disponíveis na solicitação de autorização, através do IADOL.
Formato: binário, comprimento variável (até 32 bytes)
5.1.5.1 Estrutura 9F10 no Contato Doméstico e Internacional
Byte Descrição
03-08 Card Verification Result (CVR)
Issuer Application Data (IAD) – Informação condicional,

09-16
vide template de perso
5.1.5.2 Estrutura 9F10 no Sem Contato para Doméstico e Internacional
Byte Descrição
03-10 Card Verification Result (CL-CVR) ***
Issuer Application Data (IAD)
11-16
Estrutura do IAD
Cartão Vide template de perso do cartão
Byte 11 Valor da tag ‘DC’
Mobile Byte 12-14 Valor fixo ‘000000’
Byte 15-16 Valor do Form Factor
*** Note que são 8 bytes para o CVR na interface sem contato, para transação
doméstica e internacional
5.1.5.3 Form Factor (parte da tag ‘9F10’)
O Form Factor é parte do Issuer Discretionary Data do Issuer Application Data (9F10),
quando ativado/presente na tag IADOL da aplicação de pagamento.
A posição varia de acordo com a interface:
• Contato vide template de Personalização, particularizado por Emissor

• Sem contato vide estrutura da tag 9F10
Form
Descrição Interface
Factor
00 Contact Interface (Contact-only Card) Contact
10 Contactless Interface (Dual-Interface Card) Dual-Interface
Contactless Interface (Dual-Interface Card

13 Dual-Interface
Modelo Elo 2.0)
11 Contactless Interface (Contactless-only Card) Contactless
20 Contactless Interface (Mobile HCE) Contactless
2A Contactless Interface (Mobile APAY-Google) Contactless
2F Contactless Interface (Mobile SPAY-Samsung) Contactless
2E Contactless Interface (Mobile EPAY-Apple) Contactless
Aplication Descrição
00 Não informado na tag 9F10 (não utilizado)
10 Crédito
11 Débito
Detalhamento do CVR (Card Verfication Results)
O Card Verification Results (CVR) é um elemento EMV com informações proprietárias

da aplicação de pagamento, sendo distinto por tipo de transação (Doméstico e
Internacional), Interface (Contato, sem contato) e Origem (Cartão, Dispositivo).
Este elemento é utilizado para informar ao emissor o status do cartão para

determinadas condições ocorridas durante as transações. Em tempo de autorização da
transação, este dado é transmitido como parte do Issuer Application Data ‘IAD’ da TAG
‘9F10’, contida no DE55.
CVR Doméstico e Internacional para Contato – Bytes 1 a 6
8-7 Em tempo de verificação para autorização da transação online (Bit

6-5 com valor ‘10’), o valor esperado para este status é ‘10’.
1 Application cryptogram type returned in 1st GENERATE AC
6-5 Em tempo de verificação para autorização da transação online, o

4-1 RFU: ‘0000’
8 1 = DDA Returned (if supported by card)
7 1 = CDA returned in 1st GENERATE AC (if supported by card)
2 6 1 = CDA returned in 2nd GENERATE AC (if supported by card)
5 1 = Off-line PIN Verification performed
4 1 = Off-line Enciphered PIN Verification performed (if supported by card)
3 1 = Off-line PIN Verification Successful
2 1 = CAC-default ignored with CAT3 terminal
1 RFU: ‘0’
8-
Right nibble of Script Counter
5
3
4-
Right nibble of PIN try Counter
1
8 Unable to go on-line during previous transaction
7 Issuer Authentication not performed during previous online transaction.
6 Issuer Authentication failed during previous transaction
5 Script received on previous transaction

4
4 Script failed on previous transaction
3 PTH forced on-line (‘Go online next transaction’)
2 PDOL forced on-line (during GPO)
1 PDOL forced decline (during GPO)
8 Invalid PDOL check
7 Off-line PIN verification failed

5
6 PIN Try Limit exceeded
5 Lower Consecutive Offline Transaction limit exceeded (LCOL).
Upper Consecutive Offline Transaction limit exceeded (UCOL).

4
Lower Cumulative Offline Transaction Amount limit exceeded (LCOA).

3
Upper Cumulative Offline Transaction Amount limit exceeded (UCOA).

2
Single Transaction Amount limit exceeded (STA).

1
8- ID of PDOL-Decline or PDOL-Online check that forced the transaction to be

5 declined or to go online (Only valid if byte 4, bit 2 or 1 of CVR is set).
6
4-
Transaction profile Identifier (0000 by default)
1
CL-CVR Doméstico e Internacional para Sem contato – Bytes 1 a 8
O CL-CVR é um elemento de dados proprietário usado para informar ao Emissor o

contexto da transação, a decisão do cartão e as condições de exceção ocorridas
durante a transação atual e anterior. Esse elemento de dados permite que o cartão
tome uma decisão sobre risco aceitável para:
• Processar a transação pela interface sem contato;

• Processar a transação offline;
• Processar a transação sem verificação do titular do cartão (CVM/CD-CVM).
O CL-CVR é transmitido ao emissor como parte do Issuer Application Data (tag 9F10).
Nota: Todos os status podem ser específicos do perfil de personalização (Template).
Decisão do Cartão para o Emissor avaliar
1 = Online PIN Required
Notas:

1 8
verificação do PIN Online, vide bit habilitado na TAG ‘DF34’ do
Card Profile.
• O Terminal também pode requisitar a verificação do PIN Online,
1 = Signature Required
Notas:
7 verificação da Assinatura, vide bit habilitado na TAG ‘DF35’ do

Card Profile.
• O Terminal também pode requisitar a verificação da Assinatura,
00 = AAC (Transação negada offline pelo Cartão)
01 = TC (Transação aprovada offline pelo Cartão)
10 = ARQC (Transação enviada online para validação do Emissor)
11 = RFU (Reservado para uso futuro)
6 -5
Nota:
• Refere-se a análise de risco gerenciada pelo Cartão, quando a

decisão final sobre Negar Offline, Aprovar Offline ou enviar a
transação Online para validação do Emissor.
1 = PID Limit reached - Transaction approved by reader

4
Nota: Recurso referente à programas de Fidelidade gerenciados pelo Cartão.

Não utilizado pela Elo.
XXX = Script Counter
3-
Nota: Indica o número do script processado durante a última transação
1
contato ou sem contato realizada.
Comparativo entre as TAGS do CAC-CRM e do CAC-CVM
1 = Online Cryptogram Required
Nota:
8 • Requisita a validação transacional com criptograma (TAG 9F26)

presente.
• Se o gerenciamento de risco do cartão não julgar necessário, então
o leitor é habilitado para offline e suporta CDA
1 = Transaction Type required to be processed online with online PIN

CVM
Nota:
7
configurado pelo cartão, exigindo o processamento da validação
transacional Online com a verificação do PIN Online.
• Exemplo: compras com reembolso, recarga pré-pago, etc.
1 = Transaction Type required to be processed offline without any

CVM
6
Nota:

configurado pelo cartão, permitindo o processamento da validação
transacional Offline sem a verificação do PIN Online.
• Exemplo: transação de reembolso, pré-pago, emissão de bilhetes,
consulta de saldo offline, etc.
1 = Domestic Transaction
Nota:
5 • Indica se a transação ocorreu em ambiente Doméstico

1 = International Transaction
Nota:
4 • Indica se a transação ocorreu em ambiente Internacional.

1 = PIN Try Limit exceeded (Dual-Interface implementation only)
Nota:
• Adicionalmente informa se o “PIN try Limit” da interface de contato

está excedido no cartão.
1 = Confirmation Code Verification performed (Mobile

Nota:
2
• Indica se o Confirmation Code foi requisitado pelo dispositivo.
• O Bit só estará presente quando o Confirmation Code Flag for igual
a ‘1’.
1 = Confirmation Code Verification performed & failed (Mobile

1
Nota:
• Indica se que o Confirmatio Code foi requisitado e falhou.

• O Bit só estará presente quando o Confirmation Code Indicator for
igual a ‘1’
Ações do CVM (Cardholder Verification Method)
1 = CVM Required
Nota:
8
• Indica que o CVM foi solicitado no ato de uma transação, com base
no valor “Reader Contactless CVM” configurado no Terminal.
‘RFU’ (Contactless Card)
‘CD-CVM Local Validation Performed’ (Contactless Mobile / Device

Application)
3
Nota:
7
• Cartão: Não usado (RFU) para cartões Dual-Interface ou apenas
sem contato
• Mobile: Quando a implementação é MOBILE, indica que o
dispositivo realizou o CD-CVM durante a transação.
• Bits 6 a 1
quanto ao Método de Verificação do Portador (CVM) configurado no
Ações do CRM (Card Risk Management) Parte ½
1 = CDA failed during previous Contactless transaction
Nota:
8
• Indica quando o CDA foi performado na transação anterior, porém
houve falha na validação.
1 = Last Contactless transaction not completed
7 Nota:
• Indica quando houve tentativa de transação anterior, sem sucesso.

4
1 = “Go on-line next transaction” was set by Contact or Contactless

application
Nota:
6 • Indica que algum controlador, limitador e/ou acumulador do cartão

foi excedido em transações anteriores.
• Este indicador também segue ativo (valor = 1) quando o CSU
recebido em transação anterior requisitou “Go on-line next
transaction”
1 = Issuer Authentication failed during previous Contact or

Contactless transaction
5 Nota:
• Indicador que a transação anterior não foi concluída ou foi

concluída e houve falha na autenticação Online.
1 = Script failed on previous Contact or Contactless transaction
Nota:
• Indica que o cartão recebeu um ou mais “Script Command” do Host

4
de Autorização na transação anterior e houve falha no
processamento deste(s) script(s).
• A rejeição de um Script Command não representa que a transação
anterior tenha sido Declinada pelo Cartão.
1 = Invalid PDOL check
Nota:
3
• O PDOL check é uma funcionalidade que habilita a Bandeira e
Emissor especificarem condições de Autorização Transacional,
permitindo a escolha de um perfil (Card Profile) especifico para
Declinar, Aprovar ou Requisitar Aprovação Online da transação.
• Esta funcionalidade é específica por Card Profile, este bit segue com
valor ‘1’ quando ocorrer uma inconsistência na fase GPO da
transação sem contato
1 = PDOL forced online (during GPO)
Nota:
2
validada sistematicamente online.
1 = PDOL forced decline (during GPO)
Nota:
1
negada sistematicamente.
Ações do CRM (Card Risk Management) Parte 2/2
8 Consecutive Contactless Transaction limit exceeded (CL-Cons)
7 Cumulative Contactless Transaction limit exceeded (CL-Cumul)
6 Single Contactless Transaction Amount limit exceeded (CL-STA)
5 Lower Consecutive Offline Transaction limit exceeded (LCOL)

5
4 Upper Consecutive Offline Transaction limit exceeded (UCOL)
3 Lower Cumulative Offline Transaction Amount limit exceeded (LCOA)
2 Upper Cumulative Offline Transaction Amount limit exceeded (UCOA)
1 Single Transaction Amount limit exceeded (STA)
• Bits 8 a 1
quanto ao Gerenciamento de Risco Transacional (CRM) configurado no
Informações para o Emissor
XXXX = ID of PDOL-Decline or PDOL-Online check that forced the

8-
6 transaction to be declined or to go online
5
Nota:
• Bit ativo (valor = 1) apenas quando o B4b1 ou B4b2 do CL-CVR

estiver com ‘1’
XXXX = Transaction profile Identifier
Nota:
4-
• ‘0000’ = valor padrão
1
• Funcionalidade disponível para cartões com mais de um Perfil
Transacional habilitado. Qualquer valor diferente de ‘0000’ indica o
perfil que foi atribuído pelo PDOL durante a transação.
Informações do TTQ para o Emissor
8 1 = EMV contact chip supported
7 1 = Offline Contactless Reader
6 1 = Online PIN supported
7
5 1 = Signature supported
4 1 = Issuer Update Processing supported
3-
RFU (Slot reservado para uso futuro)
1
• Bits 8 a 1
Estes bits indicam a capacidade do processamento do Terminal
Informações do PID para o Emissor
XX = Program ID
8- Nota: Recurso referente à programas de Fidelidade gerenciados pelo Cartão.

8
1 Não utilizado pela Elo.
Detalhamento do TVR (Terminal Verfication Results)
O Terminal Verification Results é o status do Terminal sobre a transação corrente, esta

TAG é transmitida no DE55 pela TAG 95.
Ratificamos a importância da comparação entre os indicadores similares do CVR e TVR

para identificação de fraudes (exemplo: wedge attack/man-in-the-middle).
Dentre as diversas informações do TVR, destacamos:
5.5.1 TVR – Byte 1
1 = Offline data authentication was not performed
Nota: Este status indica que não houve a realização do O.D.A., recomenda-
8
se verificar se o cartão é um produto com validação off-line SDA, DDA ou
CDA.
1 = SDA failed
Notas:

1 ao Emissor decidir sobre a autorização da transação com este
7
terminal;
cartão.
• RECOMENDAÇÃO: Autorizador não rejeitar a transação de contato
doméstico com CVN 05 devido a falha de SDA/CDA apontada no
TVR. O impacto é minimizado pois a validação do criptograma
garante a segurança fim a fim dos dados do bit 55.
1 = ICC data missing
6
Nota: Dado que o gerenciamento de risco é particular por Emissor, este
indicador pode ser ou não ‘1’. Vide template de personalização Elo
para verificar se este status é esperado para o produto.
5 1 = Card appears on terminal exception file
1 = DDA failed
Notas:

4 o Erro nos dados assinados no cartão;
terminal;
3 1 = CDA failed
Notas:

terminal;
2-1 RFU
5.5.2 TVR – Byte 2
8 1 = ICC and terminal have different application version
7 1 = Expired Application
6 1 = Application not yet effective
1 = Requested service not allowed for card product
5
Nota: Status ativo quando um serviço do terminal (Saque, Compra ou
2 Serviços) for requisitado pelo Portador e este não for permitido para o
cartão/produto. Vide TAG 9F07 do template de personalização Elo.
1 = New Card
4
Nota: Para os cartões Elo este valor sempre será “0” no TVR, recomenda-se
verificar o status equivalente do CVR para verificar esta condição.
3-
RFU
1
5.5.3 TVR – Byte 3
1 = Cardholder verification was not successful
Notas:
8 • Status ativo quando todos os métodos de validação do Portador,

presentes no cartão pela TAG “CVM List (8E)” falharem e/ou não
forem mutuamente aceitos entre Terminal e Cartão
• Recomenda-se verificar a igualdade de status no bit
correspondente do CVR.
1 = Unrecognised CVM
7
3 Nota: Status ativo quando todos os métodos de validação do Portador,
presentes no cartão pela TAG “CVM List (8E)” não forem
reconhecidos pelo Terminal.
1 = Pin try limit exceeded
Notas:

6
1 = Pin entry required and Pin pad not present or not working
Notas:
5
• Status para informar que o PIN Pad (teclado) não está funcional.
• Recomenda-se verificar os métodos suportados pelo cartão como
base para autorização.
1 = Pin entry required, Pin pad present, but Pin was not entered
Notas:
4 • Cabe ao emissor decidir se a digitação do PIN é obrigatória ou não.

1 = Online Pin entered
Notas: Recomenda-se avaliar este status, em concordância com os status de

3
PIN do CVR, a fim de detectar discrepâncias entre Cartão e Terminal para
validação de PIN, sinalizando um possível ataque “man-in-the-middle”.
2-1 RFU
5.5.4 TVR – Bytes 4 e 5
1 = Transaction exceeds floor limit

8
1 = Lower consecutive offline limit exceeded
7
1 = Upper consecutive offline limit exceeded
6
1 = Transaction selected randomly for online processing

5
1 = Merchant forced transaction online

4
3-1 RFU
Default TDOL used

8
Issuer authentication failed

7
5 Script processing failed before final GENERATE AC

6
Script processing failed after final GENERATE AC

5
3-1 RFU
A validação dos criptogramas gerados pelo cartão e pelo emissor (EMV - full grade) é
necessária para a prevenção contra tentativas de fraude em transações bancárias.
O Criptograma Tipo 5 é aplicável somente para transações na interface com contato.
5.6.1 ARQC - Authorization Request Cryptogram
O criptograma ARQC é gerado pelo cartão durante o 1st Generate AC, quando a decisão do
Cartão for ‘ir online’ este Criptograma é enviado para o emissor através do DE55 (tag ‘9F26’).
Trata-se de um valor único por transação, portanto, é mandatório para o Emissor a validação
desta TAG.
5.6.1.1 Cálculo para ARQC Doméstico e ARQC Internacional
O algoritmo para o ARQC está especificado no documento EMV Book 2, Parte IV, seção 8.1.2
“Application Cryptogram Algorithm”. Este algoritmo é comum para validação do criptograma
gerado pela aplicação doméstica e internacional.
5.6.2 ARPC - Authorization Response Cryptogram
O criptograma ARPC tem por finalidade provar ao cartão que a resposta da transação
provém de uma fonte fidedigna (Host Autorizador). Este valor é gerado pelo emissor e
enviado para o cartão na tag 91 (IAD - Issuer Authentication Data), conforme os formatos
apresentados abaixo, respectivamente para as aplicações doméstica e internacional.
5.6.2.1 Formato Doméstico e Internacional
Bytes Descrição
1–8 ARPC
9 - 10 CSU
O criptograma ARPC é verificado pelo cartão, permitindo que o mesmo negue ou aprove a
transação no 2nd Generate AC. Caso o cartão não reconheça o ARPC, a transação será a
negada mesmo que o Authorization Response Code da Mensagem de Autorização seja “00 -
Aprovado”. Ocorrendo desta forma o Desfazimento da Transação.
5.6.2.2 Cálculo para ARPC Doméstico e Internacional
A geração do ARPC para a aplicação Internacional, segue os 3 passos abaixo:
a) Concatenar o CSU Internacional adicionando 6 bytes com valor '00' à

direita do CSU, obtendo:
X = (CSU || '00'|| '00' || '00' || '00' || '00' || '00')
b) Calcular:
Y = ARQC EOR X.
c) Calcular o ARPC Como segue,

ARPC = DES3 (SKAC) [Y]
Nota: Um exemplo do cálculo do ARPC internacional pode ser obtido através do

e-mail tecnologia@cartaoelo.com.br.
bancárias.
O Criptograma Tipo 15 é aplicável somente para transações na interface sem

contato.
5.7.1 Cálculo para ARQC Doméstico e ARQC Internacional
A geração do ARQC para interface sem Contato, cuja versão do Criptograma é

15, segue abaixo:
a) Diversificar a MKac, conforme EMV Book 2, seção A1.4.1 “Option A”.

a. O resultado é o DKac
b) Gerar a chave de sessão, conforme EMV Book 2, seção A1.3.1

a. O resultado é o SKac
c) Concatenar a informação abaixo, oriunda do DE55, gerando o

“Cryptogram Input Data”:
a. 9F02 - AMOUNT AUTHORIZED
b. 5F2A - TRANSACTION CURRENCY CODE
c. 9F37 - UN
d. 9F36 - ATC
e. 9F10 - ISSUER APPLICATION DATA
d) ARQC: MAC(SKac) [Cryptogram Input Data]
Nota: Um exemplo do cálculo do ARQC pode ser obtido através do e-mail

tecnologia@cartaoelo.com.br
Validação do Criptograma (DCVV) Transações ZIP Mode
A validação do criptograma gerado é necessária para a prevenção contra

tentativas de fraude em transações bancárias.
O Criptograma do Tipo DCVV é aplicável somente para transações na interface

sem contato e internacional.
5.8.1 DCVV – Dynamic Card Verification Value
O DCVV é gerado pela interface sem contato D-PAS como um valor exclusivo
para cada transação.
É mandatório para o Emissor a validação desta TAG.
5.8.2 Cálculo para DCVV Internacional
O algoritmo para o cálculo do DCVV é o seguinte:
• Calcule o Track Data Hash concatenando da esquerda para a direita os

dígitos decimais do PAN com a Data de Vencimento. Se o PAN tiver um
número ímpar de dígitos decimais, será preenchido à esquerda com
zero. Execute um cálculo SHA-1 e mantenha os 2 bytes mais à esquerda.
Track Data Hash Darivation Data = [PAN || Data de Vencimento]
Track Data Hash = SHA-1 [Track Data Hash Darivation Data] (considerar
os 2 bytes à esquerda)
• Calcule o DCVV da seguinte maneira:
DCVV Derivation Data = 2-bytes ATC || 1-byte Unpredictable Number ||
1-byte ~Unpredictable Number || 2-bytes Track Data Hash || 2-bytes

~ATC
DCVV = DES3 (AUKDCVV) [DCVV Derivation Data] (considerar os 3

bytes mais à esquerda, cada valor de byte mod 10)
O cartão calcula o DCVV na etapa Initiate Application Processing. Ele armazena

o resultado na tag 9F7E no Registro 1 do SFI 1, a ser recuperado pelo leitor. O
leitor insere o DCVV nos dados da trilha.
Para autenticar o cartão, o sistema de autorização extrai o Unpredictable

Number e o ATC dos dados da trilha, calcula o Track Data Hash, calcula o
AUKDCVV (conforme descrito na seção 7.1.2) e calcula o DCVV conforme
descrito nesta seção. Os resultados são usados para comparar o DCVV
calculado com o DCVV nos dados da trilha. Se o DCVV calculado não for igual
ao DCVV nos dados da faixa, o sistema de autorização deverá recusar a
transação.
Nota: Um exemplo do cálculo do DCVV pode ser obtido através do e-mail

5.8.3 Método de derivação para chave AUKDCVV
O emissor deve gerar e manter uma Issuer Master Key para DCVV (IMKDCVV)
para derivar uma Account Unique Key para DCVV (AUKDCVV). O AUKDCVV é a
ICC Key criada para gerar o DCVV.
O algoritmo para derivar o AUKDCVV é descrito abaixo. Uma criptografia

Triple-DES é executada dependendo do comprimento da chave IMKDCVV.
• Concatene da esquerda para a direita os dígitos decimais do PAN com

a Data de Vencimento, o inverso do PAN, o inverso da Data de
Vencimento. Se o PAN tiver um número ímpar de dígitos decimais, será
preenchido à esquerda com zero. Concatene com o indicador de
preenchimento variável de 1 byte '80' e o menor número de bytes '00'
para obter um comprimento múltiplo de 8 bytes para a criptografia
3DES-CBC.
AUKDCVV Derivation Data = PAN || Data de Vencimento || ~PAN ||

~Data de Vencimento || '80' || '00' adicionados para tornar o
comprimento total dos dados de derivação múltiplo de 8.
• Calcule os dados de derivação obtidos como seguintes:
AUKDCVV = DES3-CBC (IMKDCVV) [AUKDCVV Derivation Data]
O Key Checksum Value pode ser calculado da seguinte forma:
AUKDCVV KCV Derivation Data = '00 00 00 00 00 00 00 00 00'
AUKDCVV KCV = DES3-ECB (AUKDCVV) [AUKDCVV KCV Derivation

Data] considerar os 3 bytes à esquerda.
Recomendações adicionais para autorização.
No intuito de detectar um possível ataque “man-in-the-middle” quanto ao

Offline PIN, recomendamos validar:
• O CVR da aplicação Elo Domestico tem um recurso exclusivo para

detectar este tipo de ataque.
o Byte 3, bit 3 do CVR com valor ‘1’.
• Na ausência do CVR acima (ex.: aplicação internacional), realizar a

avaliação das TAGS 9F34 (CVM Results) e 9F33 (Terminal Capabilities) do
DE55.
o 9F34: Esta TAG indicará se o Offline PIN foi verificado, o CVR
deverá indicar o mesmo.
o 9F33: Esta TAG indicará se o terminal suporta Offline PIN, se o
cartão suportar Offline PIN o TVR deverá indicar que PIN não está
com status “Bypassed” e o CVR também deverá indicar que o
Offline PIN foi verificado com sucesso.

Manual Operacional

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Manual Operacional

Enviado por

Direitos autorais:

Formatos disponíveis

MANUAL OPERACIONAL

Autorização de Transações EMV (Full Grade)

As informações contidas neste documento são restritas e de propriedade da Elo Serviços

Manual Completo • Novo manual 1.0 24/11/2014

Validação de • Inclusão de seção exclusiva para ataque

• Atualização para contemplar as mudanças

Manual Completo • Alteração no template do Manual 1.3 07/04/15

• Detalhamento do local do CVR para

Estrutura da 9F10 • Ajuste na seção, de 1.1.1 para 3.1.2

(Local CVR) – • Ajuste no Issuer Application Data, de “09- 1.5 11/01/16

Internacional 32” para “09-16”

• Ajuste no nome da Seção 06, para

Validação de “Recomendações adicionais para

• Descritivo sobre a obrigatoriedade da

3.2.1 Marcações de Exemplos ............................................................................ 9

4.1.1 CVR e TVR ................................................................................................ 10

4.9.1 TVR – Byte 1 ............................................................................................. 42

4.10.1 ARQC - Authorization Request Cryptogram........................................... 50

4.11.1 Cálculo para ARQC Doméstico e ARQC Internacional ............................ 53

4.12.1 DCVV – Dynamic Card Verification Value ............................................... 54

5.1.1 CVR e TVR ................................................................................................ 59

5.5.1 TVR – Byte 1 ............................................................................................. 83

5.6.1 ARQC - Authorization Request Cryptogram........................................... 90

5.7.1 Cálculo para ARQC Doméstico e ARQC Internacional ............................ 93

5.8.1 DCVV – Dynamic Card Verification Value ............................................... 94

O mapa de impactos e atuação tem o objetivo de indicar as ações devidas de acordo

• Regulatório: obrigatoriamente deve ser desenvolvido pelo participante, por

• Mandatório: obrigatoriamente deve ser desenvolvido pelo participante

• Equiparado: obrigatoriamente deve ser desenvolvido pelo Participante, se ele já

• Opcional: o participante pode optar ou não por desenvolver.

• Informativo: não requer desenvolvimento pelo participante – apenas informativo

Para facilitar a análise do documento pelos Participantes dos Arranjos de Pagamento

• Vermelho tachado (Vermelho tachado) – Indica a exclusão do texto no documento,

Na próxima versão deste documento os textos tachados em vermelho serão

A solução determinante para evitar fraudes e maximizar a segurança, é baseada na

A validação de ARQC é mandatória para todos os Emissores Elo.

Nas seções decorrentes apresentaremos estes parâmetros, as particularidades Elo e

O manual é dividido em duas sessões contemplando as necessidades para os modelos

Guia de Utilização do Manual

Esta seção tem o objetivo de auxiliar a compreensão e utilização do manual, de modo

3.2.1 Marcações de Exemplos

• Bordas pontilhadas, com fundo Cinza.

Modelo de Implementação Elo 1.0

4.1.1 CVR e TVR

O ATC (Application Transaction Counter) é um contador gerado pela aplicação de

O modelo de implementação Elo 1.0 possui a seguinte estrutura de ATC:

1 ATC para aplicação Crédito Doméstico Contato.

1 ATC para aplicação Débito Doméstico Contato.

1 ATC para aplicação Crédito Doméstico Sem Contato.

1 ATC para aplicação Débito Doméstico Sem Contato.

1 ATC para aplicação Débito Internacional Contato e Sem Contato (Débito

4.1.3 CVM (Cardholder Verification Method) List

4.1.4 CD-CVM ‘DC’

O “Consumer Device - Cardholder Verification Method” está presente em transações

Byte Bit Descrição

0001 = NFC 0100 = IN APP

0010 = BLE 0101 = 3D – Secure

01 0000 = No 0011 = 0110 = Facial

0001 = 0100 = 0111 = Local

0010 = 0101 = Retina 1000 = Other

4.1.5 Issuer Application Data (IAD) ‘9F10’

O IAD contém dados proprietários da aplicação Elo a serem transmitidos ao Emissor

4.1.5.1 Estrutura 9F10 para Contato Doméstico

Byte Bit Descrição