SPECIFICATIONS FOR INTEROPERABLE E-PURSE IN INDIA
The specifications for a globally interoperable e-purse published by CEPSCo have been evaluated
in detail for their advantages as well as disadvantages for being considered as the basis for
interoperable e-purse schemes in India. CEPS is perhaps the only globally supported initiative for
an open platform and vendor independent framework for interoperable electronic purse schemes.
A cross-border pilot for CEPS titled DUCATO was completed in December 2001 in Spain,
Netherlands, Belgium and France. - demonstrating international interoperability of
different CEPS-based e-purse technologies. Although CEPS is now ready as a
technology platform, with at least 3 different commercially available implementations, the
actual migration in Europe from proprietary e-purse systems to CEPS is expected to be a
slow process. As a standard, CEPS is perhaps at a stage where EMV was 2 years ago.
1. Currency exchange for cross-border transactions (a major feature in CEPS, developed
because of the needs in Europe), is an overspecification and is not a requirement for the Indian
e-purse system. Unlike Europe, India is a large sub-continent and almost no business case exists
for cross-border micro-payment transactions (except for transactions on the internet). Providing
currency exchange facilities on cards, hosts and terminals will increase the system complexity,
introduce the variable of exchange rates (which is complex to manage in an off-line system with a
time lag in the processes of load, transaction and settlement).
2. Another specific instance of over-specification is the support for truncation and aggregation
options, neither of which are expected to be of practical use. It is unlikely that financial institutions
will choose to deploy any procedures which increase system risk.
3. The use of dynamic data authentication and PKI requires a crypto-co-processor which
increases the card cost.
4. CEPS requires a multi-level (3 or 4 level) hierarchy for the PKI system. Currently, the CCA
only permits a flat 2 level hierarchy in India.
5. CEPS requires compliance testing and certification of all system components. There are
currently no CEPS certification facilities in India. Certification for CEPS can be an expensive
and time consuming process for the Indian domestic industry.
6. CEPS prohibits the use of PIN or signature or any other form of cardholder verification during
a purchase transaction. This is mandated to allow simple CEPS compliant terminals which do not
need to have a PIN pad (such as a vending machine). The absence of a PIN presentment feature for
offline transactions means that the entire available balance on a card is lost to the customer when a
card is lost. therefore refund of value on a lost card is presently not an option with CEPS.
1. The specifications are complete, exhaustive, and well documented, representing 3 years of effort
by industry resources.
2. CEPS specifications are free, open, and vendor independent. CEPS has no associated royalty
costs (commercial implementations by various vendors may have a royalty or cost component
particular to the vendor). Anyone can implement CEPS specifications. Multiple CEPS schemes
from different vendors can co-exist and be inter-operable.
3. The existence of a credible compliance testing and certification regime for CEPS is perhaps the
most valuable reason to stay as close to CEPS as possible, at least in the initial period. Without a
defined certification process and an available certification facility, issuers have no means to be
sure of the integrity, quality, security and validity of any implementation. An end-to-end system
certified to ensures interoperability can be deployed today with CEPS without losing any time.
Migration to a system that still remains compliant and also address specific domestic needs of
India can happen shortly thereafter as a planned process. Starting the process from scratch, though
entirely possible technically, will cost years in development time before the first cards can be
issued (even after that, any system developed from scratch will remain a proprietary and country
4. CEPS have been implemented in a multi-country, multi-scheme pilot, and are already
commercially available from at least 3 different vendors. Europay and Visa have CEPS compliant
brands and networks.
5. CEPS uses PKI based authentication. This is an advantage as the IT Act 2000 in India now
legally recognizes PKI based digital signatures for non-repudiation. This lowers deployment risks
and provides a secure basis for issuers, acquirers and network providers.
6. CEPS allows scheme or country specific enhancements in actual implementations.
The approach for specifying an interoperable e-purse for India
1. The published business and functional requirements of CEPS have been stripped of 3 specific
features, all of which are optional and not mandatory for functional interoperability: currency
conversion and multiple currency slots (inter-related features); truncation; and aggregation.
These features are considered unnecessary, irrelevant or not viable for implementation in India.
The cards, terminals, hosts and the clearing and settlement systems of the actual scheme therefore
do not have to implement the functionality of these features.
2. The remaining portions of the business and functional requirements are retained exactly. This
therefore creates a sub-set of the CEPS requirements without introducing the need of any new
3. At the same time, the technical specifications of CEPS which define the basis of actual
interoperability data elements; message formats; coding tables; status conditions; initialization,
validation and exception processes are retained in their entirety, even where they refer to currency
conversion, currency slots, truncation and aggregation. In such a scenario, as an example, the
currency will always default to the Indian Rupee; the number of currency slots will always default
to one; the currency conversion related menu items will not be offered in any terminal; data fields
for truncation and aggregation will exist but will not be utilized.
4. The actual resultant scheme will definitely not be interoperable at an international level, as the
currency conversion has been done away with. It will not be possible to get an unqualified CEPS
certification for such a host system. However, because all cards and all terminals in such a scheme
will be fully interoperable domestically with ANY scheme certified by CEPSCo, the creation of a
'domestic CEPS' certification category will be requested of CEPSCo.
5. The above approach retains full functional domestic interoperability without implementing
unnecessary features, and more importantly, without giving up on the benefits of the compliance
testing and certification facilities available. It also ensures that all CEPS certified cards, terminals,
hosts, and peripheral systems and components available today can be used without need of any
modification or re-certification. This provides a viable basis to start an India specific
implementation without losing any time.
6. Retaining technical specifications in their entirety provides a major incentive to local
manufacturers of system components. Any cards, terminals, and other devices will be certified for
complete CEPS compliance, and will therefore have a global market available to them.
7. All scheme specific user defined data fields will still be available for enhancements or added
functionality. These fields will be used to add custom functionality required in Stage 1.
8. PKI will be deployed with a multi level hierarchy as a pilot approach, with the CCA as an
observer. IDRBT will be the root key management authority for participating Banks. Functionally,
it is not a problem to go with the present flat 2-level hierarchy for the pilot. However the
establishment of a true multi-level hierarchical system of trust is essential for building the
'exclusive' domains (based on exclusion) of trust that Banks will want to work within.
9. To move on to stage 2, a full functional compliance testing and certification facility must be set
up in India, with an independent mandate to certify an 'India-specific' variation of CEPS. This
process is likely to take between 9-12 months if requisite funding and expertise is available. This is
the stage when it will become feasible to make significant departures based on experience gained,
and add new functionality specific to India's needs.
ADDITIONAL FUNCTIONALITY (not fully defined in CEPS)
Low cost merchant terminals (wallet class terminals) with two full form factor removable cards
(one customer e-purse card, and one merchant PSAM card) are a business requirement for India.
This requires the complete transaction details to be stored in the memory space of the PSAM card.
This is in neither prohibited nor completely specified in the specifications. It is normally expected
that the transactions details will be stored in the memory of the terminal hardware. Further
specifications are therefore required to define the memory usage of the PSAM card during a
purchase transaction as well as a collect transaction. This will also require a larger memory PSAM
card to store all the transactions (though this aspect does not affect specifications).
CONFLICT AREA WITH CEPS
CEPS explicitly prohibits the use of PIN for e-purse purchase transactions (although PIN is
mandatory for load). This may be un-acceptable in the specific environment of India. Customized
functional enhancements are required to the CEPS specifications for PIN presentment and card
revalidation to enable refund of balance on lost/stolen cards. However, no PIN protection implies
that the stored balances on cards that have been stolen or lost cannot be refunded. As a calibrated
compromise between the two situations it is proposed that no PIN will be required for cumulative
transactions below a total of Rs. 500 (a user or issuer definable limit), from the last transaction
where a valid PIN was presented (an incremental counter of transaction amount is maintained
on-card, which resets to zero every time a valid PIN is presented). Whenever this limit is exceeded,
the card will initiate a PIN request on the terminal. Additionally, an on-line revalidation of the card
will always be required 45 days (a system defined limit - cards will keep a record of the date on
which the last on-line revalidation of the card was performed) from the last such revalidation (this
revalidation may happen automatically in all on-line transactions). The combination of the above
mentioned procedures will allow the Banks to refund balances on lost/stolen cards which have
been reported, after 45 days of the reporting of the loss, with a maximum possible loss of Rs. 500.
It is important to give customers this security, to enable large scale take up of cards. This
implementation will result in a certain degree of inconvenience to customers (A PIN request may
turn up in the course of a small purchase. Revalidation is an online process and may suddenly be
demanded by the card though there is no online terminals available immediately). However, these
inconveniences will be well outweighed by the assurance of refund on lost or stolen card. The
refund option, will be implemented only at the discretion of the issuing Bank.
Documents sent in a separate e-mail and also by courier on a CD:
1. Business Requirements for Interoperable Purse: ver 7.0 published by CEPSCo: Portions not
considered necessary for India are crossed out.
2. Functional Requirements for Interoperable Purse: ver 6.3 published by CEPSCo: Portions not
considered necessary for India are crossed out.
3. Technical Specifications for Interoperable Purse: ver 2.3 published by CEPSCo: Retained
without any change to allow true interoperability with off-the-shelf certified systems, cards and