White Label Payment Olivier Sanrey

Transcription

1 White Label Payment Olivier Sanrey

2 Agenda Introduction The three different types of White Label solutions The EMV Common Payment Application (CPA) Two CPA case studies

3 A White Label is a Payment System independent from global payment brands Open-Loop: Scheme = many issuers + many acquirers Example: National Debit Scheme Closed-Loop: Scheme = one issuer = one acquirer Example: Company Cantine Industries: Banking, Retail, Transit, Loyalty, Fuel cards, Lunch vouchers, Access systems, etc.

4 A White Label solution fulfills various needs of various branches and markets Banks Own rules, certification processes Alternative technology Own business model Multi-applications Independence Limit acceptance Consumer financing models Retail Cash substitute Consumer stickiness Transit

5 Agenda Introduction The three different types of White Label solutions The EMV Common Payment Application (CPA) Two CPA case studies

6 Three White Label configurations Classical scheme Their brand 1 Global Scheme licensing My Brand Their technology 2 3 Proprietary application My brand Their technology EMV CPA* My brand My technology Our technology * Common Payment Application

7 1 Global Scheme Licensing My Brand What is that? Their technology Special agreement: license agreement to use established scheme technology. White Label: global scheme brand is not appearing on the device. Difference: same setup as traditional scheme, but debranded. Possibility to limit acceptance. What are the pros? Time to market: no development lead time. Proven technology: chip production, personalisation, terminal configuration, etc. Multi sourcing: existing off-the-shelf products, various OS and devices. Type Approval: procedure is existing. Migration: easy to migrate to global brands. What are the cons? Dependency: based on traditional payment scheme rules and obligations (TA, etc.), reduced flexibility. Costs: most probably license fees. Conditions: agreement might be conditioned (e.g. noncompetitive scheme, complementary scheme).

8 2 Proprietary Application My brand What is that? Proprietary: scheme own specifications, not standardized. Option: part of EMV like CCD with additional proprietary features. My technology What are the pros? Independence: fully independent solution. Fit for purpose: solution matches 1:1 the issuer needs, enables light specification. What are the cons? Interoperability: communication with existing terminal infrastructure not standardized. Infrastructure: major infrastructure efforts required. Migration: migration to another product complicated due to not standardized solution. Type Approvals: No type approvals for a full application. Multi-sourcing: No possibility for multi-sourcing.

9 3 EMV Common Payment Application (CPA) My brand What is that? Our technology What are the pros? Independence: independent but standardized. Time to market: no development lead time for the card application. Proven technology and multi-sourcing: chip production, personalisation, terminal software, etc. Multi-brand: application can be used for global brands like MasterCard and VISA. EMV: specification developed by EMVCo, complies with EMV CCD. Application: fully functional application similar to M/Chip or VIS. Availability: specification is made available royalty fee free. Type approval: Type approval process available at EMVCo. What are the cons? Infrastructure: infrastructure efforts for the scheme (host, Certification Authority, etc.). Specifications: sophisticated, no type approval or dedicated specification for contactless for the moment.

10 Agenda Introduction The three different types of White Label solutions The EMV Common Payment Application (CPA) Two CPA case studies

11 The Common Payment Application (CPA) CPA/CCD 2004: EMVCo publishes CCD (Common Core Definitions) a set of minimum requirements for cards based on the EMV standard, which has now been incorporated into EMV 4.3. JSmart EMV 4.3 MChip/4 2005: EMVCo member working group -- with support from MasterCard, Visa and JCB -- released CPA a specification for a CCD-compliant common payment application. Common Payment Application is a chip application that can be used to issue multiple brands VSDC Key objective: Provide issuers one card application for all international and domestic brands

12 CPA Scope of development, implementer and issuer options EMV CPA Min. Specification Implementer options Issuer options CPA DDA/CDA EMV CPS option Max Days offline check DDA/CDA Authentication Profile Selection Using Card Data Counters Application security counter Accumulators CCD Low Value Payment Other profile relevant options Must have, Type Approval relevant implementation. Implementer can decide whether or not to develop these functionalities. Configuration made by the issuer like in every EMV projects.

13 Common Contactless Application (CCA) The CIR (Common Implementation Recommendations) Technical Working Group is an open standardisation initiative of EMV implementers in Europe. Requirements for an EMVCo Common Contactless Application (CCA) have been presented to the EMVCo Board of Advisors. The Common Contactless Card Application (CCA) is a contactless implementation based on the Common Payment Application Specification (CPA).Implementing the Common Contactless Card Application on a CPA card does not require more than: - Support of the contactless transmission mode according to the EMV Contactless Communication Protocol Specification - Support of the CPA implementer-options "Dynamic-RSA" and "Profile Selection Using Card Data". Source:

14 Agenda Introduction The three different types of White Label solutions The EMV Common Payment Application (CPA) Two CPA case studies

15 CPA case study 1 [ FLEET CARD ISSUER ] Specific needs Remain independent Possibility to go offline EMV solution compatible with global payment brands Loyalty functionalities Initial situation Closed-loop payment system Based on magnetic-stripe technology Facing increasing fraud Results First cards issued in CPA-DDA Expected fraud reduction and improvement of the loyalty system

16 CPA case study 2 Specific needs Manufacturer-independent multiapplication platform High security requirements Technical interoperability Initial situation Increasing number of applications Innovation cycles are permanently becoming shorter Results More than 100 Mio cards based on CPA No interoperability issues reported Engagement to move forward towards a contactless solution Source:

17 SECCOS in GERMANY Overview Standard Applications Brands SECCOS Debit -> DK Type Approval MC Credit/Debit -> EMVCo Type Approvals EMV CPA VISA Credit/Debit -> EMVCo Type Approvals SECCOS Debit -> DK Type Approval planned MC Credit/Debit -> MasterCard Type Approval VSDC VISA Credit/Debit -> Specification outstanding/setup not confirmed Geldkarte SECCOS Prepaid SECCOS Prepaid -> DK Type Approval -> DK Type Approval Loyalty Various profiles Parking, etc.

18 Thank you