Successful authentication is a prerequisite for the processing of any on-line or offline CEPS transaction;sec
On-line authentication must take place between the card issuer and the CEP card for load, unload, and currency exchange transactions;sec
The card issuer and the CEP card share a secret key to generate and verify MACs;sec
Off-line authentication must take place between a PSAM in the POS device and the CEP card for purchase and cancel last purchase transactions;sec
The card and the PSAM must use a public key algorithm for mutual authentication and session key exchange, as no permanent shared secret key may exist between the CEP card and the PSAM;sec
To load value into a slot of the CEP card securely, the load device establishes a connection between the issuer and the CEP card;sec
The card should use a unique diversified secret key, personalized into the card, to generate and authenticate transaction signatures;sec
If this is not a cash load, the funds issuer needs to verify that the funds are requested by the legitimate account owner, which is normally done by the presentation of an enciphered PIN;sec
The card issuer needs to ensure that the load acquirer is guaranteeing payment for the electronic value, and that the card is authentic;sec
The load acquirer needs to ensure that the issuer is the true owner of the card, and, in the case of an apparent failure of the load, the load acquirer needs the card presented to authenticate the failure;sec
The load device sends S1 in an authorization request to the issuer;sec
The load device also provides for verification of the identity of the cardholder (with either on-line or off-line PIN verification) and forwards verification data in the authorization request;sec
The issuer validates S1 to authenticate the card and the data to be used in the transaction;sec
The issuer sends S2 to the load acquirer in the authorization response message;sec
Unloads are permitted only to an account controlled by the card issuer and are performed only at a load device under the control of the card issuer;sec
The cardholder must have an account relationship with the card issuer, and funds removed from the card are credited to the cardholder account only after the card issuer authenticates the card;sec
The issuer needs only to authenticate the card, and the card needs only to authenticate the issuer and that the data is the same as used by the issuer;sec
The card generates S1, using data from the card and load device, and sends S1 to the card issuer to authenticate the card and the data that is to be used in the transaction;sec
The card issuer generates S2, which is sent to the card to allow the card to validate the card issuer�??s authenticity and to ensure that the data used by the card in the transaction is the same as the card issuer intended;sec
In the case of an unsuccessful completion, exception processing outlined in the On-line Exception Processing section is performed;nonsec
During a purchase transaction, the CEP card must ensure that it is dealing with an authentic POS device, and it must generate a signature to allow the card issuer to verify the integrity of the transaction;sec
The POS device must ensure that it is dealing with an authentic card, and guarantee integrity of transactions and batches to the merchant acquirer;sec
In the case of a reversal, the CEP card must re-authenticate the PSAM;sec
The card must ensure that the transaction is performed by the same POS device as was used for the purchase being canceled, and that the amount of the cancellation is the same as the amount of the purchase, or, in the case of an incremental purchase, the same as the amount of the last step;sec
During a Cancel Last Purchase transaction, the CEP card is authenticated by the PSAM in the POS device;sec
The PSAM authenticates that the purchase transaction being canceled was performed by the PSAM, and that the transaction being canceled is part of the active batch;sec
The card issuer and the merchant acquirer also authenticate the transaction when they receive it;sec
Transmissions between host systems should be protected by MACs based on unique keys that are shared by the nodes involved;sec
The transaction signatures ensure end to end integrity of transmitted data for load, unload, and currency exchange transactions;sec
These totals are used by the merchant acquirer to ensure the integrity of the batch;sec
The count and amount of the transactions in the batch must be protected by the S4 MAC,  This information is not part of the card issuer�??s verification process;sec
Scheme providers must assign unique identifying numbers to merchant acquirers who provide PSAMs;sec
These merchant acquirers must then assign unique identifiers to PSAMs;sec
Each PSAM must maintain a transaction count, The unique PSAM ID and the transaction count are used during a conversation with a CEP card. The transaction count must not be reset during the life of the PSAM;sec
Contain the CA public RSA key, the PSAM�??s private RSA key and optionally the certificates that the POS device uses to perform mutual authentication with the CEP card;sec
Perform the calculation required to generate a signature using the PSAM�??s private RSA key, to allow the CEP card to validate the PSAM;sec
Contain the latest transaction count and amount of batches that have not been deleted from the POS device by the merchant or merchant acquirer;nonsec
Contain the details of a transaction between the initialize command for that transaction and the initialize command for the next transaction;nonsec
Be the entity that maintains control over the flow of a transaction, ensuring that all security is enforced;sec
Perform the verification of signatures and certificates during a purchase and cancel last purchase transaction;sec
Ensure that each batch of transactions is cleared and settled once and only once;nonsec
Send transactions to card issuers or their processors in a standard format defined in agreement with the scheme provider;nonsec
Ensure that CA public keys, aggregation parameters, blocking lists and issuer certificate revocation lists from the scheme providers are sent to the POS devices;sec
Share one or more MAC keys with connecting processors, create a MAC on each transmission sent to another processor, and verify the MAC on each transmission received from another processor;sec
Send transactions to other processors in a standard format defined in agreement with the scheme provider;nonsec
If a supported scheme provider has a dispute resolution process, participate in that dispute resolution process with connecting processors to resolve any issues related to invalid transactions. These resolution processes should include a mechanism for repayment of funds associated with invalid transactions;nonsec
The scheme provider must ensure that the entire process between merchants, merchant acquirers, card issuers, and processors is auditable and reconcilable;sec
If errors in the card issuer MAC are discovered by the card issuer during its processing of the transactions, a dispute mechanism, established by the scheme provider, may be used to have money refunded;sec
If a scheme provider establishes a central error repository, all transactions for the scheme with MAC errors must be sent to that central error repository whether or not they are submitted to the dispute process;sec
Payment for a transaction is only required when a detail transaction is submitted for payment, A merchant acquirer may choose to pay the merchant using the batch total;nonsec
The timing of payment to the merchant must be established between the merchant and the merchant acquirer;nonsec
A purchase transaction may be reversed, prior to the removal of the CEP card from the POS device, by sending a purchase reversal command to the CEP card, The CEP card must authenticate the PSAM using certificates previously exchanged;sec
The amount to be reversed is the amount of the last step of the transaction. The reversal command sent to the CEP card contains a S2 MAC computed by the PSAM;sec
The PSAM in the POS device generates a merchant acquirer S5 MAC for the transaction, computes a new S4 MAC on the updated batch total count and amount, and logs the transaction;sec
The CEP card authenticates the PSAM using the certificates previously received and the S2, The CEP card increments the value of the purse and logs the transaction;sec
The CEP card sends a response to the reversal command to the POS device. The reversal is considered to be successful even in the event of a negative response or no response from the CEP card;nonsec
After the CEP card is inserted in the POS device, the POS device initiates the cancel last purchase transaction;nonsec
If the POS device supports multiple applications or multiple transaction types, an interaction between the terminal and consumer or sales agent determines the CEP application and the function to be performed (cancel last purchase transaction);nonsec
The CEP card verifies that the PSAM is the PSAM used in the original transaction, computes a S1 MAC using the same DES session key that was used for the purchase transaction being cancelled, and responds to the POS device with the S1 and the identification of the last transaction. If the purchase transaction to be canceled has been canceled or is not part of the active batch, the command is not allowed;sec
The PSAM either retrieves or re-derives the DES session key used for the purchase transaction being cancelled. The POS device authenticates the CEP card using this key and the S1 MAC;sec
The PSAM in the POS device generates a merchant acquirer S5 MAC for the transaction and a new S4 MAC for the batch total count and amount and logs the transaction. The amount of the canceled last purchase transaction is subtracted from the header amount. The transaction is kept in a data store associated with the POS device until the merchant acquirer collects it;sec
A credit command, which contains the S2 MAC computed by the PSAM using the session key, is sent to the CEP card;sec
The CEP card authenticates the terminal using the S2 MAC and the session key from the purchase transaction being cancelled. The CEP card increments the value of the purse and logs the transaction. The CEP card verifies that the cancellation amount is equal to the amount of the last step of the purchase transaction;sec
A transaction collection process must exist. Data being transmitted from the POS devices must be transmitted in a manner that ensures integrity of the data;sec
The batch is sent to the merchant acquirer. Delivery may involve transmission to multiple intermediate locations or it may be direct to the merchant acquirer;nonsec
The merchant acquirer validates the batch to ensure that it has been transmitted correctly and enters it into the log;nonsec
If the business rules allow this transaction is to be aggregated, the PSAM must determine if it has an aggregation record for the card issuer. If the PSAM does not have an aggregation record for the card issuer, a new aggregation record for the card issuer must be created;nonsec
The aggregated totals by card issuer must be transmitted to the merchant acquirer at the same time and manner as the non-aggregated detail transactions in the batch;nonsec
Each POS transaction completed at the POS device is given a S5 MAC by the PSAM, which is used by the merchant acquirer to validate that the transactions were made at a POS device with a valid PSAM. The batch total count and amount must be protected by the S4 MAC, which must also be validated by the merchant acquirer;sec
The merchant acquirer validates the PSAM�??s MACs prior to accepting the POS transactions for payment. In addition, selected data elements are validated to ensure correct processing by the POS device and its PSAM;sec
Each purchase transaction is signed by the CEP card with a S6 MAC, which is used by the card issuer to validate that the transaction was made with a legitimate, not counterfeit, CEP card. The card issuer validates the CEP card�??s MAC;sec
Payment decisions are based on signature validations, scheme provider rules, and merchant and merchant acquirer agreements;sec
After investigation, if the merchant acquirer decides, based on scheme rules, to accept the transactions, a method must exist to settle them and forward them to the card issuer;nonsec
A transaction that passes merchant acquirer validations and is forwarded to the card issuer is paid for by the card issuer. If the transaction does not pass card issuer validations, the card issuer may follow the scheme provider�??s dispute procedures;nonsec
Pay on detail is the default payment arrangement for merchant acquirers to provide payment to their merchants. In this arrangement, the merchant acquirer relies on the POS transaction S5 MAC to determine acceptance. Merchants are paid only for valid POS transactions;sec
POS transactions that were rejected for payment by the merchant acquirer are flagged with an error code indicating the type of validation failure and are forwarded to the card issuer for CEP card history information only;nonsec
All load transactions are on-line transactions. Authorization of funds for load transactions must require a form of cardholder verification. The load device must support on-line encrypted PIN or off-line PIN verification;sec
Off-line PIN verification must include both encrypted and unencrypted PIN;sec
The card verification method indicator (CVMI) in the CEP card must specify support of online PIN verification and at least one method of off-line PIN verification (encrypted or unencrypted);sec
Since these transactions are on-line to the issuer, the issuer has the opportunity to lock the card or the application. These transactions are not available to a card that has already been locked;sec
Card issuers must inform their cardholders as to which currencies they support in electronic purses;nonsec
Load acquirers must determine the currencies that they must support for load transaction;nonsec
The CEP application must contain data that indicates the presence of a linked financial institution. If a linked financial institution is established for the CEP application, then linked loads must be allowed and data in the application must indicate whether linked loads are supported;nonsec
Flexibility is required to accommodate the variety of environments where unlinked loads may be implemented. As a result, the design specification must not preclude dual-leg transactions** from taking place either sequentially or in parallel. The design of a given implementation will vary depending on the device, host, and network capabilities;nonsec
Unload and currency exchange transactions are optional for CEP card issuers. The CEP card must indicate whether the card issuer supports these transactions. However, if a card issuer issues multi-currency capable cards, it must provide its cardholder with a facility to remove any remaining value. As a result, if a card issuer supports loading of multiple currencies onto a card, then it must support the unload or currency exchange transaction or both;nonsec
The card issuer must establish its policies for assigning and adjusting slot maximum balances. These policies may require the card issuer to maintain a card database;nonsec
Currency exchange rate fluctuations may increase the card issuers liability. The card issuer must be able to adjust maximum balances to bring them in line with their policies. The card issuer may update the maximum balances as part of a load, a partial unload, and a currency exchange transaction. On a currency exchange transaction, only the �??to�?� currency maximum balance may be updated;nonsec
A CEP card may contain currencies that the load acquirer does not support. As a result, load devices must use the alphabetic issuer-supplied currency code and currency exponent from the CEP slot(s) to display the source amounts for the currency conversion transaction;nonsec
Card issuers must provide an alphabetic currency code in each message that establishes a new currency. This alphabetic currency code and the currency exponent will be used by the load device to display currency balances. This allows the cardholder to identify the currency being displayed;nonsec
Script messages that conform to EMV specifications may be included as part of load, unload and currency exchange messages from the card issuer to the CEP card. An update key must be used when card parameters are changed. Script messages may be sent to the CEP card either before or after the credit for load, debit of unload and currency exchange commands;nonsec
All on-line messages must have the ability to include card issuer discretionary data from the CEP card;nonsec
The card issuer must notify the cardholder if the assessment of service fees by the card issuer during the currency exchange transaction may result in a balance of zero after the transaction has completed;nonsec
The card issuer must have the ability to deactivate a CEP application in the response to a load or currency exchange transaction;nonsec
The CEP card may support multiple currencies. Each currency occupies a �??slot�?� within the CEP. The slots are defined by the currency supported. The currency for an individual slot is determined during load or currency exchange. Currency exchange could apply to a single slot, and then only for the total balance;nonsec
It is a card issuer�??s decision to determine the currencies that are allowed to occupy slots in the CEP card. This decision is made by the card issuer during the load or currency exchange transaction, by approving or rejecting the request to authorize the transaction;nonsec
A single currency cannot occupy more than one slot. The CEP card must not permit a slot to be assigned a currency if another slot in the CEP card has already been assigned to that currency;nonsec
The CEP card limits each slot to a maximum balance. The maximum balance for a slot is established when a currency is assigned to the slot, and is determined externally by the card issuer or by CEP card data which indicates a maximum balance in a reference currency. There is no requirement that all slot maximums have the same relative value, and there is no requirement for the card to maintain a maximum total value;nonsec
Only one version of the CA public key is required in the card. This requires that the PSAMs with which the CEP card exchanges cryptograms must be capable of generating and validating cryptograms using the relevant keys from all current cards;sec
Two-way, or mutual, authentication, where the card authenticates the terminal and the terminal authenticates the card for each transaction, must be performed for off-line transactions;sec
For increased security and convenience, asymmetric cryptography must be used as the authentication security for off-line transactions;sec
The card must authenticate the terminal at the point of sale, ensuring that it is genuine and valid, and use a two-way authentication process;sec
The terminal must authenticate the card and the transaction at the point of sale, ensuring that they are genuine and valid;sec
The terminal must participate in a two-way authentication process with the card;sec
For cancel last purchase transactions, the terminal must validate the card and sign the cancellation;sec
The terminal must secure transactions by retaining the card�??s symmetric MACing key signature as part of the transaction;sec
The terminal must generate a symmetric MACing key signature and send it to the merchant acquirer;sec
Incremental purchase transactions must use two-way authentication for the initial session authentication, and at least one-way, with the terminal authenticating the card, for the remaining increments or some of the remaining increments;sec
Load and unload functions must be authenticated using end-to-end security between the card and the card issuer;sec
The issuer host must authenticate the card upon the load/unload request;sec
The card must authenticate the issuer host upon the response to the request;sec
A proof must be sent to the load acquirer that a load or unload occurred to avoid repudiation;sec
The management of keys must be accomplished in a secure, certified environment;sec
There may be multiple certification authorities that manage keys for the system, including the possibility of one overall highest level certification authority (perhaps on an international level), and domestic certification authorities for each country or region;sec
The system must protect the integrity of key transaction data including transaction identification, currency code and amount. If tampering is suspected, the system must cause the transaction to fail;sec
Expired cards must not be used for loading electronic value;nonsec
The time period during which a cardholder can unload electronic value, perform a purchase or a currency exchange from an expired card may be determined by each issuer;nonsec
Consumers must be able to load electronic value to their cards at any participating load device, regardless of the location, provided that the currency that is requested is supported by the acquirer and the card issuer;nonsec
Funds issuers must accept funds authorization requests, regardless of the load currency type, as permitted;sec
Load devices that are available to the general public should support multiple sources of funding and support both linked and unlinked loads;nonsec
Authorizations for load transactions require a form of cardholder authentication for funds requests;sec
The load device must support on-line PIN encryption or off-line PIN verification;sec
The load device which supports only off-line PIN verification must support both the off-line PIN encryption method and the off-line PIN plain text verification method as defined in EMV;sec
Unload transactions do not require cardholder authentication. (However, an acquirer�??s devices may be configured such that authentication is required for access.);sec
The architecture for the electronic purse should not preclude the eventual deployment of a variety of devices to meet the needs of many card acceptance environments. Unload must not be precluded from being supported on any or all of these devices at the option of the acquirer;nonsec