Documentation Index
Fetch the complete documentation index at: https://docs.futurex.com/llms.txt
Use this file to discover all available pages before exploring further.
Acquiring focuses on the steps carried out between merchants and banks for processing credit and debit transactions, either through traditional card-based transactions or mobile payments.
The following sections cover these acquiring topics:
- PIN translation and verification
- EMV validation
- Mobile payment acceptance
- CVV validation
PIN translation and verification
When users enter their card personal identification number (PIN) on a device (such as an ATM or payment terminal), the device encrypts the PIN and then sends it to an HSM in the bank data center, along with the account or card number and the PVV or offset (depending on the method). The HSM then decrypts the PIN that the user entered, takes the account or card number, the bank PIN Verification (PVK), and the PVV or offset and derives the actual PIN. Then, it compares that PIN value to what the user entered and approves or declines the transaction.
The data structure for an encrypted PIN is called a PIN block. PINs are typically four characters, but you cannot encrypt only four characters with the DES algorithm. Because you need at least an 8-byte block of data, the payment industry created the concept of PIN blocks.
Embedded in a PIN block are the length of the PIN, the PIN itself, and padding. Then, all of that data is XORed with a portion of the account number. The result is the clear value of the PIN block. The clear PIN block value is then encrypted with a PIN Encryption Key (PEK).
Different standards exist for PIN blocks, and we currently support ISO format 0 and ISO format 3. The new ISO format 4 standard supports an AES PIN encryption key, but AES pin blocks were previously not supported because of issues with AES requiring a 16-byte block of data to encrypt.
Common PIN translation and verification commands
This section contains PIN translation and verification commands for Excrypt, Standard, and International command sets:
Excrypt
| Command | Description |
|---|
| RPIN | PIN Change & Optional PIN Verification (IBM 3624) |
| RPIN | PIN Change & Optional PIN Verification (IBM 3624 DUKPT) |
| RPIN | PIN Change & Optional PIN Verification (Visa) |
| RPIN | PIN Change & Optional PIN Verification (Visa DUKPT) |
| TPCP | Translate Encrypted PIN Coordinates to a PEK for Generate New Map Collection |
| TPDD | Allow an encrypted ANSI PIN block to be translated |
| TPIN | Translate PIN blocks |
| TPIN | Translate PIN blocks (DUKPT) |
| TPIN | Translate PIN blocks (IBM 4736) |
| TRPN | Translate PIN from RSA to Symmetric PIN Block |
| TSPN | Translate PIN from PIN block to RSA encryption |
| VMAP | Verify MAC and PIN (Diebold Method) |
| VMAP | Verify MAC and PIN (IBM 3624 Method) |
| VMAP | Verify MAC and PIN (Visa Method) |
| VPIN | Verify PIN |
| WPIN | Weak PIN checking |
| XPIN | ANSI to ANSI |
| XPIN | ANSI to PIN Pad |
| XPIN | Extended PIN Translation |
| XPIN | IBM 3624 to IBM 3624 |
| XPIN | IBM 3624 to PIN Pad |
| XPIN | IBM 4736 to IBM 4736 |
| XPIN | PIN Pad to PIN Pad |
Standard
| Command | Description |
|---|
| 31 | Translate PIN Block |
| 32 | Verify PIN |
| 32 | Verify PIN - ANSI |
| 32 | Verify PIN - Compare two PIN Blocks |
| 32 | Verify PIN - Diebold |
| 32 | Verify PIN - Diebold DUKPT |
| 32 | Verify PIN - IBM 3624 |
| 32 | Verify PIN - IBM 3624 DUKPT |
| 32 | Verify PIN - IBM 4736/NCR |
| 32 | Verify PIN - Visa |
| 32 | Verify PIN - Visa DUKPT |
| 335 | Translate PIN Block |
| 33 | Extended PIN Translation |
| 346 | DUKPT PIN Translate |
| 35 | Translate PIN Block using Double Encryption |
| 36 | Verify PIN Block using Double Encryption |
| 36 | Verify PIN Block using Double Encryption (ANSI) |
| 36 | Verify PIN Block using Double Encryption (Compare two PIN Blocks) |
| 36 | Verify PIN Block using Double Encryption (Diebold - DUKPT) |
| 36 | Verify PIN Block using Double Encryption (Diebold) |
| 36 | Verify PIN Block using Double Encryption (IBM 3624 - DUKPT) |
| 36 | Verify PIN Block using Double Encryption (IBM 3624) |
| 36 | Verify PIN Block using Double Encryption (IBM 4736 - NCR) |
| 36 | Verify PIN Block using Double Encryption (Visa - DUKPT) |
| 36 | Verify PIN Block using Double Encryption (Visa) |
International
| Command | Description |
|---|
| BC | Verify a Terminal PIN using the Comparison method |
| BE | Compare PIN to Encrypted PIN Block |
| CA | Translate PIN Block from TPK to PEK Encryption |
| CC | Translate PIN Block from one PEK to another PEK |
| CI | Translate PIN Block from BDK to PEK Encryption |
| CK | Verify PIN using the IBM Method (DUKPT) |
| CM | Verify PIN using the Visa PVV Method |
| CU | Validate PIN and Generate new PVV |
| DA | Verify Terminal PIN Block - IBM 3624 |
| DC | Verify Terminal PIN Block - Visa |
| DU | Verify and Generate an IBM PIN Offset (of a customer selected PIN) |
| EA | IBM 3624 |
| EC | Visa |
| G0 | Translate PIN from BDK to ZPK Encryption (3DES DUKPT) |
| JC | Translate PIN from TPK to MFK Encryption |
| JE | Translate PIN from ZPK to MFK Encryption |
| JG | Translate PIN from MFK to ZPK Encryption |
| SC | Verify Public Key Encrypted PIN |
EMV validation
When you insert (or dip) an EMV card at a terminal, the terminal performs a few validations, such as the type of product (such as debit or credit) and the cardholder verification method (such as chip and PIN or chip and signature). After validations, the terminal requests an Authorization Request Cryptogram (ARQC) from the integrated circuit chip (ICC) of the card.
ARQC validation and ARPC generation
The following workflow describes the ARQ validation and ARPC generation process:
The chip generates an 8-byte Application Cryptogram (AC) using an Application Cryptogram Master Key (MKAC). The chip performs the following actions to generate the Application Cryptogram (AC):
- It generates an Application Cryptogram Session Key (SKAC) by using the MKAC and an Application Transaction Counter (ATC) value. The session key is unique for each transaction.
- It uses the session key and the data to generate an Application Cryptogram (AC) by applying 3DES or AES.
In the case of an online transaction, this authorization cryptogram is called an Authorization Request Cryptogram (ARQC). The chip sends the ARQC to the terminal, which in turn sends the ARQC in the authorization message to the issuer host for authorization.
Upon receiving the ARQC in the authorization request, the issuer system validates the ARQC and generates an Application Response Cryptogram (ARPC) by using a hardware security module (HSM).
If the ARQC verification is successful, an ARPC is generated by using ARQC as one of the inputs. If the ARQC verification is unsuccessful, then you shouldn’t use the ARQC for ARPC generation.You can use the following methods to generate the ARPC:
- Method 1 generates an 8-byte ARPC by using an 8-byte ARQC and a 2-byte Authorization Response Code (ARC) as input.
- Method 2 generates a 4-byte ARPC by using an 8-byte ARQC, a 4-byte Card Status Update (CSU), and a 0–8-byte Proprietary Authentication Data as input.
The ARPC is sent in an authorization response message from the issuer to the terminal through the acquirer.
Commonly used EMV Validation commands
This section contains EMV validation commands for Excrypt, Standard, and International command sets:
Excrypt
| Command | Description |
|---|
| EMPT | Translate PIN Block for EMV Personalization |
| EMVA | Verify QRQC and optionally generate ARPC |
| EMVP | PIN Change |
| EMVR | EMV RSA Private Key or Component Translation to Encryption Under a Personalization Key |
| EMVS | Translate an ICC Master Key to Encryption Under a Personalization Key |
| EMVT | EMV Translate Sensitive Data |
| VCAC | Verify EMV Mastercard CAP Token |
| VCAV | Verify Cardholder Authentication Verification Value |
| VDAC | Verify a Data Authentication Code (DAC) |
| VDCV | Verify CVC3 |
| VDDC | Verify Discover Dynamic Card CVC3 |
| VEMI | Verify an EMV Issuer Certificate |
| VIDN | Verifies an ICC Dynamic Number (IDN) |
| VVDC | Verify a Dynamic CVV |
Standard
| Command | Description |
|---|
| 350 | EMV ARQC Validation |
| 357 | Dynamic CVV Validation |
| 359 | Dynamic CVC3 Validation |
| 365 | Verify Visa Cloud-Based Payments |
International
| Command | Description |
|---|
| JS | UPI ARQC Verification and ARPC Generation |
| KG | Validate a signed Issuer Certificate |
| KQ | ARQC (or TC/AAC) Verification and/or ARPC Generation |
Mobile payment acceptance
Mobile payments use a combination of specialty hardware and a mobile wallet (such as Google Pay, Apple Pay, Samsung Pay, and so on). Users hold their mobile devices up to the contactless payment terminal. This enables the two devices to communicate over a specific radio frequency, passing encrypted payment information back and forth to complete the transaction. The funds then leave the user’s digital wallet and enter the business point of sale system.
Tokenization is another critical piece in enabling mobile transactions and payments. When you set up a mobile wallet, details are sent to your issuing bank. The bank replaces these details with a token, a set of randomly generated numbers. This keeps your account details completely encrypted and protected from fraud.
Commonly used mobile payment acceptance commands
This section contains mobile payment acceptance commands for Excrypt command set:
Excrypt
| Command | Description |
|---|
| DAPT | Decrypt Apple Pay Token |
| DGPT | Decrypt Google Pay Token |
| DSPT | Decrypt Samsung Pay Token |
| VHMC | Verify HCE Mobile Cryptogram |
| VHMD | Verify HCE Magstripe Verification Value |
The Standard and International command sets do not support mobile payment acceptance.
Card Verification Value validation
Card issuers and banks use card verification values (CVV) to determine when someone uses a forged card in a card-notpresent transaction. Using the card expiration date, PAN data, and PIN, an HSM can cryptographically validate CVV (in its many forms, including CVC, CID, CSC, CVC2, and CVV2) and determine if the card data presented is authentic for online or contact-free payments.
CVV, CVC, and CVC2
CVC accelerates the process of verifying card data in card-present transactions. The magnetic strips contain the CVC, and card-reading point-of-sale terminals process these codes anytime a card is inserted.
CVV and CVC2 are commonly referenced for card-not-present transactions and are used interchangeably. They are usually in the form of a three or four-digit code on the back of the card, and they are often used in place of CVC for card-not-present transactions.
Reasons for validating CVV
In online transactions, CVV validation is one of two ways of verifying if cards are authentic (the other method is XML-based authentication). Storage of CVVs in any database is expressly prohibited, but businesses need to have access to the card’s public key to decrypt and verify transactions. To secure the CVV, the process uses HSMs to validate and encrypt it.
There is CVV generation and verification, but not translation because it is not encrypted between the hops.
Commonly used CVV validation commands
This section contains CVV validation commands for Excrypt, Standard, and International command sets:
Excrypt
| Command | Description |
|---|
| VAAV | Verify Account Holder Authentication Value |
| VCSC | Verify American Express (Amex) CSC Value |
| VCVC | Verify CVC and CVC2 |
| VCVV | Verify CVV |
| VDCV | Verify Discover Dynamic Card CVV |
| VDDC | Verify dynamic CVC value (CVC3) |
| VEMI | Verify EMV Issuer Certificate |
| VIDN | Verify ICC dynamic number (IDN) |
| VVDC | Verify dynamic CVV |
Standard
| Command | Description |
|---|
| 357 | Dynamic CVV Validation |
| 359 | Dynamic CVC3 Validation |
| 35A | Verify American Express (Amex) CSC Value |
| 5E | Verify Card Verification Value (CVV) |
International
| Command | Description |
|---|
| CY | Verify Visa Card Verification Value (CVV) |
| RY (Mode 4) | Verify Card Security Codes for CSCK |
Message Authentication Code generation and verification
Message Authentication Code (MAC), also referred to as tags, authenticates messages. In other words, MAC ensures that the message came from the stated sender (its authenticity) and has not been changed. The MAC value protects message data integrity by enabling verifiers (who also possess the secret key) to detect any changes to the message content, thus preventing man-in-the-middle attacks and fraudulent hosts or ATMs.
Currently, MACing is not very common in the U.S. for payment transactions. However, in Canada, a government-owned interbank network, Interac, forces participating banks to MAC all payment transactions.
Common MAC generation and verification commands
This section contains MAC generation and validation commands for Excrypt, Standard, and International command sets:
Excrypt
| Command | Description |
|---|
| EMVM | Generate/Verify MAC |
| GHPB | Generate HMAC and PBKDF2 Obfuscated Value |
| GMAC | Generate Message Authentication Code (MAC) |
| GPMC | General Purpose Symmetric MAC |
| HMAC | Generate MAC Hash |
| RKHM | Generate/Verify HMAC |
| VMAC | Verify Message Authentication Code (MAC) |
| VMAP | Verify MAC and PIN Diebold Method |
| VMAP | Verify MAC and PIN IBM 3624 Method |
| VMAP | Verify MAC and PIN Visa Method |
Standard
| Command | Description |
|---|
| 56 | Generate MAC (512 bytes or less) |
| 57 | Generate MAC (512 bytes or more) |
| 5A | Verify MAC (512 bytes or less) |
| 5B | Verify MAC (512 bytes or more) |
| 5C | Verify and Generate MAC (DUKPT) |
| 98 | Generate MAC value based on MAC key and data |
| 99 | Verify MAC value based on MAC key and data |
| 11D | Generate MAC and DEK keyblocks |
| 304 | Verify CMAC using TDES |
| 305 | Generate CMAC using TDES |
| 324 | Verify APACS 40 request MAC |
| 348 | Verify MAC using DUKPT key derived using the BDK and KSN |
| 386 | Generate MAC using DUKPT key derived using the BDK and KSN |
International
| Command | Description |
|---|
| C2 | Generate a MAC (AS2805) |
| C4 | Verify a MAC (AS2805) |
| EO | Generate a MAC on a Public Key |
| EQ | Verify a MAC on a Public Key |
| GW | Generate or Verify a MAC (3DES DUKPT) |
| L0 | Generate an HMAC Secret Key |
| LQ | Generate an HMAC on a block of data |
| LS | Verify an HMAC on a block of data |
| M6 | Generate MAC using MAK (supports continuation mode) |
| M8 | Verify MAC using MAK (supports continuation mode) |
| MA | Generate MAC using MAK |
| MC | Verify MAC using MAK |
| MK | Generate a Binary MAC |
| MM | Verify a Binary MAC |
| MQ | Generate a Binary MAC (extended length) |
| MS | Generate a Binary or Hex MAC (extended length) |
| MY | Verify and Generate MAC |
| PQ | Generate an AS2805.4 MAC |
| PS | Verify an AS2805.4 MAC |
| RK | Verify MAC and return MAC Residue |
Remote Key Loading (RKL)
We all depend on encryption keys in one way or another. While few people outside the payments industry are aware of this, anytime you present your payment card at a Point of Sale (POS) terminal or use an Automated Teller Machines (ATM), an encryption key quickly goes to work to encrypt the PIN or the primary account number (PAN) associated with your card. This encryption obscures the data and protects against information theft as the transaction goes back to the card issuer for validation. For this process to work, an encryption key must be securely loaded into that endpoint device, such as an ATM, a POS terminal, or even a commercial off-the-shelf device used for payment acceptance.
You load the encryption key onto those devices manually through a process known as direct key injection. For POS terminals and PIN entry devices, this involves bringing the devices to a key injection facility where key administrators manually inject each device. This can be time-consuming and expensive. It requires the upfront cost of maintaining a validated Payment Card Industry (PCI) Level-3 key injection facility (KIF), and the operational costs of shipping devices to the KIF anytime you need to rekey them. For larger devices, like ATMs and gas station payment terminals, key administrators often have to travel to each device in the field to load the necessary encryption keys. For organizations with widespread ATM or POS networks, this can be a significant operational expense with a high susceptibility to human error.
While the direct injection model is sufficient for many organizations, others find a remote key loading (RKL) solution more cost-effective and efficient. With RKL, a remote key server establishes a secure, PKI-authenticated connection with each device and remotely distributes encryption keys without needing physical access to the device. The ability to remotely rekey the device in the field without extended downtime is a powerful time-and-money saver for many organizations.
RKL allows organizations to manage keys for an entire infrastructure by sending cryptographically secure key exchanges from a centralized location. Better yet, you can rekey devices instantaneously with minimal downtime, eliminating the costs of maintaining an injection facility and manual injection.
Successful remote key loading (RKL) operations require collaboration and standardized communication protocols between the device manufacturer and the RKL provider. Trust at both ends of the key exchange is the backbone of RKL, with the RKL provider on one side and the field-level device on the other. A certificate authority establishes this trust, providing the endpoint terminal and the RKL platform with a digital certificate. This certificate is a private key in the public key infrastructure (PKI) that facilitates secure key exchanges. The manufacturer must ensure that their devices have this certificate before deployment.
Furthermore, the endpoint devices and the RKL provider must use the same communication and encryption protocols, which furthers the manufacturer’s role in the process. While the most common and accepted encryption standard for RKL is TR-34, which was developed by ASC X9, there are many others in use depending on manufacturers, geographic location, and other factors. RKL providers need to be accommodating in their platform design to enable integration with multiple manufacturers.
ATMs
Millions of people use ATMs to withdraw cash every year. In 2016, the United States Federal Reserve noted that 91% of Americans have credit, debit, or other bank accounts, and three-quarters of them use ATMs for cash withdrawals. With so many people depending on ATMs functioning properly, security is a major concern. ATMs rely on network protection and PIN encryption techniques to keep the customer PINs safe.
Compliance and security mandates require you to rotate the encryption keys that encrypt and validate PINs regularly. Before remote key loading became a viable option, keyholders had to visit each ATM in person to rotate keys across the network. As the number of ATMs grew, this process became cumbersome and increasingly infeasible.
Furthermore, Payment Card Industry Data Security Standard (PCI DSS) regulations require all PINs to be encrypted upon capture at the terminal. RKL provides a secure, efficient, and cost-effective method for loading and managing ATM encryption keys across entire ATM networks.
POS terminals
POS terminals have double the encryption work. Like ATMs, they encrypt PINs for debit card transactions, but many merchants also require encryption of the primary account numbers, commonly known as PANs, which are the account numbers associated with credit card payments. While PCI DSS regulations do not require PAN encryption, it’s rapidly becoming the norm in the payments landscape. Recent years have seen high-profile data breaches traced back to a lack of PAN encryption. PAN encryption works similarly to PIN encryption, but the technology surrounding PAN encryption is typically called Point-to-Point Encryption (P2PE). Like PIN encryption, P2PE encrypts the PAN at the moment of capture in the POS device.
The encryption mechanisms behind PIN and PAN encryption differ slightly on the payment processing end, but they are the same for RKL. Both processes require reliable access to encryption keys. Most POS terminals have at least two key slots, with separate keys for PIN and PAN encryption.
Common RKL commands
This section contains RKL commands for the Excrypt command sets:
Excrypt
| Command | Description |
|---|
| PEDK | Key Request (Version 3 - Mode 1: Two Pass) |
| PEDK | Key Request (Version 3 - Mode 2: One Pass TR-34) |
| PEDK | Key Request (Version 3 - Mode 2: One Pass TR-34 with AES) |
| PEDK | Key Request (Version 3 - Mode 3: One Pass) |
| DRKI | Identification Request (Mode 1) |
| DRKI | Identification Request (Mode 2) |
| DRKK | Key Request (Mode 1) |
| DRKK | Key Request (Mode 2) |
| DRKV | Key Verification Request (Mode 1) |
| DRKV | Key Verification Request (Mode 2) |
Standard and International command sets do not support RKL.
ATM network
An ATM network, or interbank network, is a computer network that enables you to use ATM cards issued by a financial institution that is a member of the network to perform ATM transactions through ATMs that belong to another member of the network.
Network key exchange
Every active ATM has a PIN Encryption Key (PEK), Master Key, and Key Encryption Key (KEK) loaded on it through Remote Key Loading (RKL). To do this, the payment application on the backend sends a request to an HSM to generate a random KEK, encrypt it under the ATM public key or certificate, and send it to the ATM. The ATM then decrypts the KEK by using the private key associated with the public key or certificate that encrypts it. This key management scheme is called Master/Session.
On the ATM, the KEK (or Master key) encrypts a randomly generated Working Key (or Session key). In this case, the session key is the PIN Encryption Key (PEK).
The PEK is changed out regularly. In some cases, once a day or once every 1,000 transactions. The KEK is changed out less frequently (such as annually or once in the life of the ATM).
Foreign transaction example
Suppose an IBC Bank customer goes to a Chase Bank ATM and inserts their IBC debit card in the card reader. They enter their PIN, which the ATM encrypts under its PEK and sends to First Data Corporation. First Data hosts their STAR Network, which provides debit acceptance at more than two million retail POS, ATM, and Online outlets for nearly a third of all U.S. debit cards.
This example uses First Data, but many other networks exist to provide debit acceptance services.
- First Data forwards the request to Visa DPS to process.
- Visa DPS sends the response back to First Data.
- First Data delivers the response to the Chase ATM.
So, why can’t Chase send the request directly to IBC or Visa DPS? Because it’s not feasible for Chase to have relationships with every processor. Thus, they go to a network, First Data, in this case. First Data has relationships with all banks and processors and with other networks that do have a relationship with the issuing bank.
PIN translation
PIN translation plays a crucial role in all ATM foreign transactions. Between each of the hops in the preceding example, a PIN translation takes place by using the TPIN Excrypt command. Each involved entity has its own PIN Encryption Key (PEK). In addition, between each link in the network chain, a shared PEK is established between the two entities. For example, the process looks like this:
- Chase and First Data have a shared PEK, which we’ll call CFD-PEK. This shared PEK is stored on an HSM in both companies’ data centers.
- After the IBC cardholder enters their PIN, the Chase ATM encrypts it under its PEK and sends it to the Chase HSM, requesting that it perform a PIN translation from the ATM PEK to the CFD-PEK and then send it to First Data.
- First Data then performs a PIN translation from the PIN being encrypted under the CFD-PEK, encrypting the key under its own PEK.
- Then, the encrypted PIN is translated again, encrypting it under the PEK established between Visa DPS and First Data, and the process continues.
To reiterate, each link in the chain must establish a shared key for PIN translation to occur.
Typically, the process involves more than a PEK. Most likely, the process would establish an MFK-CFD-KEK key and use the KEK to share other keys so that the PEK could be swapped out periodically.
Point-to-point Encryption
The PCI Security Standards Council established the point-to-point encryption (P2PE) standard in 2012. It stipulates that cardholder information should be encrypted immediately after the card is used with the merchant’s point-of-sale terminal and not be decrypted until the payment processor has processed it.
PCI-DSS does not require P2PE encryption. PCI states that if you have a network where clear cardholder data is transmitted, you are within the scope of DSS-compliance requirements. Because of this, when companies started encrypting cardholder data, they correctly assumed that they no longer fell within the scope of DSS. However, PCI caught wind of this and considered that if these companies were encrypting cardholder data, they would need to securely manage encryption keys. Thus, they created the PCI-P2PE security standard, making its requirements even more stringent than PCI-DSS.
In reality, there are primarily two types of companies that deploy P2PE in their payment processing transactions:
- Retailers that want to reduce risk and don’t want to be in the news.
- Acquirers that are trying to add value to their service.
Before P2PE, there was no need for HSMs for acquirers because the only transactions going through an HSM were PIN-based transactions. Now, if an acquirer uses P2PE, every transaction goes through an HSM.
Common P2PE commands
This section contains P2PE commands for Excrypt, Standard, and International command sets:
Excrypt
| Command | Description |
|---|
| DCDK | Decrypt Cardholder Data Using DUKPT |
| ECDK | Encrypt Cardholder Data Using DUKPT |
| ONGQ | Translate PAN Encrypted Under an Asymmetric Key Pair to a Different Trusted Public Key |
| TCDK | Translate Cardholder Data Using DUKPT |
| TDKD | Translate Cardholder Data Using DUKPT and Symmetric Keys |
| TKDR | Translate DUKPT Data to RSA with Specific Output Data |
Standard
| Command | Description |
|---|
| 388 | 3DES DUKPT Encrypt/Decrypt Data |
| 52 | Data Translate |
International
| Command | Description |
|---|
| M0 | Encrypt a block of data |
| M2 | Decrypt a block of data |
