The entirety of this Web site is copyright © 2007, ACI
Worldwide, Inc.
|
|
|
EMV issuer solution using ASx
On completion of the processing of an authorization request at
the terminal by the ICC application, a cryptogram is returned to the terminal along
with several indicators showing the result of the off-line processing. This is called
the Authorization Request Cryptogram (ARQC) and can be used to indicate that the
transaction must go online to issuer for authorization. This data is sent to the
Issuer and by using other data from the ICC in the authorization request (such as
the unpredictable number) and the cardholders secret DES key, the issuer system
can generate the same ARQC and compare it to the one from the request message. This
process is referred to as Online Card Authentication (CAM). These CAM results can
be used in the authorization process.
On the response message, an Authorization Response Cryptogram (ARPC) can be generated
from the ARQC, Response Code and cardholder key by the Issuer system and transmitted
back to the terminal / ICC. If the card supports ARPC verification, the ARPC will
be validated to ensure that the issuer is genuine. This facility can be used to
allow the update of security information on the chip only when the ARPC is valid.
Secure information would include the PIN retry counters, off-line limits etc, which
would be sent down as scripts to the card. If the ARPC validation fails then the
card can be set to always go online until a valid ARPC is received.
|
All of these very specific functions and data have been implemented
as an authorization server for the EMV data. To support these functions in ASx,
the product stores EMV specific data in the cardholder database such as:
|
|
Cardholder secret key (obviously encrypted under a secure MFK variant)
|
|
|
Tag data for limits - this includes an amount, number of days before
going online etc
|
|
|
Tag data to change PIN value
|
|
|
Other market specific tags
|
|
|
the flexibility to load tagged scripts directly to each specific
card in a database, or have a pointer for each card to shared tag data (e.g. a global
off-line limit parameter) or even to apply tags to BINs
|
|
|
Enhanced authorization rule processing to determine the downloading
of tag data according to card status, or Merchants type (MCC) etc - e.g. if the
merchant is a SET merchant, there is a good chance that different data will be sent
to the terminal than for an ordinary POS device.
|
All of these functions are built into the database and available
for use in the online process.
|
|
