Online authorization of transactions in the EMV® world takes on another dimension in comparison to magnetic stripe and card-not-present payments. The purpose of EMV is to verify card and cardholder authenticity and transaction data integrity. This is achieved by cryptographic processes in the card, POS terminal and issuer system that provide mutual authentication of card and host and cardholder verification, and that detect tampering or corruption of data. Of course the requirement to validate card status, expiry date and to check available funds still exists, so Aconite Technology authorization solutions work in tandem with existing systems to provide the uplift to full EMV capability – without a major system upgrade or replacement.
Click here to jump to Aconite Technology Banking Solutions.
The specific processes that EMV authorization systems must support are summarized below:
Incoming Authorization Request
EMV authorization requests contain a rich seam of additional data that must be extracted, broken down and processed. Within this data are audit trails of actions taken and decisions made by card and terminal prior to sending the request online, status information about previous transactions and the EMV Authorization Request Cryptogram (ARQC – a form of digital signature) that can verify card authenticity and data integrity. That cryptogram was generated by the card using a secret – in some cases dynamic – key known only to the card and to the issuer system, which must re-derive that key and call an HSM (Hardware Security Module) to validate the cryptogram. If validation fails, either an attempt has been made to use a counterfeit card, or data in the transaction has been altered or corrupted, and the authorization request should be declined.
Issuer systems may optionally analyze the additional authorization data to detect anomalies that may also indicate fraud attempts or other exception conditions in the card or transaction, and determine whether to approve or decline, or take other action as a result.
Whether or not the authorization request is approved or declined, another cryptogram, the Authorization Response Cryptogram, or ARPC, must be generated by the issuer system to allow the card to verify the authenticity of the issuer and the integrity of the data in the response message. The ARPC and its associated data, including the Authorization Response Code and any EMV Script (see below), are assembled into a data block and inserted into the response message returned to the network.
Using an EMV Script, the issuer also has the option to update card settings and parameters, described below.
Card Management in the Field
During EMV authorization processing, the issuer can update parameters in the card that either control its behavior, particularly if offline transactions are supported, or change or unblock an EMV Offline PIN, if present. This process, known as EMV Scripting, can also be used to block the entire card if it has been reported lost or stolen, and special processes and secret keys are used in the creation of EMV scripts. Some applications also allow counters and accumulators in the app to be reset using a special form of Response Code.
Depending on the issuer system's capabilities, EMV Scripts can be generated in real-time, during authorization processing, or can be scheduled for delivery when the card next comes online for authorization. It is also possible to track the success or failure of script updates from data delivered in subsequent transactions.
Click here to jump to Aconite Technology's Transaction Management product page.