EMV Issuer scripts and how do they work

EMV Issuer scripts allow the Issuer to update and change parameters and values on the card chip whilst it is live in the field. This means that the EMV application can be updated to change parameters that can improve the risk functions of the application on the chip and reduce and prevent fraudulent activity as this changes during the life of the card.

Equally changes can be used to adapt the card to suit the requirements of the cardholder when the card is used in a live situation. For example increasing the LCOL (Lower Consecutive Offline Limit) and / or the UCOL (Upper Consecutive Offline Limit) could allow the card to be used offline more without being forced online if the cardholder regularly uses the card in an area with many terminals that are predominately offline.

Technically all scripts are similar, obviously with different functions but working more or less in the same way. However from a business view there are two different types of scripts. Automatically generated scripts like Block Card, when a card is stolen or lost, or when a card is miss-used by the cardholder.

Scripts generated by customer service when a change or action is needed, like PIN Unblock or increase the LCOL are applied by the customer service representative. Automatically generated scripts would have a higher priority normally than a requested change and should be scheduled by the card management system to send them first.

In simple terms scripts work in this way. The scripts to be applied are stored, usually somewhere accessible to the system where a transaction is to be authorised. The script will have a priority and must be applied in the order of the priority. The script or scripts are added to the authorisation response and returned to the ATM or POS device with the response, (Note: EMV is designed to allow multiple scripts in one response, in reality it is usually one script at a time). The terminal applies the scripts, in order, and completes the transaction; the scripts can be applied before completion of the transaction or after.

For example Block Card or Block Application must be applied before completion; most others would be after completion. The result of the script processing and its success or not is then returned in the next transaction sent to the host. This response should be used to update the script management system and allow re-sending of scripts if this is needed.

EMV can support around 16 scripts that allow:

• The updating of many of the card parameters set at personalisation
• Blocking and unblocking the application
• Blocking the card
• Resetting the PIN try counter
• Changing the offline PIN on the chip

In fact the scripts mainly used are:

• Application Block and Unblock
• Card Block
• PIN Change or Unblock
• Update data, mainly change LCOL or UCOL

These all work and as EMV becomes more generally used across the world the use of scripts and the number of uses and scripts will increase and allow us to adapt the cards as we use them. However this does impose an overhead on card personalisation as if an individuals card parameters are changed to suit the way they use the card they will want the same parameters on the new card, so all changes have to be recorded for re-issue, but that’s another subject.

Detailed description and example of Secure Messaging functionality covered by BP-CCALC be found here:

BP-Tools: Secure Messaging – VISA
BP-Tools: Secure Messaging – MasterCard