PIN Translation
This topic is probably one of the most confusing ones within payments simply because PIN translation is a form of encryption. The encryption process has to maintain a degree of complexity in order to remain a safe vehicle to pass on PIN codes.
We are still using the example where a user has to type in their PIN into a card terminal (POS). The user’s PIN will be passed on from POS to the acquiring bank, to payment scheme and finally to the issuing bank which is the only instance that can verify if the PIN is correct. While traveling through all these instances the PIN will be encrypted and at each instance the encryption will change to ensure the necessary degree of security.
POS to Acquiring Bank
The first translation starts when the PIN is received by the POS and sent over to the acquiring bank. The POS is the only instance that actually receives the real PIN.
Let’s say the user’s PIN is 1234.
In order to send the PIN to the acquiring bank, the first translation (encryption) needs to happen. The encryption will use an algorithm to translate the PIN code form 4 or 6 digits purely numerical code to a 16 digit hexadecimal code.
1234 → A9AHDt54DN3HK1B0
Sidenote: For the sake of simplicity I am not going to deep dive into the various forms of encryption, but will only briefly mention some encryption key concepts. Do not get too confused by the similar-sounding acronyms. Simply remember that at each instance the key will be decrypted and encrypted in a different way than at the previous instance. This means that each instance uses different encryption to ensure security.
The encryption from POS to acquiring bank uses a key called ZPK (Zone PIN key). This key was generated based on the ZMK (Zone Master Key). The ZMK concept is known to both POS and acquiring bank so they are able to exchange the decrypt the ZPK. Without the master key (ZMK) encryption and decryption are not possible.
Acquiring Bank to Payment Scheme
Now the acquiring bank needs to move the PIN to the card scheme. The acquiring bank will use another key, AWK (Acquirer Working Key), to first decrypt the code and then encrypt it again. The 16 digit hexadecimal code will become the 4 digits numerical code again and then decrypted into another 16 digit hexadecimal code.
A9AHDt54DN3HK1B0 → 1234 → WUJ7HSW93SH43SO1
Payment Scheme to Issuing Bank
The same happens at the last instance where the key is passed on from the payment scheme to the issuing bank. Again the key will be decrypted into its original 4 digits numerical form and then encrypted again. In this case, the key will be translated into the IWK (issuer working key). One last step follows where the issuer will use the PVK (Pin Validation Key), which was used to generate the PIN in the first place, verify if the PIN code entered in the POS is correct.
WUJ7HSW93SH43SO1 → 1234 → D573BNDDZ9322QLO → 1234
The issuing bank will match the PIN 1234 to a customer account and verify (or not). The verification will be sent in the form of a code back through all the instances to the POS terminal where the receipt can be printed.
In a separate article, I will go more into details of static and dynamic encryption code, HSM commands and DKUPT methods.
