Solution Summary
For nearly a decade, CSFi has offered a proven integrated solution for EMV acquiring, issuing, and issuer-processing support with SWITCHWARE®. Our solution maintains the integrity of the payment transaction and takes full advantage of how EMV technology provides a secure way to handle card creation and cardholder authentication. Once deployed, liability can be shifted away to those who cannot support EMV chip cards, which means EMV compliant issuers and acquirers are absolved of any loss.
SWITCHWARE® is EMV-ready and contains the additional data elements necessary to support the latest EMV mandates. These data elements require only a few tables used in configuring the interfaces to support EMV. A new EMV data transaction log stores all of the EMV data received from an acquirer and issuer system. RSA security is used for authenticating the cardholder and common EMV functions used by all EMV-enabled interfaces, which are included in the base release. CSFi’s EMV base system license is required to activate the EMV functions in SWITCHWARE®.
SWITCHWARE EMV
- Offline PIN Verification
- Application Cryptogram Validation (ARQC/ARPC)
- Card Risk Management (Offline risk parameters & authorization controls)
- Card security code (CSC, CVV, CVV2) and Chipcard Security Code (iCVV or Chip CVC)
- Card Verification Results (CVR) Support
- Multiple cardholder verification methods (Offline, Fallback, Online, Signature, No CVM)
- All chip cards (ICC, Contact, Contactless, Dual Interface, All CVN types)
- Combined DDA & Application (CDA) cryptogram support.
- Issuer Scriptiong & Issuer Action Codes (IACS)
- Message Authentication Code (MAC) Support
Solution Diagram
EMV Issuing Support
EMV issuer support consists of Cardholder Authentication Method (CAM) verification, the means by which a plastic card is determined genuine and not counterfeit, verifying the Authorization Request Cryptogram (ARQC) and responding with Issuer Authentication Data.
HSM Interface. Card authentication is performed through special commands sent to a Host Security Module (HSM). The HSM supports RSA Key Management, verification of the ARQC (Authorization Request Cryptogram) and generation of an ARPC (Authorization Response Cryptogram). Available EMV-enabled HSM interfaces are provided using Thales HSM devices.
Smart Card Issuance Solutions
In addition to authorizing transactions as a smart card issuer, your organization may wish to issue smart cards with preloaded applications. In order to accomplish this, several components are required to support an “end-to-end” smart card issuance environment.
Pingen. The Pingen system’s main purpose is to provide PIN mailer generation and card encoding/embossing functions. To support EMV smart card issuance, Pingen is responsible for accessing SWITCHWARE®’s cardholder data tables for magnetic stripe, embossing and EMV data. Pingen then generates a PIN and outputs a file containing track1, track2 embossing and EMV data.
Pingen P3 Interface Module. The Pingen P3 interface module is used to prepare the EMV data file for importation into the Thales P3™ card personalization process system. The import file generated for P3 will consist of the embossing/encoding details, the PIN encrypted in ZPK defined between Pingen and the card personalization system and the EMV related tags setup for the cardholder in the SWITCHWARE® database.
P3™. The Thales P3™ Personalization Preparation Process system provides the functionality to define, generate and store cryptographic data that will ultimately be loaded onto the smart card. There are multiple P3 software solutions available that are designed to meet the needs of your EMV smart card issuance volume and performance needs.
P3 Cryptographic Functions. A P3 Crypto Module (P3CM) is used to perform the EMV cryptographic functions required by the P3 Personalization Preparation Process System.
EMV Acquiring Support
ATM Support. EMV-enabled ATM handlers support the acquisition of a smart card at an ATM terminal equipped with a smart card reader and Encrypting PIN Pad (EPP) that supports 3DES and MACing (Message Authentication Code). Available ATM handlers include:
- Diebold format
- NCR format
- Wincor-Nixdorf (Using their native extensions)
POS Support. EMV-enabled POS handlers support the acquisition of a smart card at a POS device equipped with a smart card reader and EMV compliant terminal program.
| Feature | Magstripe | SWITCHWARE® EMV |
|---|---|---|
| Storing data on the card (PAN, account inf, etc.) | Stored in the clear | Encrypted |
| Card data is protected and not easily skimmed or copied | No | Yes |
| The issuer can authenticate the card and the terminal as legitimate | No | Yes |
| The ability to identify counterfeit cards | No | Yes |
| Card can perform own risk assessment (rules for risk stored on the card) | No | Yes |
| POS terminal can perform own risk assessment (rules for risk stored on the card) | Rare cases | Yes |
| Issuer can generate dynamic cryptogram sent to the card | No | Yes |
| CVC 1 | Yes | Yes |
| Chip CVC | No | Yes |
| ARQC dynamic cryptogram generated at the time of the transaction | No | Yes |
| Chip security/service code (to differentiate between chip and magstripe) | No | Yes |
| Issuing system can be validated by the card using an ARPC | No | Yes |
| Send issuer scripts, modify applications, limits and other values stored on the card | No | Yes |
| Offline transactions allowed | No | Yes |
| Offline PIN allowed | No | Yes |
Commonly Asked Questions
How will the inclusion of a chip change the graphic design of the card? Where does our logo appear? How do we preserve our brand?
It’s likely that your organization has devoted considerable time and resources to developing your unique brand; that is the “look and feel” of your magnetic stripe cards. Because regulations specify the exact placement of the microchip on contact or dual interface chip cards, you may find you cannot re-use the design of your magnetic stripe cards without relocating graphics or text that will otherwise be displaced by the chip.
Note that in addition to the chip, you will typically still include a magnetic stripe on your new chip cards to enable your cardholders to use their cards at devices that are not chip enabled.
Which applications are included on the chip?
As part of planning your card personalization, in addition to making decisions about the manufacturing of the plastics (embossing, magnetic stripe encoding, and so forth), you must also make decisions about the applications contained on the card’s chip. Chip cards can contain multiple applications. For the purposes of our discussion, let’s focus on the financial and payments applications on your cards.
Some card applications are associated with a payment network’s scheme (such as MasterCard, VISA, American Express, Discover). Other applications are associated with regional switch networks. For your chip cards to be used at a chip-enabled terminal by your cardholders, there must be a match between one of your card applications and one of the applications that the chip-enabled terminal supports.
You may discover that requirements from a payment network, regional switch network, or even government may largely determine the applications you must have on your chip cards. If you do have options regarding the applications to include, consider the following:
• If your card issuing organization belongs to a global payment network (such as MasterCard, Visa, American Express, etc.) or regional switch network, your organization must work with representatives from those networks to determine which applications are to be included on chip cards bearing their logos. Networks typically require formal functional certifications for chip cards, as well as inter-member certifications. Choosing to include an existing, pre-certified application will enable you to get your cards into production faster.
• In addition to any required network-level applications, you may choose to develop your own ICC application. Note, however, that any new application will very likely be based on an existing ICC application and must be certified with the appropriate payment network (that is, applications based on Visa standards must be certified by Visa, and applications based on MasterCard standards must be approved by MasterCard, and so forth). Obtaining that certification may result in substantial delays in getting your cards into production; therefore your organization will need to carefully consider the consequences of developing and certifying a new chip application.
• The global payment networks have very strict regulations about how cardholder data is to be provided to chip card manufacturers and secured during the card personalization process. Your institution must conform to all of these regulations, in addition to existing PCI DSS (Payment Card Industry Data Security Standards) regulations.
Can we use the same BINs/Prefixes for our chip cards that we used for our magnetic stripe cards, or do we use new BINs/Prefixes? What are the advantages and disadvantages?
You already have BINs/Prefixes that you use for your magnetic stripe cards. Your card issuing organization must decide to either issue chip cards using those existing BINs/Prefixes or using a new (never before used) BIN/Prefix. Of course, if you use a new BIN, you must be sure to register that BIN with the appropriate network(s). The new BIN could be either an extended BIN (sharing the first ‘n’ digits with the existing ‘short’ BINs owned by the issuer) or a completely new short BIN. With SWITCHWARE®, it is possible to use existing card issues (BINs) or create new ones.
There are advantages and disadvantages to each approach, and your institution should examine all options carefully. For example, using a new extended BIN can enable you to establish host parameters exclusive to chip card authorization by BIN, if desired. Similarly, if transaction routing is based on BIN, you can use the extended BIN to identify and route chip transactions to a different endpoint than magnetic stripe transactions. You can also use BINs to distinguish cards by product, service, function, and so forth. Even if you choose to use your existing BINs to issue your new chip cards, you could still choose to use new PANs for chip cards.
Can we support the PIN change function for our chip cards?
Yes. With SWITCHWARE® you can optionally allow your chip cards to perform a PIN change at chip-enabled ATMs driven by SWITCHWARE. Alternatively, you might choose to offer PIN changes exclusively at your branch offices via a device in the branch that could send a PIN change script to the chip card. Note, however, that if you choose to support PIN changes at the ATM or branch, your cards and SWITCHWARE will need to contain the keys and programming to support these features.
How will we perform the steps needed for chip card authentication?
To perform chip card authentication, SWITCHWARE® must be able to communicate to your appropriate hardware security module (HSM), as well as the appropriate chip card authentication keys. Chip card authentication is too complex to discuss here at length, but involves steps such as:
• ARQC verification and ARPC generation – Verifying the authorization request cryptogram and generating the corresponding authorization response cryptogram.
• TVR/CVR checks – Verifying the Terminal Verification Results (TVR) and Card Verification Results (CVR).
• Fallback checks – Verifying transactions that were processed with a chip card at a chip-capable device, but which were completed using a magnetic stripe (typically because of an inability to read the chip). These transactions “fall back” to use of the magnetic stripe to complete transaction processing and can be indicative of fraud.
• iCVV check – Checking the Card Verification Value contained on the card’s chip.
• ROC check (POS only) – Verifying the Reason Online Code (ROC). The ROC indicates the reason that a POS transaction was forced to go online for authorization.