HomeMailSite Map Russian version  
 
Home
SV Overview
SV Docs
SV Support
SmartVista Processing Solution Overview
For illustration purposes, this paragraph describes the SmartVista Front-End authorisation routing and processing based on an example of an ATM generated transaction.

  1. Authorisation request message reception from an ATM. The message reception and primary processing is performed by the SmartVista Front-End Communication Interface The message contains card details, encrypted PIN block and transaction details.

  2. Message header modification. The SmartVista Front-End Communications Router replaces the communication header with a SmartVista Front-End internal header and forwards the message to the ATM Interface queue.

  3. Formatting. The ATM Interface identifies the message type and reformats the message into the internal SmartVista Message Format.

  4. ATM details and status retrieval. These are taken from the SmartVista Front-End database tables that hold ATM definitions and current settings of control parameters and counters. Checks are run to make sure that the previous transaction has been completed, that this message is not a duplicate of an already processed one, etc.

  5. Settlement record generation. At this step, a record is created in the database containing all information that will be needed to perform the End-of-Day processing and to generate the Posting File for SmartVista Back-Office.

  6. Card type identification. The message is forwarded to the SmartVista Front-End Transaction Router that identifies the transaction type (whether it involves a card issued by us, i.e. Us-on-Us or Us-on-Them, or by another Issuer, i.e. Them-on-Us). If the card is 'ours' (Us-on-Us for this particular example or Us-on-Them if we were considering an authorisation request for our customer received from another Acquirer's terminal), the message is routed to the Host Interface.

  7. Autorisation method and host identification. The Host Interface looks up the Institution and Routing Tables in the SmartVista Front-End database to identify the authorisation method and the host system that will perform the authorisation.

  8. Stand-In/Host authorisation mode identification. The Host Interface determines whether the transaction has to be authorised by the SmartVista Front-End Authorisation Engine, or whether it must be routed to an external Host for authorisation. This is done by checking whether the card BIN is listed in the Stand In Always Table. If the result is positive, the authorisation is done by SmartVista, otherwise the Host Interface checks the current status of the required host and if the connection to the host is up, the message is routed to the host. If the host check reports failure (host down or communication error), the authorisation is again performed by SmartVista.

  9. Authorisation, when performed by SmartVista Front-End, breaks down into several steps, as follows.

    9.1. Pre-authorisation. The following actions are performed:

    • verify the PAN length;

    • verify the PAN;

    • check that the requested authorisation method is supported for this transaction type;

    • calculate the Issuer Fee;

    • verify that the transaction amount is not null;

    • verify the PIN (by sending the PIN block to the HSM Communication Interface);

    • check the counter for the number of PIN verification attempts;

    • check the CVV;

    • check the transaction currency and, if needed, convert the requested amount into the currency of the required account;

    • check if the card is on file;

    • check if the account is on file;

    • check the card limits;

    • check the account limits;

    • check the card status;

    • make a decision if the card should be withdrawn.

    9.2. Database update. The transaction details are added to the Transaction and End-of-Day (Settlement) tables of the SmartVista Front-End database.

    9.3. Stand-In authorisation. The following items are checked at this step:

    • stand-in authorisation mode allowed for this card;

    • applicable account restrictions;

    • account available balance;

    • card issue date;

    • stand-in card limits

    Depending on the result of all these checks, the SmartVista Authorisation Engine will debit the account and update the account balance in the Accounts Table and add any updates required to the Card Reference File.

  1. Send Back. The Authorisation Engine sends the message back to the Host Interface, which, in turn, forwards it to the Transaction Router.

  2. Response generation. Based on the authorisation result, the ATM Interface generates a response message for the the ATM and forwards it to the Transaction Router, which, in turn, routes it to the required Communication Interface.

  3. ATM confirmation receipt. Once the ATM has executed the instructions contained in the response message, it sends a confirmation message back to the ATM Interface. Upon receipt of this confirmation, the ATM Interface updates the relevant tables in the SmartVista Front-End database to indicate that the authorisation transaction has been completed.
If SmartVista Front-End fails to receive such a confirmation for a transaction, this transaction will be marked in the Front-End database as 'suspect'.

If the ATM reports a partial cash withdrawal, the ATM Interface will generate an internal reversal transaction and forward it to the Host Interface. This, in turn, will refund the difference to the customer account.

If the ATM reports withdrawal failure, the ATM Interface will generate an internal reversal transaction for the entire transaction amount and send it to the Host interface for complete refund.



Copyright © 2001–2007, Banking Production Center. All rights reserved.