Interoperability Working Group Issues List

EMV^® Interoperability Working Group Issues List Version 6.3 September 2017 Ref. IWGVR039-V01 © 2017

countries. EMV^® Interoperability Working Group Issue List v6.13

Legal Notice

The EMV^® Specifications are provided "AS IS" without warranties of any kind, and EMVCo neither assumes nor accepts any liability for any errors or omissions contained in these Specifications. EMVCO DISCLAIMS ALL REPRESENTATIONS AND WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NONINFRINGEMENT, AS TO THESE SPECIFICATIONS. EMVCo makes no representations or warranties with respect to intellectual property rights of any third parties in or in relation to the Specifications. EMVCo undertakes no responsibility to determine whether any implementation of the EMV^® Specifications may violate, infringe, or otherwise exercise the patent, copyright, trademark, trade secret, know-how, or other intellectual property rights of third parties, and thus any person who implements any part of the EMV^® Specifications should consult an intellectual property attorney before any such implementation. Without limiting the foregoing, the Specifications may provide for the use of public key encryption and other technology, which may be the subject matter of patents in several countries. Any party seeking to implement these Specifications is solely responsible for determining whether its activities require a license to any such technology, including for patents on public key encryption technology. EMVCo shall not be liable under any theory for any party’s infringement of any intellectual property rights in connection with the EMV^® Specifications. © 2016

countries. EMV^® Interoperability Working Group Issue List v6.13

1. 3. 3. 3. 3. 3. 3. 3. 3. 3. 3. 3. 3. 3.

v6.13

1 Interoperability Issues 1.1 Summary of Findings and Status Of the interoperability incidents reported to EMVCo, the IWG has determined that few of the problems are true EMV interoperability issues that could have been prevented either by clarifications to the EMV specifications or the related EMVCo Type Approval testing process. As of September 2017, with ninety-one total reported incidents, only one of the earlier issues required a change to the EMV specifications. In a number of the reported incidents, EMVCo has published application notes, bulletins, or best practice guides to help prevent interoperability problems as indirect consequences to resolutions. In other incidents, EMVCo test cases have been added or updated so that similar incidents might be prevented in the future. Many of the reported issues were the result of:

• Improper behavior of chip devices deployed prior to the establishment of EMVCo approvals
• Member card personalization and terminal implementations
• Payment system and network-related incompatibilities All these types of incidents, reported to EMVCo, were (and will continue to be) transferred to the appropriate payment system for resolution. For the most effective problem management of interoperability issues, incidents are best reported directly to the payment system. The primary reasoning for this approach is because: 1. A majority of the problems, as evidenced by the incidents initially reported to EMVCo, are not directly or indirectly consequential to EMV specifications or EMVCo type approval test cases. 2. The resolution of almost all the reported problems is most effectively implemented by the payment systems in conjunction with its affected Members directly. Should any actions need to be taken by EMVCo, or should the issue be likely to have global impact, payment systems have been requested to forward these requests along with the problem background to the IWG. v6.13 2 Explanation for Problem

Impact

Classification In order to better depict problem severity, all the issues have been given a classification of Red/Yellow/Green (or High Medium Low) in three categories – Transaction Result, Volume and Field Implementation. The classification for each reported issue can be found in each issue summary in Section 3. The levels and characteristics of each category are: 1. Classification by Impact of Transaction Result ●=HIGH TRANSACTIONS ABEND OR RESULT IN DECLINES ◓=MED TRANSACTIONS COMPLETE WITH MAJOR ERRORS ○=LOW TRANSACTIONS COMPLETE BUT WITH MINOR ERRORS; FALLBACK/WORKAROUND IN PLACE N/A NO INFORMATION AVAILABLE OR NOT APPLICABLE 2. Classification by Volume Impact ● HIGH NUMBER (BY PERCENTAGE OR ABSOLUTE VALUE) OF DEVICES OR CARDS INVOLVED; BRAND IMPACT ---- EMV REPUTATIONAL IMPACT ◓ POTENTIALLY HIGH VOLUME; ROLLOUT CONTINUING; PROBLEM FIX NOT DEFINED OR DELAYED ○ LOW VOLUMES; CONTROLLED PILOT; PROBLEM FIX IMPLEMENTED N/A NO INFORMATION AVAILABLE OR NOT APPLICABLE 3. Classification of Field Implementation Status (NEW) ● NO PROGRESS (MAJOR DELAYS OR NO MOVEMENT AT ALL) ◓ SLOW PROGRESS (MINOR DELAYS OR UNDER MAINTENANCE MODE) ○ GOOD PROGRESS (REPLACEMENT ACTIVELY ONGOING) N/A NO INFORMATION AVAILABLE OR NOT APPLICABLE

v6.13

*NOTES: Classification for #1 and #2 problem impacts and for #3 Field Implementation Status will be primarily based on information from the payment system. If no or limited data on problem impact is available from a payment system, the IWG will use its best judgment to properly classify it. Problems reported by the payment system will be rated high or medium based upon the rating assigned in the notification. The original rating will not be changed during the lifecycle of the issue so as to preserve the history of the initial impact, but changes in the status will be updated as "Current Assessment".

v6.13 3 Details

3.1 Issues

Summary

The table below and the sections following summarize the interoperability issues reported to the IWG. Actions resulting from these issues are either the responsibility of EMVCo or the payment system. In some cases, a particular issue may affect both EMVCo and the payment system for actions and/or resolution. Therefore, the issues have also been grouped by the "actors" who are primarily managing them -- EMVCo, Payment System, or Both. Since the last publication of this list, one issue has been closed with no new issues entering the List EMVCo Both EMVCo and Payment System Payment System Assessment in 0 0 0 Process Resolution in 0 0 0 Process Pending 0 Implementation Open Issues 0 Closed Issues 31 (I0062, I0050, I0048, I0047, I0045, I0043, I0041, I0038, I0036, I0031, I0030, I0029, I0027, I0026, I0025, I0024, I0023, I0022, I0021, I0016, I0015, I0013, I0012, I0011, I0010, I0007, I0006, I0005, I0004, I0002, I0001) Total Issues 31 0 0 33 (I0091, I0090, I0089, I0088, I0087, I0086, I0085, I0084, I0083, I0082, I0081, I0080, I0079, I0078, I0077, I0076, I0075, I0074, I0073, I0069, I0068, I0065, I0064, I0061, I0060, I0057, I0058, I0055, I0054, I0051, I0049, I0046, I0044) 33 0 0 27 (I0072, I0071, I0070, I0067, I0066, I0063, I0059, I0056, I0053, I0052, I0042, I0040, I0039, I0037, I0035, I0034, I0033, I0032, I0028, I0020, I0019, I0018, I0017, I0014, I0009, I0008, I0003) 27 Total 0 0 0 0 91 91

v6.13 3.2 Assessment in Process – EMVCo (none)

3.3 Assessment in Process -- EMVCo, Payment System (none) 3.4 Assessment in Process -- Payment System (none) 3.5 Resolution in Process -- EMVCo (none) 3.6 Resolution in Process -- EMVCo, Payment System (none) 3.7 Resolution in Process -- Payment System (none) 3.8 Pending Implementation – EMVCo (none) 3.9 Pending Implementation -- EMVCo, Payment System (none) 3.10 Pending Implementation -- Payment System (none)

v6.13

3.11 Closed -- EMVCo Activities Complete EMVCo Identifier Issue Identifier Status Date Opened

Description

Findings I0062 Transaction Severity ◓=MED I0062 Volume Severity ◓=MED Closed – EMVCo July 07, 2006 It was reported that some terminals do not accept the card with zero value in ATR historical bytes, sometimes fall back to magnetic stripe transaction. It seems that the terminals reject some Belgian cards which contain zero value(s) on the ATR. The terminal may not support the zero value(s) for the historical bytes in the ATR. Terminal Information Corrective Action Preventative Action Additional Comments Some Cybernet JADE terminals The terminals have been replaced Best Practice regarding this issue has been published on the website. EMVCo Identifier Issue Identifier Status Date Opened Description Findings Corrective Action Preventative Action Additional Comments I0050 Transaction Severity N/A I0050 Volume Severity N/A Closed – EMVCo, Jan 25, 2004 Dec 3, 2003 It was reported that EMV chip cards are not accepted at French chip-capable devices displaying the payment system logo. Only French bankcards are currently accepted. This is a similar issue to I0041 with the non-acceptance of ICC cards at devices with a payment system logo. None. None. Payment systems MasterCard and Visa are aware of the issue. These are not EMVCo-approved ICC devices. For EMVCo informational purposes only. EMVCo Identifier Issue Identifier Status Date Opened Description Findings Corrective Action Preventative Action Additional Comments I0048 Transaction Severity ●=HIGH I0048 Volume Severity ◓=MED Closed – EMVCo, Jan 8, 2004 Oct 01, 2003 It was identified that some cards had been personalized with Track 2 data and extra padding bytes. This caused authorization rejections by some Acquirers. When Track 2 equivalent data on the chip does not end on a full byte boundary, padding is required to bring the data element length to a full byte. Issuers personalized cards with extra padding bytes that caused rejection of the cards by some Acquirers. Acquirer host software was modified to accept the cards. The cards will be corrected. The CTWG published Application Note #18 in Dec, 2003, to clarify that the field shall be padded with a single hex ‘F’, if needed, to ensure whole bytes. None.

v6.13

EMVCo Identifier Issue Identifier Status Date Opened Description Findings Corrective Action Preventative Action Additional Comments EMVCo Identifier Issue Identifier Status Date Opened Description Findings Corrective Action I0047 Transaction Severity ●=HIGH I0047 Volume Severity ◓=MED Closed -- EMVCo, PS Oct 15, 2004 Oct 01, 2003 – Sept 22, 2004 It was reported that the allowable padding of FF and 00 in the FCI data and within a record caused issues with personalization and interoperability. Some cards were personalized with additional padding that caused rejection of the cards at various terminals. The error was identified and the personalization process corrected. Application Note #22 was published in Sept 2004 to clarify the padding of constructed data objects. Here is a section from the application note: Padding, using ‘00’ or ‘FF’ bytes, may occur before, between or after primitive BER-TLV encoded data objects in the value field of constructed data objects (templates) only. This padding is subject to following rules:

• Padding shall not be applied within primitive BER-TLV encoded data objects.
• Padding shall not be applied outside templates.
• Padding may occur within templates, but must be before, after, or between primitive BER-TLV encoded data objects.
• The length indicated in length byte of a padded constructed data object shall include any padding bytes present, since the padding shall only occur within the value field. The padding bytes have no meaning and are discarded. None. I0045 Transaction Severity ●=HIGH I0045 Volume Severity ○=LOW Closed – EMVCo, Feb 6, 2004 Aug 01, 2003 It was reported that some terminals rejected cards where the Language Preference tag had been omitted in the PSE setting (FCI of the PSE) but the tag was present in the application’s ADF. Language preference, if used, needs to be identical in both the FCI of an ADF and the PSE. This was a card personalization issue. During application selection, the terminal checked the fields and rejected the card. The cards were corrected and re-issued. The terminal is also being updated to not check for the discrepancy. v6.13 Preventative Action Additional Comments EMVCo Identifier Issue Identifier Status Date Opened Description Findings Corrective Action Preventative Action Additional Comments EMVCo Identifier Issue Identifier Status Date Opened Description Findings Corrective Action Preventative Action Additional Comments EMVCo Identifier Issue Identifier Status Date Opened Description Findings Corrective Action Preventative Action Additional Comments The CTWG published Specification Update #29 in June 2004, to clarify that terminals should not terminate the transaction when errors are found in the non-critical data elements during application selection. None. I0043 Transaction Severity N/A **** Volume Severity N/A Closed – EMVCo, Mar 13, 2003 Feb 11, 2003 It was reported that ICC cards are rejected at chip capable devices. The device accepts only domestic brand cards. It was determined that although the device does not display an international payment system’s logo, it is a chip capable device. These chip capable devices accept only the domestic brand. None None For EMVCo informational purposes only. These are proprietary devices accepting the domestic ICC card. There is no payment system logo on these chip capable devices. I0041 Transaction Severity ●=HIGH I0041 Volume Severity ◓=MED Closed – EMVCo, Jan 25, 2004 Jul 10, 2002 It was reported that ICC cards are not accepted at chip capable devices that display the payment system (Visa or MasterCard) logos. It was determined that ICC cards are not accepted at various devices, including payphones and unattended petrol devices, where a payment logo is displayed. Proprietary ICC cards or magnetic stripe-only payment system cards are accepted. Payment system’s ICC cards are rejected, and fallback to magnetic stripe does not occur. None. None. The payment systems MasterCard and Visa are aware of the issue. These are not EMVCo-approved ICC devices. Based upon the payment system logo on a terminal, there is currently no way to distinguish between magnetic stripe and chip card acceptance. For EMVCo informational purposes only. I0038 Transaction Severity N/A I0038 Volume Severity N/A Closed –- EMVCo, Jan 21, 2003 Dec 15, 2002 A request for technical clarification of the specifications was submitted concerning the proper use of Issuer script identifiers. The inquiry was responded to. No changes are needed. None. None. This is not an EMV issue. v6.13 EMVCo Identifier Issue Identifier Status Date Opened Description Findings Corrective Action Preventative Action Additional Comments I0036 Transaction Severity ●=HIGH I0036 Volume Severity ○=LOW Closed –- EMVCo, Mar 24, 2003 Dec 15, 2002 It was reported that an interoperability issue could arise when cards configured to require cardholder confirmation during application selection are used at devices that do not support cardholder confirmation. The potential for this interoperability problem is known and is not in conflict with EMV specifications. None. Application Note #9, regarding the application priority indicator and cardholder confirmation, is now published to provide guidance to issuers on the coding of the card for cardholder confirmation. This issue is related to issues I0010 & I0013. EMVCo Identifier Issue Identifier Status Date Opened Description Findings Corrective Action Preventative Action Additional Comments I0031 Transaction Severity N/A **** Volume Severity N/A Closed –- EMVCo, Mar 18, 2003 Oct 11, 2002 This was a technical question regarding the use of a particular field (TA4 in the ATR) and was not an interoperability issue. The inquiry was responded to. TA4 can be present provided that the rest of the ATR is correctly constructed. None. None. This is not an EMV issue. Queries of a technical nature can be submitted at the EMVCo website, under ‘Communication’. EMVCo Identifier Issue Identifier Status Date Opened Description Findings Corrective Action Preventative Action Additional Comments I0030 Transaction Severity ●=HIGH **** Volume Severity ○=LOW Closed – EMVCo, May 21, 2004 Oct 11, 2002 It was reported that a terminal application generated an error while attempting to process responses from a card. Both the card and the terminal used the same optional instruction for different purposes. It was determined that the terminal improperly handled the data received from the card. This error occurred when the terminal acted upon coincidental receipt of an inverse value of the instruction byte of the command. Receipt of this inverse value triggered the terminal to perform an invalid process. The terminal application is being modified to correct the problem. While this is a logic flaw unique to this terminal application, EMVCo test cases are being created to ensure this problem cannot occur again. Type Approval Level 1 test case updates were published in May, 2004. Lab implementations of the test cases will occur in several months. None. v6.13 EMVCo Identifier Issue Identifier Status Date Opened Description Findings Corrective Action Preventative Action Additional Comments I0029 Transaction Severity ●=HIGH **** Volume Severity ◓=MED Closed – EMVCo Mar 14, 2003 Oct 11, 2002 It was reported that a terminal application was rejecting a TLV value with a length of less than 127 bytes when represented by a 2-byte length. The terminal application is not functioning correctly as EMV requires that the aforementioned TLV lengths be supported. The terminal application was modified to correct the problem. Two additional test cases (2CE.001.01 & 2CE.001.02) were added in January 2003, to test for this particular condition. None. EMVCo Identifier Issue Identifier Status Date Opened Description Findings Corrective Action Preventative Action Additional Comments I0027 Transaction Severity N/A **** Volume Severity N/A Closed – EMVCo, Nov 22, 2002 Oct 4, 2002 Interoperability problems were reported with a previously approved EMV device. It was determined that the approved device was subsequently modified to interface with a proprietary application. The reported errors apparently occurred only after that modification. The modified application must be resubmitted for EMVCo approval. None. None. EMVCo Identifier Issue Identifier Status Date Opened Description Findings Corrective Action Preventative Action Additional Comments I0026 Transaction Severity N/A **** Volume Severity N/A Closed -- EMVCo, Mar 31, 2003 Oct 4, 2002 It was reported that a date handling error was encountered during testing of a terminal application. The date handling error was correctly identified during the testing of the terminal application. This problem was not encountered in a production environment. None. There is a test case for this condition. More information on the error was requested. This is not an EMV issue. v6.13 EMVCo Identifier Issue Identifier Status Date Opened Description Findings Corrective Action Preventative Action Additional Comments I0025 Transaction Severity N/A **** Volume Severity N/A Closed – EMVCo, Nov 22, 2002 Oct 4, 2002 It was reported that a card was being rejected by a particular terminal application. It was determined that the failure occurred when processing a proprietary Tag. The processing of proprietary Tags is outside the scope of EMV. None. None. This is not an EMV issue. EMVCo Identifier Issue Identifier Status Date Opened Description Findings Corrective Action Preventative Action Additional Comments I0024 Transaction Severity ●=HIGH **** Volume Severity ○=LOW Closed – EMVCo, Jun 25, 2003 Oct 4, 2002 It was reported that potential interoperability issues could arise in the future at particular ATM devices when offline PIN authentication is supported by both the card and device. This is a network and payment system issue that is not an EMV issue. None. Specification Update #16, ‘If Cash or Cash back CVM Condition Codes’, addresses this issue. This is not an EMV issue. EMVCo Identifier Issue Identifier Status Date Opened Description Findings Corrective Action Preventative Action Additional Comments I0023 Transaction Severity N/A **** Volume Severity N/A Closed – EMVCo, July 1, 2003 Oct 4, 2002 It was reported that multiple application cards were not being accepted by a certain terminal application. Additional information is needed concerning the card, terminal, and application types involved. None. None. The Type Approval Working Group requested additional information on the error. Since no additional information has been received, the issue was closed in July 2003. v6.13 EMVCo Identifier Issue Identifier Status Date Opened Description Findings Corrective Action Preventative Action Additional Comments I0022 Transaction Severity N/A **** Volume Severity N/A Closed – EMVCo, July 1, 2003 Oct 4, 2002 It was reported that a card was rejected due to the presence of an invalid value in the Application Transaction Counter (ATC) field. This was a single, isolated occurrence and additional information is needed to research the issue further. None. None. The Type Approval Working Group requested more details on the error, especially if the card correctly sent the ATC. Since no additional information has been provided, the issue was closed in July 2003. EMVCo Identifier Issue Identifier Status Date Opened Description Findings Corrective Action Preventative Action Additional Comments I0021 Transaction Severity N/A **** Volume Severity N/A Closed – EMVCo, July 1, 2003 Oct 4, 2002 It was reported that sporadic SDA failures were being experienced. It was found that the rejected cards were subsequently processed successfully at other terminals. Additional information is necessary to research the issue further. None. None. The Type Approval Working Group requested more details on the error in order to make an assessment. Since no additional information was received, the issue was closed July 2003. EMVCo Identifier Issue Identifier Status Date Opened Description Findings Corrective Action Preventative Action Additional Comments I0016 Transaction Severity ●=HIGH **** Volume Severity ○=LOW Closed – EMVCo, Mar 31, 2003 Oct 10, 2002 It was reported that a PIN Pad model was rejecting some cards. It was determined that the problem resulted from improper circuitry in the PIN Pad. The PIN Pad was rejecting cards as the result of testing for I/O at an EMV-defined indeterminate time. Vendor has corrected the problem and the device received EMVCo approval. None. None. v6.13 EMVCo Identifier Issue Identifier Status Date Opened Description Findings Corrective Action Preventative Action Additional Comments I0015 Transaction Severity ●=HIGH **** Volume Severity ●=HIGH Closed – EMVCo, Mar 3, 2003 Oct 4, 2002 It was reported that some cards were being rejected at particular ATM devices. It was determined that ATM devices were encountering an error selecting and processing an application on the card that was not EMV compliant. The proprietary application being selected relied upon use of a proprietary terminal application that is outside the scope of EMV. The vendor has identified a solution and is developing the correction. Performing ISO 7816-4 SELECT per AID (equivalent to the EMV SELECT) of the application first would avoid this problem. The Card Terminal Working Group has published a draft bulletin addressing non-EMV cards and the application selection methodology after the answer to reset. This is not an EMV issue. EMVCo Identifier Issue Identifier Status Date Opened Description Findings Corrective Action Preventative Action Additional Comments I0013 Transaction Severity ●=HIGH **** Volume Severity ○=LOW Closed – EMVCo, Oct 10, 2002 Jan 14, 2002 It was reported that a terminal application rejected cards requiring cardholder confirmation. It was determined that the cards being rejected were configured to require cardholder confirmation for application selection, however, the terminal application did not support cardholder confirmation. According to EMV, this is the correct terminal behavior. The Acquirer will modify the terminal parameters to correct the incompatibility. Application Note #9 was published March 2003, to provide guidance to issuers on the coding of the card for cardholder confirmation. This is the same issue as I0010 and I0036. EMVCo Identifier Issue Identifier Status Date Opened Description Findings Corrective Action I0012 Transaction Severity ●=HIGH **** Volume Severity ◓=MED Closed – EMVCo, Oct 10, 2002 Jan 14, 2002 It was reported that some cards were "locking-up" particular terminal applications. It was determined that terminal applications were rejecting cards with a Language Preference containing uppercase letters. This data field should have been encoded with lower case letters. This is a personalization issue with the card. v6.13 Preventative Action Additional Comments EMVCo Application Note #12 was published July 2003, to clarify the coding of upper and lower case. ISO 639 indicates the usage of lower case, so cards shall use lower case for language preference. However, it is highly recommended that terminals not be case-sensitive and recognize the language preference regardless of its case. None EMVCo Identifier Issue Identifier Status Date Opened Description Findings Corrective Action Preventative Action Additional Comments I0011 Transaction Severity ●=HIGH **** Volume Severity ○=LOW Closed – EMVCo, Nov 22, 2002 Jan 14, 2002 It was reported that some cards were causing a terminal application to generate an "Invalid Data" response. It was determined that the terminal application was improperly rejecting cards when either an Application Label or Application Preferred Name field contained a ‘space’ character. The EMV specifications state that these fields may only contain alphanumeric characters and was interpreted by the terminal vendor to mean the exclusion of special characters such as ‘space’. The terminal application was modified to additionally accept special (printable) characters. EMVCo Specifications Update Bulletin #14 is now published on the website. None. EMVCo Identifier Issue Identifier Status Date Opened Description Findings Corrective Action Preventative Action Additional Comments I0010 Transaction Severity N/A **** Volume Severity N/A Closed – EMVCo, Nov 22, 2003 Aug 27, 2002 It was reported that a terminal application was incorrectly rejecting cards requiring cardholder confirmation. It was determined that the cards being rejected were configured to require cardholder confirmation for application selection; however, the terminal application did not support cardholder confirmation. According to EMV, this is the correct terminal behavior. The Acquirer will modify the terminal parameters to correct the incompatibility. Application Note #9 was published March, 2003, to provide guidance to issuers on the coding of the card for cardholder confirmation. None. v6.13 EMVCo Identifier Issue Identifier Status Date Opened Description Findings Corrective Action Preventative Action Additional Comments I0007 Transaction Severity ●=HIGH **** Volume Severity ◓=MED Closed – EMVCo, Jun 20, 2003 Aug 27, 2002 & Oct 4, 2002 It was reported that T=1 cards configured with TA2 in the Answer to Reset (ATR) are being rejected by a terminal application. The EMV3.1.1 and EMV4.0 specifications (Book 1, section 4.3.3.5) and test cases 1CE.005.xy and 1CE.006.xy have been reviewed. The specifications and the test cases are correct. An ATR with a TA2 is accepted provided that b5=0 and other conditions are satisfied. None None Please check to see if this is an approved EMVCo device. EMVCo Identifier Issue Identifier Status Date Opened Description Findings Corrective Action Preventative Action Additional Comments I0006 Transaction Severity ●=HIGH **** Volume Severity ○=LOW Closed – EMVCo, Sep 9, 2003 Aug 27, 2002 and Oct 10, 2002 It was reported that a terminal application was rejecting T=1 cards configured with TC1=FF in the Answer to Reset. A card with the error was received from the Issuer. The TAWG reviewed the issue. Current tests do not test for the maximum INF field. A modified test using an I-Blocks with a maximum INF field size (254 bytes) shall be implemented by the TAWG in the accredited laboratories. This test case implementation will be used in Type Approval at each EMVCo accredited laboratory. The test case has been modified. The TAWG has additionally reviewed the approved labs’ test case implementations. None. EMVCo Identifier Issue Identifier Status Date Opened Description Findings Corrective Action Preventative Action Additional Comments I0005 Transaction Severity ◓=MED ***** Volume Severity ◓=MED Closed – EMVCo, May 21, 2004 Oct 10, 2002 It was reported that a terminal application was improperly interpreting the first 2-bits of the CVM Results as ‘00’. This condition was confirmed and is in violation of EMV. Test case 2CM.028 will be enhanced to test for this specific occurrence. Further clarification was added in the Level 2 test plan improvements, published May 2004. Lab implementations of the test cases will occur in the next few months. None. v6.13 EMVCo Identifier Issue Identifier Status Date Opened Description Findings Corrective Action Preventative Action Additional Comments I0004 Transaction Severity ●=HIGH **** Volume Severity ○=LOW Closed – EMVCo, Mar 31, 2003 Aug 27, 2002 & Oct 4, 2002 It was reported that a terminal application incorrectly accepted a response to a GENERATE AC command that contained an invalid length and continued processing the transaction request. Two test cases exist, 2CL.034 and 2CA.011, to test for the Generate AC and the DDOL. This issue is an earlier (older) problem that is today corrected in the various implementations of the EMVCo test cases. None. None. Please check to see that the terminal is an approved device. EMVCo Identifier Issue Identifier Status Date Opened Description Findings Corrective Action Preventative Action Additional Comments I0002 Transaction Severity ●=HIGH **** Volume Severity ○=LOW Closed – EMVCo, Mar 31, 2003 Oct 4, 2002 It was reported that a terminal application rejected the ICC card when the FCI template of the card was padded with zeros. EMV specifies that the terminal application should ignore the padding of zeros in the FCI template. EMV test 2CL.052.00 tests for zero padding. The terminal application was modified to correct the error. Type Approval test case updates were published in May, 2004. Lab implementations of the test cases will occur in the next few months. None. EMVCo Identifier Issue Identifier Status Date Opened Description Findings Corrective Action Preventative Action Additional Comments I0001 Transaction Severity ◓=MED **** Volume Severity N/A Closed – EMVCo, Jan 22, 2003 Aug 27, 2002 It was reported that a terminal application was incorrectly recording an error in the Terminal Verification Results (TVR) field when a DDA failure occurred as the result of a missing ICC Public Key Remainder in the consumer card. When this error occurred, the terminal application was setting only the TVR bit corresponding to ‘ICC Data Missing’ and no other bits – such as ‘Offline dynamic data authentication failed’. EMV specifies that the terminal application need only set the TVR bit corresponding to ‘ICC Data Missing’ as is presently occurring. Attempting to perform DDA would not be possible with the absence of the ICC Public Key Remainder. None. None. None. v6.13 3.12 Closed -- EMVCo, Payment System Activities Complete EMVCo Identifier Date Original Assessment Current Assessment Current Status Description Findings Terminal Information Corrective Action Preventative Action Additional Comments EMVCo Identifier Date Original Assessment Current Assessment Current Status Description I0091 Tag5F20 Chinese character encoding issue Opened - Jun 4, 2014 Closed - Aug 22, 2017 Transaction Severity ●=HIGH Volume Severity ◓=MED Transaction Severity ●=HIGH Volume Severity ○=LOW Pending Implementation – Field Implementation EMVCo, Payment System ○=GOOD Some cards in the field contain Chinese characters in Tag5F20 which cannot be accepted on some terminals (currently only ATM, still checking POS) in Europe. The terminal is expecting ASCII in this tag but Issuer use GBK character set (a Chinese national standard for encoding Chinese characters). Other tags could have similar issue are tag50, tag9F0B, tag9F1F, tag9F12, tag5F50. Transactions on such cards will be rejected by some terminals which check the format of these tags. The incident has been reported in France and UK Wincor ATMs Wincor has new kernels based on 4.3b available to update impacted ATMs. ATMs have been updated and no further incidents reported. Issued Spec Bulletin No159 in Feb 2015 which updates Spec Bulletin No83 issued in Dec 2010. The terminals now must ignore the formatting error and continue processing for Tags 5F20, 9F0B, 5F50, 9F4D, and 9F4F. Added relevant test cases to 4.3d in May 2015 (TA Bulletin No160) CLOSED. No new field issues reported in the last 12 months with all necessary preventative actions taken. I0090 Terminal unable to process cards with longer length AFLs and causes online crypto to fail Opened - Feb 20, 2012 Closed – Aug 7, 2013 Transaction Severity ◓=HIGH Volume Severity ○=LOW Transaction Severity ◓=HIGH Volume Severity ○=LOW Resolution in Process – Field Implementation EMVCo, Payment System ○=GOOD It was reported that certain transactions are being declined due to online crypto validation error in the authorization message. The issue has been identified in transactions initiated by some terminals in Taiwan. v6.13 Findings Terminal Information Corrective Action Preventative Action Additional Comments EMVCo Identifier Date Original Assessment Current Assessment Current Status Description Findings Terminal Information Corrective Action Preventative Action The cause of the issue is likely to be that the terminal is unable to correctly process cards that have longer length Application File Locator (AFL). Although the terminal to card portion of the transaction appears to complete without problems, the Application Interchange Profile (AIP) that is sent in the online authorization is overlaid with two bytes from the end of the AFL. This incorrect AIP causes the online cryptogram (ARQC) to fail validation and the transaction to be declined. VeriFone 3750 and 5150 terminals Fixed kernels being downloaded or being swapped out with new terminals. Test Plan 4.2a –introduced after this kernel approval- added a test for longer AFLs (150 bytes). This tested length seems sufficient. As a consequence EMVCo does not foresee additional test unless the on-going investigation leads to a different understanding of the issue. CLOSED. The impacted terminals have either aged out of the market or have received updated applications/kernels that do not exhibit the issue. No issues reported for over 12 months I0089 Issue with padding bytes at end of PSE read response Opened - May 23, 2011 Closed – Mar 17, 2016 Transaction Severity ●=HIGH Volume Severity ◓=MED Transaction Severity ●=HIGH Volume Severity ◓=MED Resolution in Process – Field Implementation EMVCo, Payment System ○=GOOD In a range of VeriFone terminals, the transaction hangs during application selection for certain German issued cards with padding bytes at the end of a PSE read record response after the constructed data object 0x61. No transaction available (chip or mag stripe) when issue occurs. The impacted kernels get into an endless loop when reading the PSE Read record response because they does not skip the '0' padding bytes in the PSE read response. Issue initially reported in Netherlands, Luxembourg, Poland and Australia. Other countries identified after the assessment especially in Asia and Canada. Several VeriFone kernels including Vx EMV Module 5.0.5, Vx EMV Module 5.1.5, SC5000 EMV Module 4.5.0. Corrected versions have been made available for all impacted kernels. EMVCo lists "Level 2 Contact Approved Application Kernels" and "Level 2 Contact Approved Application Kernels Restricted Renewal" have been updated removing impacted kernels and appended references of corrected versions. Upgrade globally completed in all countries with maybe some restriction for Canada. Additional test cases added to terminal testing process (4.3.a). v6.13 Additional Comments EMVCo Identifier Date Original Assessment Current Assessment Current Status Description Findings Terminal Information Corrective Action Preventative Action Additional Comments CLOSED - No new field issues reported in the last 12 months with all necessary preventative actions taken. I0088 Contactless reader issues during mobile transactions Opened - Apr 13, 2011 Closed – Sep 13, 2016 Transaction Severity ●=HIGH Volume Severity ○=LOW Transaction Severity ●=HIGH Volume Severity ○=LOW Resolution in Process – Field Implementation EMVCo, Payment System ○=GOOD The contactless reader exhibits non-standard behavior when it is conducting a payment transaction with a GSM mobile phone if the mobile receives a call. This non-standard behavior involves the initiation of a power-up reset. The reader remains in reset until the phone stops transmitting. Recovery can require re- booting of the reader. In some case, the incident causes a permanent reversal of the reader's display screen (i.e. a mirror image displays). The cardholder device is a mobile device using GSM850 and GSM 900 frequency band. The incident has been reported in the UK VivoPay 5000 A hardware fix has been developed that solves the problem. EMD Task Force defined the methodology to investigate for future EMD issues. No issues in the field. Investigation methodology defined. Re- assess further necessity of preventative measures based on future related issues should they arise. EMVCo Identifier Date Original Assessment Current Assessment Current Status Description Findings Terminal Information Corrective Action Preventative Action I0087 Terminal error due to use of private tags Opened - Dec 21, 2010 Closed – Mar 17, 2016 Transaction Severity ◓=MED Volume Severity ○=LOW Transaction Severity ◓=MED Volume Severity ○=LOW Pending Implementation – Field Implementation EMVCo, Payment System ◓=SLOW *Under Maintenance Mode In certain VeriFone kernels, during Application selection, when the kernel tries to update the Tag DF10 (private tag) read from the card's response to the collection, it returns an error. Tag DF10 is used by the kernel internally for other usage. Some UK issued cards were affected as the terminal terminates the transaction due to the duplicate usage of tag DF10. VeriFone Vx EMV Module 5.0.0 affected. VeriFone has developed a patch fix which has passed relevant testing, and is now on the EMVCo website. Additional test cases added to terminal testing process 2CJ.012.04 in 4.3 v6.13 Additional Comments 3 EMVCo Identifier Date Original Assessment Current Assessment Current Status Description Findings Terminal Information Corrective Action Preventative Action Additional Comments EMVCo Identifier Date Original Assessment Current Assessment Current Status Description Findings Terminal Information Corrective Action CLOSED - No new field issues reported in the last 12 months with all necessary preventative actions taken. I0086 Terminal not following signal sequence during warm reset Opened - Apr 23, 2010 Closed – March 28, 2016 Transaction Severity ◓=MED Volume Severity ○=LOW Transaction Severity ◓=MED Volume Severity ○=LOW Resolution in Process – Field Implementation EMVCo, Payment System ○=GOOD It was reported that certain terminals deactivate the Clock signal by setting CLK at state L during the warm reset sequence. Such a sequence is identified by silicon manufacturer(s) as a potential threat requiring the implementation of a counter measure. In some cases this may lead to disabling the card. The transaction is not possible and the card may be damaged or disabled by internal security mechanism. The terminal's behavior seems not compliant to EMV v.4.1 and v.4.2 Book 1 section "6.1.3.2 Warm Reset" Details still under investigation. Not relevant. This defect was introduced by third parties’ development specific to few markets and not by the terminals vendor (as per EMVCo definition) A fix on the application layer made available. New test added through the introduction of a new test tool hardware. (EMVCo Contact Terminal L1 Test Case 1CC.004.0x with Comprion IT3). CLOSED. Corrective and preventative actions completed. No new incidents reported in over 12 months. I0085 Terminal freeze due to Certificate serial number issue Opened - Feb 25, 2010 Closed – Jan 18, 2011 Transaction Severity ◓=MED Volume Severity ○=LOW Transaction Severity ◓=MED Volume Severity ○=LOW Pending Implementation – Field Implementation EMVCo, Payment System ◓=SLOW *Under Maintenance Mode It was reported that certain VeriFone terminals are unable to process certain cards with long key length and supporting Offline Enciphered PIN and when the cards are used in a certain sequence. This issue happens when the first bytes of Issuer Certificate serial numbers of two consecutive cards differ by a small number. If two such cards are used then the first transaction succeeds but the next one freezes the terminal. All that matters is the difference between Issuer Certificate serial numbers of the two cards. The issue has only been reported in the UK. VeriFone Vx 3.0.5 terminals The vendor has developed a fix for this issue to be used in the interim prior to ultimately updating to a new EMVCo approved v6.13 Preventative Action Additional Comments EMVCo Identifier Date Original Assessment Current Assessment Current Status Description Findings Card/Terminal Information Corrective Action Preventative Action Additional Comments EMVCo Identifier Date kernel. It was confirmed that the fix successfully solved the issue with no critical errors in regression testing This kernel did not go through Renewal Testing as per EMVCo process, therefore it remains not formally EMVCo approved. Still the patch provides an effective solution to a critical existing issue, thus the deployment of this corrected version should be considered by the acquirers. Prior to field deployment, Acquirers are required to consult with the relevant Payment Systems. This is an incident that can happen in very specific scenarios and no specific test cases could be defined. CLOSED due to no issues being reported over 10 months with limited (low) terminals/cards affected. I0084 ESD issue with Dual Interface Cards Opened – Mar 16, 2010 Transaction Severity ●=HIGH Transaction Severity ●=HIGH Resolution in Process – EMVCo, Payment System Closed – Mar 17, 2016 Volume Severity ●=HIGH Volume Severity ◓=MED Field Implementation ◓=SLOW *Under Maintenance Mode It was reported that certain contact chip PIN pads in Canada sometimes experience ESD issues when reading dual interface cards via the contact chip interface. In most cases the terminal automatically recovers. In some cases if the device is integrated with a merchant till, the till needs to be reset. With repeated discharges, the device may not recover or become nonfunctional. It was confirmed that dual interface cards are not the only card types impacted. VeriFone Vx810 terminals in Canada were found to be particularly susceptible to ESD, but field modification has already been made available. This problem occurs in cold, dry environments. Canadian acquirers decided to replace affected terminals with different model of terminals. VeriFone has provided field modification solutions with most problematic ones replaced and others replaced in maintenance cycle. A dedicated task force within EMVCo was created to address this issue. Terminal ESD Evaluation Process released in Sep 2014. CLOSED - No new field issues reported in the last 12 months with all necessary preventative actions taken. I0083 "PIN entry required and PIN pad not present or not working" bit set while Offline PIN is not supported by the terminal Opened - Jan 20, 2010 Closed – Jul 27, 2011 v6.13 Original Assessment Current Assessment Current Status Description Findings Card/Terminal Information Corrective Action Preventative Action Additional Comments EMVCo Identifier Date Original Assessment Current Assessment Current Status Description Findings Terminal Information Corrective Action Transaction Severity ◓=MED Transaction Severity ◓=MED Pending Implementation – EMVCo, Payment System Volume Severity ◓=MED Volume Severity ○=LOW Field Implementation ◓=SLOW *Under Maintenance Mode It was reported that a significant number of cards were declined offline when used in certain terminals in Hong Kong. Apparently, the terminals try to conduct the PIN-related CVM processing even when the terminal doesn’t support any PIN-related CVMs and the CVM condition code of the cards indicates "if supported" result in set the "PIN entry required and PIN pad not present or not working" bit of the TVR to 1 regardless of the value of the CVM condition code. The issue was also reported in China, Macau, Singapore, and Vietnam. PAX P60 and P70 terminals In progress through terminal replacement. Hong Kong, China, and Macau – 80% complete Singapore and Vietnam – Unknown, but no actual issues reported The new test case has been introduced in the 4.2.b test case, effective from end of January 2010. CLOSED - No new field issues reported in the last 12 months with all necessary preventative actions taken. I0082 Transaction declined when Issuer Authentication fails Opened - Dec 21, 2009 Closed – Mar 17, 2016 Transaction Severity ◓=MED Volume Severity ○=LOW Transaction Severity ◓=MED Volume Severity ○=LOW Pending Implementation – Field Implementation EMVCo, Payment System ◓=SLOW It was reported that some IBM ATMs in Canada decline issuerapproved transactions when issuer authentication fails even though the card returns an approval (TC) in the second GEN AC response. This behavior violates the EMV specification and causes a decline for transactions that should be approved. Issuer has personalized cards to not decline when Issuer Authentication fails and the issuer has approved the transaction online, but the ATM in Canada is declining regardless. ATM declines issuer-approved transactions when Issuer Authentication fails even though card approves transactions. Error occurs when EXTERNAL AUTHENTICATE command is used for Issuer Authentication. The ATM hardware is supplied by IBM, and the ATM software is written by Wincor Nixdorf. The client is running Wincor Nixdorf software on ATMs managed by IBM. The fix has been completed and tested by Wincor v6.13 Preventative Action Additional Comments Nixdorf. The fix will be implemented as part of the OS migration to Windows 7. The new test case has been introduced in the 4.2.b test case, effective from end of January 2010. CLOSED - No new field issues reported in the last 12 months with all necessary preventative actions taken. v6.13 EMVCo Identifier Date Original Assessment Current Assessment Current Status Description Findings Terminal Information Corrective Action Preventative Action Additional Comments EMVCo Identifier Date Original Assessment Current Assessment Current Status Description Findings I0081 Clock Instability in terminal causes cards to shutdown Opened - Dec 21, 2009 Closed - Mar 28, 2016 Transaction Severity ○=LOW Volume Severity ◓=MED Transaction Severity ○=LOW Volume Severity ○=LOW Pending Implementation – Field Implementation EMVCo, Payment System ○=GOOD It was reported that Ingenico I6400 terminals have a problem with its clock signal, which is perceived by some newer cards as a ‘power glitch’ attack so the card shuts down. Older cards are less sensitive and do not have this issue. After shut down, transaction is completed using magnetic stripe. Issue seems to be limited to approximately 5,800 Ingenico I6400MHQ001B approved terminals produced before July 2005. Some but not all of these devices have a problem with several card products. It was confirmed that this issue was identified in Norway. Ingenico I6400 Replacement of the terminals completed. New contact L1 test tool has been introduced which added glitch testing. CLOSED. No new incidents have been reported in over 12 months. I0080 Interference GSM/CDMA Dual Interface card Opened - Jan 20, 2010 Closed – Jul 27, 2011 Transaction Severity ●=HIGH Volume Severity ○=LOW Transaction Severity ●=HIGH Volume Severity ○=LOW Resolution in Process – Field Implementation EMVCo, Payment System ◓=SLOW *Under Maintenance Mode It was reported that there was an interference issue between several GPRS/GSM terminals and some chips used on Dual Interface cards. The technical issue is thought to be due to the emission of EMC by the terminal during the contact payment transaction which is interrupted at the card level (chip reset) during the online authorization communication and can not be completed even though the issuer returns the approval response. The issue is not systematic and will depend on factors influencing the transmission quality like the distance from the mobile operator transmitter. Very few incidents have been reported so far from the field and the current impact is maybe limited but there is a risk as deployment of terminals using wireless technology seems at its beginning. v6.13 Card/Terminal Information Corrective Action Preventative Action Additional Comments EMVCo Identifier Date Original Assessment Current Assessment Current Status Description Findings Terminal Information Corrective Action Preventative Action Additional Comments EMVCo Identifier Date Original Assessment Current Assessment Current Status Description N/A Both the smartcard silicon manufacturer and the terminal vendor reported to have experienced field issues have enhanced their device designs to reduce the risk of such interference. Best Practices for Issuance and Acceptance of Dual Interface Cards published on the EMVCo website. A dedicated task force within EMVCo was created to address this issue. The current plan is to define risk inventory of radiation, conduct assessment and to define measurement methodology based on the above assessment. CLOSED - No new field issues reported in the last 12 months. Preventative measures for Electro Magnetic Disturbance/ Compatibility being addressed by dedicated task force. I0079 Transaction terminated when CDA cards used and CDA failed Opened - Jan 26, 2009 Closed Nov 24, 2009 Transaction Severity ◓=MED Volume Severity ◓=MED Transaction Severity ◓=MED Volume Severity ◓=LOW Pending Implementation – Field Implementation EMVCo, Payment System ○=GOOD Certain terminals have a problem to process CDA failure transactions. The terminals don’t allow transactions to go online for approval for cards that fail CDA. In case the terminal fails in recovering the RSA keys needed during the CDA process, the transaction is terminated even if the card responds with ARQC (go online) or TC (approve offline) in response to generate AC command. There is no issue if the card responds GENAC in format 1. Verifone Vx/Verix and SC 5000 4.0.0 modules Verifone has developed a Hot Fix for this issue and the recertification test was completed. The terminal upgrade has started. It was confirmed that the most current test case checks that the terminal can correctly process a CDA failure transaction. I0078 Card contact interface shuts down when contactless field is detected Opened - Jan 26, 2009 Closed – Jul 27, 2011 Transaction Severity ◓=MED Volume Severity ○=LOW Transaction Severity ◓=MED Volume Severity ○=LOW Resolution in Process – Field Implementation EMVCo, Payment System N/A Some dual-interface cards shut down the contact interface when the card detects a contactless field. The presence of a stable RF v6.13 Findings Card/Terminal Information Corrective Action Preventative Action Additional Comments EMVCo Identifier Date Original Assessment Current Assessment Current Status Description Findings field is sufficient to cause this problem, as it is the energy of the field that powers the card’s contactless interface and causes the issue. With some placements of the contact and contactless readers, a contact read of the card is not possible since the contactless interface is always detected while the card is being inserted into the contact reader. Note that the distance of the card from the contactless reader may be such that contactless communications are not sufficiently stable to conduct a transaction, but within range for the RF field to activate the cards contactless interface. The card may also activate the contactless interface and disable the contact interface if there is an RF field originating from an unknown source, external to the payment acceptance environment. Issuers are impacted if the placement of the readers prevents a contact read and card settings require a contact read to update card-based data elements. Issuers issuing contact-only product on dual-interface cards with this issue may also be impacted. Merchants with contact and contactless acceptance may not be able to accept contact chip transactions if the card has this issue. This was discovered through testing at labs, field issues have not been identified. N/A (no actual field issues) Best Practices for Issuance and Acceptance of Dual Interface Cards published on the EMVCo website. A dedicated task force within EMVCo was created to address this issue. The current plan is to define risk inventory of radiation, conduct assessment and to define measurement methodology based on the above assessment. CLOSED - No actual field issues reported and preventative measures for Electro Magnetic Disturbance/Compatibility being addressed by dedicated task force. I0077 ICC Public Key >= 1024 bit in Format 1 and Format 2 Opened - Nov 11, 2008 Closed - July 20, 2010 Transaction Severity ◓=MED Volume Severity ●=HIGH Transaction Severity ◓=MED Volume Severity ○=LOW Pending Implementation – Field Implementation EMVCo, Payment System ○=GOOD Certain terminals in the field are wrongly failing DDA when the DDA card’s ICC Public Key is greater than or equal to 1024 bits. There is a problem with certain DDA-supported terminals when a card’s ICC Public Key is greater than or equal to 1024 bits. When the card responds to the INTERNAL AUTHENTICATE command using Format 1 and Format 2 templates, DDA supported terminals fail DDA. This issue occurs because the length field of the v6.13 Terminal Information Corrective Action Preventative Action Additional Comments EMVCo Identifier Date Original Assessment Current Assessment Current Status Description Findings Terminal Information Corrective Action Preventative Action Additional Comments EMVCo Identifier Date Original Assessment Current Assessment Current Status Description INTERNAL AUTHENTICATE response is two bytes long when the key is 1024 bits or more. Ingenico TT41 Ingenico has developed a Hot Fix for this issue and the recertification test was completed. 90% of the terminals will be upgraded, the remaining 10% of the terminals will be replaced. At the end of April 2010, download to the terminals in the field countries is progressing with 95% complete. Replacement of the terminals is progressing with 25% completete. It was confirmed that the most current test case checks that the terminal can process cards having ICC Public Key of 128 bytes and more. Majority of terminals are fixed, with the rest in maintenance mode replacement – this issue is closed. I0076 DDA fails with certain formats of ICC Dynamic Data Opened - Nov 14, 2008 Closed - July 20, 2010 Transaction Severity ◓=MED Volume Severity ◓=MED Transaction Severity ◓=MED Volume Severity ○=LOW Pending Implementation – Field Implementation EMVCo, Payment System ◓=SLOW It was reported that Hypercom terminals are unable to process certain formats of ICC Dynamic Data. ICC Dynamic Data consists of an ICC Dynamic Data length byte, an ICC Dynamic Number length byte, a 2-8 byte ICC Dynamic Number, and optionally additional dynamic data. Most cards do not use the additional dynamic data, but certain Swiss cards use ICC Dynamic Data with this optional data. All Hypercom terminals fail DDA when they encounter this additional data. Hypercom 11,000 terminals in Switzerland are known to be impacted. 9,000 have been upgraded with rest to be updated by February 2009. Preventative test cases has been introduced by updating test plan ver. 4.2.a. The issue in Switzerland has been corrected, no further issues reported in over 12months – closed. I0075 Application Preferred Name with extended character Opened - Sep 9, 2008 Closed – Sep 18, 2012 Transaction Severity ●=HIGH Volume Severity ◓=MED Transaction Severity ●=HIGH Volume Severity ○=LOW Resolution in Process – Field Implementation EMVCo, Payment System N/A It was reported that certain Ingenico terminals have a problem to accept Turkish cards having an ï in the application preferred v6.13 Findings Terminal Information Corrective Action Preventative Action Additional Comments EMVCo Identifier Date Original Assessment Current Assessment Current Status Description Findings Terminal Information Corrective Action Preventative Action Additional Comments EMVCo Identifier Date Original Assessment Current Assessment Current Status Description name. This issue only happens in old Unicapt 16 Ingenico terminals in France. This issue only happens in old Unicapt 16 Ingenico terminals in France. Ingenico Unicapt 16 Ingenico has developed a Hot Fix for this issue and awaiting recertification. It was confirmed that the most current test case checks that the terminal can process cards having extended characters in the application preferred name. Closed: Most Unicapt 16 terminals have been replaced in France, and there have not been any new reports of this incident in over 2 years. I0074 Offline PIN Encryption Max Key Length Opened - Sep 9, 2008 Transaction Severity ●=HIGH Transaction Severity ●=HIGH Resolution in Process – EMVCo, Payment System Closed – Sep 18, 2012 Volume Severity ◓=MED Volume Severity ○=LOW Field Implementation N/A It was reported that certain Ingenico terminals have a problem to accept cards having ICC PIN Encipherment key of 128 bytes and more even if not used (CVM List without encrypted PIN). This issue only happens in old Unicapt 16 Ingenico terminals in France. Ingenico Unicapt 16 Ingenico has developed a Hot Fix for this and awaiting recertification. It was confirmed that the most current test case checks that the terminal can process cards having ICC PIN Encipherment key of 128 bytes and more. Closed: Most Unicapt 16 terminals have been replaced in France, and there have not been any new reports of this incident in over 2 years. I0073 Error with certain proprietary data Opened - Aug 18, 2008 Transaction Severity ●=HIGH Transaction Severity ●=HIGH Pending Implementation – EMVCo, Payment System Closed - Jan 20, 2010 Volume Severity ◓=MED Volume Severity ◓=MED Field Implementation ○=GOOD It was reported that certain Verifone terminals are unable to read SFIs 21-30 where issuer proprietary data is personalized and instead terminate the transaction when the read is attempted. It is still under investigation the same problem occurs when reading from SFIs 11-20 where payment system proprietary data is personalized. v6.13 Findings Terminal Information Corrective Action Preventative Action Additional Comments EMVCo Identifier Date Original Assessment Current Assessment Current Status Description Findings Terminal Information Corrective Action Preventative Action Additional Comments EMVCo Identifier Date Original Assessment Current Assessment Cards that are personalized with an AFL requiring this data to be read are not accepted at the impacted terminals. There are about 205,000 impacted terminals in Brazil. Some Austrian ATMs also had this problem, but that problem has been corrected. Verifone Omni 3750 Verix 510 Verifone has a corrected kernel available. 95,000 terminals have already been replaced, and the rest have also been replaced at the end of 2009 It was confirmed that new test cases have been added to Test Plan 4.2.a which has been effective since end of Feb 2009. Problematic kernels have already been removed from the EMVCo Approval List and replaced with the fixed kernels where appropriate. I0069 Lock-up with certain PDOL data Opened - Sep 18, 2006 Closed – June 24, ‘08 Transaction Severity ●=HIGH Volume Severity ◓=MED Transaction Severity ○=LOW Volume Severity ○=LOW Assessment in Process – Field Implementation EMVCo, Payment System ○=GOOD When the card’s PDOL contains the tag for "Amount, Other" (tag 9F03) and in less frequent cases, the tag for "Amount, Authorized" (tag 9F02), the terminal displays ‘Invalid card’ and does not continue with the transaction. The transaction is unable to complete because the terminal locks up after application selection when these tags are encountered in the card’s PDOL. The problem does not occur at all devices with the impacted kernel but only in implementations with certain non-kernel software. The problem appears to be related to the interaction between the kernel and non-kernel software. Field research conducted so far have identified old terminals in UK and Taiwan as potentially affected markets. Ingenico and Gemalto terminals A workaround fix has been developed by the vendors and implemented onto the affected terminals. There have been no new reports on this issue. In light of the above, this issue is considered closed. New test cases were introduced in the latest test plan (v.4.1.d) effective end of October 2007. This problem has not been reported for any ‘live’ transactions. No current cards (to our knowledge) include these tags in their PDOLs, but it should be noticed that CPA cards with low-value profiles may us