PURSE INTEROPERABILITY
The invention relates to electronic purse applications. Such applications are not new technology; they allow consumers who do not have, or cannot obtain, bank accounts, a means of carrying 'cash' with reduced risk. These same consumers are, of course, excluded from paying by credit card by the very fact that they do not hold a bank account. The card application allows them to pay merchants or vendors involved in the scheme using the card.
One well-known application in this field is the EMV (Europay/MastercardΛ isa) compliant Visa debit/credit V1.3.2 smartcard application detailed in Visa Integrated Circuit Card: Card (ICC) Specification, Visa International, Version 1.3.2, July 1999. The application allows a card to determine whether a user should be allowed to complete off-line transactions according to in-built card risk management rules. These rules are based on limits specified by the card issuer. Under the Visa scheme, the card is also allowed to force a transaction to go on-line to the issuer if certain limits are exceeded. The card can also decline a transaction instantly if additional limits are reached. All of these limits are configurable by the card issuer and are set according to the issuer's requirements for the application. They also incorporate the cardholder's credit history and requirements.
The problem with existing card applications and schemes is the lack of infrastructure needed to support the various schemes in operation. A classical 'chicken-and-egg' situation occurs; unless there are sufficient terminals available for a cardholder to use, the card scheme is of little assistance to the cardholder. Conversely, merchants and vendors cannot be expected to invest in terminals to accept cards, unless there are a significant number of cardholders to support a particular card or purse scheme. Clearly, this situation would be improved if terminals were capable of accepting cards from a number of different schemes.
In accordance with the invention, there is provided a smartcard and a smartcard system comprising a card bearing an electronic purse application including a current purse value data item and an interface device by means of which the current purse value data item can be input to the electronic purse application; the card also carrying a card risk management application requiring at least one limit value data item; the system being characterised in that the card risk management application utilises the said current purse value data item as the required limit value data item.
The current purse value data item and the limit value data item may be stored on the card using different formats; the card is, in a preferred embodiment provided with means for converting the current purse value data item to the format used for storing the limit value data item.
Three schemes dominate the retail environment, those of Visa, Europay and Mastercard. In a preferred scheme in accordance with the invention, the same terminal would accept all three kinds of card for payment and existing terminals could be converted to accept all three cards transparently. This would have the advantage to the cardholder that it would no longer be necessary to search for a retail outlet with a terminal specific to his card before being able to use the card to pay for items. (Although, it may be desirable to require a specific terminal to be used to 'reload' the card.)
For the merchant/vendor, such a scheme has the advantage the card can be accepted and will perform the 'normal' transaction irrespective of the terminal used, secure in the knowledge that settlement will occur in the usual way.
An embodiment of the invention will now be described in detail, by way of example.
The core of the Visa application referred to above is a function called Generate Application Cryptogram ('GenerateAC'). One of the key functions of GenerateAC is that of Card Risk Management; during this function the card decides whether or not to accept a transaction, to request that the card goes online or to decline a transaction.
If the card requests to go online, a second GenerateAC command is usually executed so that the card is informed of the issuer's response and/or whether the terminal was actually able to communicate with the issuer. The card then employs further risk management rules to determine how it should react to the different possible responses, that is, either accept or decline transaction.
All of these interactions are transparent to the cardholder. The only indication that either the card holder or merchant/vendor will receive that any additional processing is occurring is that the transaction will take longer to complete if the card and terminal have to go online to the issuer to resolve the transaction status.
It is clear from this that it is at the risk management points of the EMV application that any purse application on the consumer's card must interact with the credit/debit application.
The Visa application specification utilises three data items which are of particular interest. These are described in Table 1 below and are explained in detail in Appendix A of the Visa specification referred to above.
Table 1
With respect to the first of the two possible GenerateAC commands, these data items are used at a point in the card risk management where the amount of the transaction (Amount Authorised - 'AA') is combined with the COT and then compared to the Cumulative total Transaction Amount limit ('CTTAL'). If the combined total exceeds the CTTAL, the transaction is generally forced to go online.
It is only at this point in the transaction flow that the actual amount of the transaction plays any part in the decision process. In effect, all three data items are counters and can be regarded as such. In a similarly simplistic view, the balance held on an electronic purse is also a counter. All of these 'counters' have application-specific rules as to when and how they are updated.
From this, we have appreciated that there is an opportunity to integrate the purse application.
As a starting point we have considered the on-card applications not to be completely independent of one another. This is a valid assumption because, in fact, most applications share data items such as the PIN used to access the card. If this idea is extended, then there is no reason not to share other information as long as access to those data items is strictly controlled when those items are to be written, updated or read.
For example, if we consider the purse balance, it can be assumed that the balance can only be updated via a dedicated terminal which accepts cash, performs suitable mutual authentication with the card and then credits the card's cash balance with the received cash value. If this data item is then also referenced as the CTTAL within the Visa application, it is clear that, as cash is spent, the COT will be incremented with each AA received in each offline transaction (as per the normal Visa application flow) until a point is reached where the offline amount stored plus the amount of the desired transaction exceeds the CTTAL (the purse balance) and an online transaction is required to reload the purse.
The Visa application allows for 15 bytes of Issuer Discretionary Data, which terminals (in national markets only) pass back to the issuer for interpretation. As the purse vendor is the issuer, the opportunity to place status, balance and any other information the issuer desires is provided for via this mechanism.
If the merchant terminal has the means to accept cash from the cardholder at that point, it may be possible to perform a reload of the purse balance at the merchant terminal. The COT and CTTAL can either be reset as part of the proprietary purse LOAD command or via a zero amount transaction followed by the secure messaging commands detailed below.
If the merchant terminal cannot accept cash, visiting the purse issuer's dedicated terminal will allow the purse balance (limit) to be configured under the complete control of the issuer. A dummy EMV transaction, for a zero amount, can then be performed by that terminal to reset the COT value so that the cardholder can immediately use the card in an offline environment.
If this is the case, and there is a mechanism for the issuer to ratify that cash has been received by the merchant on his or her behalf, script processing can then be used to update the CTTAL value via a PUT DATA command. The additional benefit of using this value as the 'hook' between the two applications is that there are no limitations as to when the PUT DATA command is executed. If this value were stored in a record within a file, for instance, then the UPDATE RECORD command with secure messaging would need to be invoked. The issue here is that with the current Visa application, only non-critical script processing is supported. Thus, no script processing can occur between GenerateAC commands. Any updates can only be performed after the transaction has been concluded under the currently supported Visa application.
Thus, in effect, if the purse issuer is the Visa card issuer, the purse balance can be controlled precisely by the issuer using standard Visa functionality.
If, on the other hand, another standard profile, for example, the Europay/Mastercard Mchip Lite profile, were to be used, the same functionality is provided by the comparison of the AA when added to the COT with the Upper and Lower Maximum Off-line Cumulative Amounts. These items are records within the Card Risk management file, but, as the applications supports critical scripts, the issuer can update the balance of the purse (limits) by executing UPDATE RECORD commands between the two GenerateAC commands required to complete the transaction. This again assumes that there is a mechanism by which the merchant can accept cash or payment and this can be ratified between the issuer and the merchant.
In the cases where this is not possible, the transaction is simply declined and a standard reload of the purse (with whatever security mechanisms for authentication and data integrity that that scheme provides) is used to add value to the purse. The balance repository if the purse is updated as per normal and the next time the Visa application is called on to perform a transaction, the current purse balance will be extracted and used.
The main difficulty which arises is the possibility of a discrepancy between the format used to store the purse balance and, specifically in the case of the Visa application, the CTTAL, which, in the case of Visa V 1.3.2 is a BCD encoded 12-digit value. If the purse application uses a different mechanism, then one of the two applications will require additional functionality to convert the value to the correct format.
For example, in the case of an existing purse which does not have the correct data format for its balance, it is fair to assume that new cards incorporating this use of both purse and EMV terminals will be issued. It is not unreasonable for the new purse application on these cards to convert the value in the proprietary LOAD_VALUE command into the format used by Visa. The conversion to/from the storage format can be handled by that purse application. This will ensure that existing purse cards and the 'new' purse cards will operate correctly with the dedicated purse terminals.
Conversely, if it is not possible to modify the purse application, it will be necessary to modify the EMV application to perform format conversion when accessing this data value. Additional flags will also be required within the Visa implementation to determine when any modification of the CTTAL value is being performed as part of a Visa standard PUT DATA command when the standard Visa formatting of the command data is being used. All reads and writes of the value will have to be aware of the formatting conversion which occurs. The major impact of this is the need for recertification of the EMV application for any change. Once achieved, interoperability is ensured.
While the invention has been described in relation to the Visa debit/credit V1.3.2 and Europay/ Mastercard Mchip Lite applications, it will be apparent that any EMV application satisfying these specifications will utilise the same group of values and that the format conversion necessary for interoperability can be implemented for other applications as well as those described above.