An Implementation Model for Contactless Bank Card Payment and Transit Smart Card Alliance: Transportation Council 8 March 2007
Agenda INSIDE Contactless Update on US Contactless Bank Card Issuance Convergence Models Implementation Approach for Dual Application Model
INSIDE Contactless Innovative, Focused, & Unique Only global fabless semiconductor company 100% focused on contactless Fundamental intellectual property 52 patents Unique microprocessor architecture for contactless applications First single chip NFC solution NFC Leader Delivery of > 100m contactless chips globally in past 3 years >50% market share provider for US contactless payment cards in 2006 Founded 1995, Located in Aix-en-Provence France; global sales offices
Contactless Issuer Update US Bank Card Market (credit, debit) ~1 billion bank cards today; Visa, MasterCard, Discover, American Express Credit transaction volumes along with total cards dominated by top 10 (80%) Debit has strong concentration up to 50% of market; then distributed >12 US Issuers Launched/Announced American Express Chase, Citibank, Wells Fargo, Bank of America, GE Money HSBC, Key Bank, Citizens Bank BB&T, Advanta, Fifth Third, SunTrust MetaBank Multiple issuers to launch in 1H 2007 Total of ~20M cards at end 2006 Additional ~30M cards into market in 2007
Converging Multi Application Models Model #1: Dual Application, Single Chip Open Bank Card Application (Visa, MasterCard, Discover, American Express) Co-Resident Transit Application Each application operates independently Single chip; single card Model #2: Dual Application, Dual Chip Open Bank Card Application Co-Resident Transit Application Each application operates independently Each resident on a distinct chip Deployed in a common card package From User View, Physically and Operationally Identical to Model #1 Model #3: Payment Application Only Open Bank Card Application Only Interoperable with transit acceptance points (like a bank card merchant)..and likely other hybrid models (Payment with Additional Data..).lastly, multiple models work; applicable in varying environments
Model #1 Considerations Applications distinctly specified by business owners Payment Association (Visa, MasterCard, Discover, American Express) Transit Agency and Integrator Co-resident contactless payment application use for transit kiosk purchasing Transit System Support Supportive of legacy transit environments Allows for adoption within new transit deployments Business Benefits Minimizes definition of new business rules Creates Issuer Opportunities for Strong Co-Brand Lowers Transit Owner cost of issuance Lower cost vs. multiple chips (model #1) and system upgrades (model #3) Simple to Implement Key Point for Today!!!
Implementation Concept Use of US contactless bank card (microprocessor) Current Situation ROM contains one or more bank card applications Selected application locked for usage (others locked out) EEPROM contains personalization data for selected application Additional available EEPROM Extension for Transit Populate transit application (data structure) into available EEPROM Populate specific transit data into transit application (read, write for life-cycle)
Data Structure Concepts EEPROM can structured with Directories and Files Data related to an application stored in a Directory File or DF, referred to by a unique identifier (AID) Inside a DF, application data stored in Elementary File(s) or EF DF and EFs are specified by ISO 7816-4
Data Update Lifecycle Chip Manufacturing Pre-Perso Perso Kiosk (Activate, Load) Transit Usage >OS & Payment App s in ROM >Transit Data Structure (Application) Load in EEPROM >Payment App Perso >Transit App Perso (optional) Pre-Personalization Details (Application Load) 1. Data containers are created in EEPROM -The DF AID is assigned -The key container(s) are created -The EFs are created with: EF N, type, size, access rights 2. Personalization Key is injected -Used during perso to inject the Non Payment Application key(s). >Transit App Perso (optional) > Turn-On Application >Purchase (Variety of Usage) > Transit Card Usage 3. The card is locked -No additional DF or EF can be added.
Implementation: Data Structure (EEPROM) Transit DF «Special DF» (PPSE*) Payment DF Personalization Key EF N 1: - Payment DF ID Issuer Personalization key Issuer Key EF N 1: Track 2 data Multiple EF s for Transit Data Storage Multiple EF s for Transit Data Storage Access Keys Payment Applications ROM resident Certified by Payment Associations Personalized at Issuer, Bureau Transit Application (Data Profile) EEPROM resident, Data Application (vs. a processing application) Data Application (..a data profile or directory)) loaded at pre-personalization or at personalization Initial data CAN be populated at personalization.or at transit kiosk
Other Implementation Considerations Flexibility in the core platform required for co-resident data applications Sufficient EEPROM must be available Support & review by card associations Fast processing requirements for transit application Support for authentication protocol; protection of core data Multi-brand payment support (i.e. best if Visa, MasterCard, Discover, American Express all available) Tools & Scripts required for: Pre-Perso, Perso
Conclusions & Challenges Implementation model is technically possible today Simple technique aids legacy integration Simplified business rules Advantages to both Transit and Financial communities Requires alignment of supply chain participants Industry challenge regarding legacy transit protocol
Thank You! Didier Serra GM Americas, EVP Sales 650-714-5430 dserra@insidefr.com