Disposition of Comments: EMV® Contactless Specifications for Payment Systems Book C-8 Kernel 8 Specification Version DRAFT2

Draft Specification & Bulletin Industry Feedback Form Working Group: Contactless Kernel Task Force Document: EMV® Contactless Specifications for Payment Systems Book C-8 Kernel 8 Specification Version DRAFT2, April 2022 Company Name: Consolidated Comments Primary Contact Name: EMVCo Contactless Kernel Task Force Date: October 2022 Consolidated Responses – C-8 Kernel Specification DRAFT2 Comment Source1 EA/Sub Clause No./ Subclause No. / Annex Paragraph/ Figure/ Table/ Note Type of comment2 Comment (justification for change) Draft Specification & Bulletin Industry Feedback Form Proposed change Status Accept, Reject, In progress, Acknowledge EMVCo Use Only EMVCo observations on each comment submitted Sub 3.3 and - 3.5 ge The encryption of the data If not already done, check if there is no Acknow- Thank you for the comment. exchanged during the execution of patent infringement ledged the read records commands and the read and write of the Data Storage functionality might infringe potential existing patent. 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. © 2022 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. October 2022 Page 2 of 16 Consolidated Responses – C-8 Kernel Specification DRAFT2 Comment Source1 EA/Sub Clause No./ Subclause No. / Annex Paragraph/ Figure/ Table/ Note Type of comment2 Comment (justification for change) Draft Specification & Bulletin Industry Feedback Form Proposed change Status Accept, Reject, In progress, Acknowledge EMVCo Use Only EMVCo observations on each comment submitted EA All N.A. specificat ion ge The secure channel defined in the To prevent such an attack, it would be Reject Mutual authentication creates specification protects against a interesting to consider an additional an overhead on terminal passive attacker (e.g., feature, possibly optional, which would management and transaction eavesdropping of the allow to carry out a mutual performance, and the communication link between Card authentication in the case where the independent feasibility study and Terminal is no longer Terminal and the Card recognize the and report, commissioned by possible). The one-sided same trusted authority. EMVCo, did not identify it as a authentication from the Card to business requirement. the Terminal avoids man-in-the- middle attacks. Unfortunately, the fact that it is not a mutual authentication still allows any Terminal (including malicious ones) to mount a secure channel with a Card in order to access its private data. 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. © 2022 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. October 2022 Page 3 of 16 Consolidated Responses – C-8 Kernel Specification DRAFT2 Comment Source1 EA/Sub Clause No./ Subclause No. / Annex Paragraph/ Figure/ Table/ Note Type of comment2 Comment (justification for change) Draft Specification & Bulletin Industry Feedback Form Proposed change Sub 6.3.8 S23-B te p.119 Looks like the flow S23-B on p. 119 give priority over READ DATA compared to READ RECORD in case the DE/DS option is implemented, setting "Next CMD" to READ DATA after a previous READ DATA. Is this the intention? Will this have any negative effect on the overall transaction time? (blank) Sub 6.3.9 S22 p. 124 te Do you see any risk that the Kernel gets stuck (i.e. remain in state S22) in the process of READ DATA in case of exception cases? Similarly, Do you see any risk that data doesn't get sent to the terminal because of a data element not being read. (blank) Status Accept, Reject, In progress, Acknowledge EMVCo Use Only EMVCo observations on each comment submitted Reject If DE/DS is implemented, the READ DATA command is sent first till all the data envelopes to be read are read, so they can be processed by the terminal as soon as possible and the Kernel does not have to wait for the response of the terminal if any.  Reject There is no negative effect on transaction time. No there is no risk because all states have an exit in case of exception. Processes C and K will respond. Card L1 has a timeout if card doesn't respond. And if the Terminal First Write Flag is not sent – this too has a specific timeout. 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. © 2022 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. October 2022 Page 4 of 16 Consolidated Responses – C-8 Kernel Specification DRAFT2 Comment Source1 EA/Sub Clause No./ Subclause No. / Annex Paragraph/ Figure/ Table/ Note Type of comment2 Comment (justification for change) Draft Specification & Bulletin Industry Feedback Form Proposed change Sub 6.3.10 S24 p. 129 te State S24 proceeds to S24-D through RECORD DECRYPTED. Should there be a check on Crypto Read Data Counter > 0? (blank) Status Accept, Reject, In progress, Acknowledge EMVCo Use Only EMVCo observations on each comment submitted Reject No, there is no need to check if Crypto Read Data Counter > 0 at this point. The check is performed later in S202122232425 – A. 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. © 2022 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. October 2022 Page 5 of 16 Consolidated Responses – C-8 Kernel Specification DRAFT2 Comment Source1 EA/Sub Clause No./ Subclause No. / Annex Paragraph/ Figure/ Table/ Note Type of comment2 Comment (justification for change) Draft Specification & Bulletin Industry Feedback Form Proposed change Sub 6.3.12 p. 141 te in Step 202122232425.16, the DF name is compared to the AID of the configuration data. This seems a bit late in the process. Assumingly the same check is done when the Kernel is started, and the kernel is configured, so that a mismatch at this point should never happen? (blank) Status Accept, Reject, In progress, Acknowledge EMVCo Use Only EMVCo observations on each comment submitted Reject A mismatch at this point only happens in the event of a manin-the-middle (MITM) attack. Entry Point has selected the configuration dataset based on the ADF Name in the PPSE. The ADF Name is not secure and can be changed by the MITM to force Entry Point to use another configuration dataset. The Kernel checks whether the AID in the configuration dataset corresponds to the DF Name in the FCI, but this time based on data that is secured (for example by including tag ‘9F06’ in the Extended SDA Tag List). 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. © 2022 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. October 2022 Page 6 of 16 Consolidated Responses – C-8 Kernel Specification DRAFT2 Comment Source1 EA/Sub Clause No./ Subclause No. / Annex Paragraph/ Figure/ Table/ Note Type of comment2 Comment (justification for change) Draft Specification & Bulletin Industry Feedback Form Proposed change Sub Annex p. 299 te A.3 Sub A.1.124 p.285 ed A.1.126 (A.1.124), Others… p.287 (A.1.126) If multiple brands use the C8 kernel, will the kernel have multiple instances of table A.39, each identified by an AID? If so, we assume there will be one table (one set of configuration data objects) active (used), i.e. the one related to the AID of the card used in the transaction. Maybe it can be considered to make this more explicit in the specification. The tables contain respectively "Not used for Kernel 8" and "Not used for contactless". For most readers, it will be clear that these (sets of) bits are used in other contexts. It would however be more readable if these lines would be visually distinguished from the relevant bits e.g. by using italic font. (blank) (blank) Status Accept, Reject, In progress, Acknowledge EMVCo Use Only EMVCo observations on each comment submitted Accept There is an instance of the configuration data table per AID and Transaction Type.  This is explained in Fig 2.3 and Table 2.7. In section 2.3, we will add extra explanation to describe that configuration can also be per RID. Accept The statements “Not used for Kernel 8” and “Not used for contactless” will be replaced by RFU in the final version. 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. © 2022 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. October 2022 Page 7 of 16 Consolidated Responses – C-8 Kernel Specification DRAFT2 Comment Source1 EA/Sub Clause No./ Subclause No. / Annex Paragraph/ Figure/ Table/ Note Type of comment2 Comment (justification for change) Draft Specification & Bulletin Industry Feedback Form Proposed change Status Accept, Reject, In progress, Acknowledge EMVCo Use Only EMVCo observations on each comment submitted EA - - ge Cardholders get more and more Add an implementation option in the Acknow- The independent feasibility used to contactless transaction specification of Kernel 8 to support a ledged study and report, processing which leads to fewer restart of the Kernel for issuer update commissioned by EMVCo, did and fewer contact transactions. In processing after an Online Request not identify this as a business addition, the number of Outcome. requirement. However, EMVCo contactless-only terminals, in Such a restart should be supported at may consider this in the future. particular mPOS without an Start B and at Start D for EMV Data additional contact reader, increases. Therefore, issuers who being sent by the issuer. Processing after a restart should be similar to want to update cards via script EMV processing of online responses and/or 2nd GENERATE AC (e.g. like for contact transactions (see Sections CSU processing in CPA) should 10.10 and 10.11 of EMV Book 3). have an option to do this over the contactless interface. We do not request to add this implementation option immediately. For now it would be considered sufficient to get a confirmation from EMVCo, that this implementation option will be added. [Company name redacted], is ready to deliver input for the specification of this implementation option. 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. © 2022 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. October 2022 Page 8 of 16 Consolidated Responses – C-8 Kernel Specification DRAFT2 Comment Source1 EA/Sub Clause No./ Subclause No. / Annex Paragraph/ Figure/ Table/ Note Type of comment2 Comment (justification for change) Draft Specification & Bulletin Industry Feedback Form Proposed change Status Accept, Reject, In progress, Acknowledge EMVCo Use Only EMVCo observations on each comment submitted Sub 1 2 All ge EMVCo has released this As card vendors, we suggest EMVCo to Reject Kernel 8 cannot be used by document as “Kernel 8 produce a minimum set of common entries in the PPSE under the Specification”. Yet it appears that requirements/functionalities for a card following conditions: the technical details specified are those visible at the interface application to be interoperable with a C-8 Kernel. • without Kernel ID, between the card application and • Kernel ID of length 0, the Kernel. Meaning is more a • or Kernel ID with value 0. specification for interoperability than a Kernel implementation one. This is because Entry Point would use the wrong default By comparison the EMVCo Next Gen was also named as “ EMV value from Table 3-6 in EMV® Book B. Next Generation Kernel System”. Meaning that a complete “technical architecture” was in the scope. It remains that the card application side of the “equation” Book C-8 specifies the behaviour of the Kernel and card application behaviour is out of the scope. is absent in the present “Kernel 8 Specification”. Yet, from a Vendor perspective, card applications able to communicate with the C-8 Kernel are to be designed. EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. © 2022 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. October 2022 Page 9 of 16 Consolidated Responses – C-8 Kernel Specification DRAFT2 Comment Source1 EA/Sub Clause No./ Subclause No. / Annex Paragraph/ Figure/ Table/ Note Type of comment2 Comment (justification for change) Draft Specification & Bulletin Industry Feedback Form Proposed change Sub All ge When EMVCo specified the “ EMV A Migration Guidance Document Next Generation Kernel System”, it should be created by EMVCo. was paid attention to migration [Company name redacted] suggests aspects for next gen cards and that documentation with that respect terminals. That’s an aspect that produced by EMVCo during the Next has not been addressed by EMVCo Gen specification process could be neither in SB 243 nor in the used as a basis present Draft Specification A case is when a card with a legacy application and a new one compliant with C-8 in face of a Terminal supporting existing Kernels and the C-8 should behave Status Accept, Reject, In progress, Acknowledge EMVCo Use Only EMVCo observations on each comment submitted Reject Aspects of the transition to Kernel 8 are outside of the scope of the kernel specification. EMVCo does not control the rollout of the EMV® Contactless Kernel. Each Payment Systems will choose if and when they move to support the use of the EMV Contactless Kernel. 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. © 2022 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. October 2022 Page 10 of 16 Consolidated Responses – C-8 Kernel Specification DRAFT2 Comment Source1 EA/Sub Clause No./ Subclause No. / Annex Paragraph/ Figure/ Table/ Note Type of comment2 Comment (justification for change) Sub 3.3 All ge Section 3.3 is a summary of the transaction steps initiated by the terminal Kernel- Application data flows yet [Company name redacted] considers that it lacks technical details for the card behaviour making it not so useful Sub te The expression “ if the card supports remote data authentication….” Draft Specification & Bulletin Industry Feedback Form Proposed change Status Accept, Reject, In progress, Acknowledge EMVCo Use Only EMVCo observations on each comment submitted § 3.3 assumes that C-8 is already selected and active. We suggest that the preliminary steps are included in section 3.3. Complete this section with details from the card-side of the message exchange and in particular the APDU-C’s generated by the C8. Make consistent the figure with the text describing the protocol. A definition and a description of “remote data authentication” is needed Reject Accept Section 3.3 is informative and aims to clarify the kernel behaviour, not the card behaviour. The Card may use its instance of the Issuer Application Data MAC as input to the Application Cryptogram generation. In that case the Kernel instance of the Issuer Application Data MAC has to be transferred to the issuer. A definition and description will be added. 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. © 2022 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. October 2022 Page 11 of 16 Consolidated Responses – C-8 Kernel Specification DRAFT2 Comment Source1 EA/Sub Clause No./ Subclause No. / Annex Paragraph/ Figure/ Table/ Note Type of comment2 Comment (justification for change) Draft Specification & Bulletin Industry Feedback Form Proposed change Status Accept, Reject, In progress, Acknowledge EMVCo Use Only EMVCo observations on each comment submitted Sub 5.2 All Sub All ge Section 5.2 specifies the Requirements for the card to Reject We believe that the informative commands and data elements for implement the RRP protocol should be section 3.6 together with the the “Exchange Relay Resistance specified in a new document. The detailed state transition Data protocol”. But no technical functional description of both the card descriptions in chapter 6, details are provided. A Relay and the terminal behaviour during the provide sufficient information Resistance Protocol (RRP) was execution of the RPP should be to develop the card side. specified in the past by EMVCo in included in the C-8 Specification Clarify the Book 11 of the Next whether the implementation of the RRP Generation Kernel System. But the is mandatory/optional for the C-8 C-8 draft makes no reference to Kernel. The same for card applications: this original RRP, so we ignore Is the RRP optional or mandatory. what functionalities are required from the card side to support the RRP ge IP situation for any used protocol Please clarify and/or algorithm on both the card and terminal sides as required by C-8 kernel (e.g., RRP, DH Exchange…) Acknow- Thank you for the comment. ledged 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. © 2022 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. October 2022 Page 12 of 16 Consolidated Responses – C-8 Kernel Specification DRAFT2 Comment Source1 EA/Sub Clause No./ Subclause No. / Annex Paragraph/ Figure/ Table/ Note Type of comment2 Comment (justification for change) Draft Specification & Bulletin Industry Feedback Form Proposed change Status Accept, Reject, In progress, Acknowledge EMVCo Use Only EMVCo observations on each comment submitted Sub 8.4 All te This section seems only consider Complete clause 8.4 with the case that Reject This version of the specification the ECDSA signature to sign the the SM2-DSA scheme is used to digitally supports only Certificate ASI ECC certificates. Yet, SM2-DSA is sign the ECC card certificates. ‘01’ (RSA) and ‘10’ (ECSDSA also a possible signature scheme with P-256). The tables in for ECC certificates as referenced Annex C give an overview of the in Annex C Table C-3. 8.4 seems to coding of ASIs in general. The have to be completed certificate ASIs supported by this version of the Kernel are set in C.10. EA Annex A Other ASI values may be assigned with support reserved for future use. te The tags IIN (42) and IINE (9F0C) Add the 2 tags in Annex and define the Accept These tags will be added to the have been added recently in appropriate actions in the different data dictionary and will become several specification Book C-X. As error cases (parsing error, length error, ‘known tags’ for Kernel 8. the book C-8 aims at being a single inconsistencies between tags…). kernel in the future, it would be interesting to define these tags in Book C-8 too. 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. © 2022 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. October 2022 Page 13 of 16 Consolidated Responses – C-8 Kernel Specification DRAFT2 Comment Source1 EA/Sub Clause No./ Subclause No. / Annex Paragraph/ Figure/ Table/ Note Type of comment2 Comment (justification for change) Draft Specification & Bulletin Industry Feedback Form Proposed change Status Accept, Reject, In progress, Acknowledge EMVCo Use Only EMVCo observations on each comment submitted EA 3.2 The Table 2.7 te Kernel TLV Database ; 4.1 TLV Database Risk of overlapping or collisions of proprietary (i.e., custom) tags. Since the C-8 Kernel will be used by multiple Card schemes, there should be some rules to govern the definition of custom tags. to avoid overlapping and collision. Otherwise, a custom tag can have multiple meanings depending on the context. Reject Tag ranges for 3-byte proprietary tags will be included in the final version of the specification. The proprietary tag ranges are provided for use by Issuers. Proprietary tags, known to the Kernel, have meaning only in the context of the AID/Transaction type. EMVCo cannot prevent the risk of overlap and collision within this context. 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. © 2022 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. October 2022 Page 14 of 16 Consolidated Responses – C-8 Kernel Specification DRAFT2 Comment Source1 EA/Sub Clause No./ Subclause No. / Annex Paragraph/ Figure/ Table/ Note Type of comment2 Comment (justification for change) Draft Specification & Bulletin Industry Feedback Form Proposed change Status Accept, Reject, In progress, Acknowledge EMVCo Use Only EMVCo observations on each comment submitted EA 1.1 last para ed The statement "This document defines the behaviour of the Kernel used in combination with cards having a Kernel Identifier indicating Kernel 8, as defined in [EMV Book B]" may be understood in a way that Kernel 8 may only be used with cards combining an AID and Kernel ID = 8 in a Directory Entry in the FCI of the PPSE. But according to EMV Book B, Req. 3.3.2.5, also cards which combine an AID with no Kernel ID, Kernel ID of length 0 or Kernel ID with value 0 can be used with Kernel 8 (like with any other kernel) if the terminal supports a combination of the AID and Kernel 8. Change the last paragraph of Section 1.1 to clarify that Kernel 8 can also be used with cards having no Kernel ID (or Kernel ID of length 0 or Kernel ID = 0) combined with an AID if the terminal supports a combination of the AID and Kernel 8. Reject Kernel 8 cannot be used by entries in the PPSE under the following conditions: • without Kernel ID, • Kernel ID of length 0, • or Kernel ID with value 0. This is because Entry Point would use the wrong default value from Table 3-6 in EMV® Book B. 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. © 2022 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. October 2022 Page 15 of 16 Consolidated Responses – C-8 Kernel Specification DRAFT2 Comment Source1 EA/Sub Clause No./ Subclause No. / Annex Paragraph/ Figure/ Table/ Note Type of comment2 Comment (justification for change) Draft Specification & Bulletin Industry Feedback Form Proposed change Status Accept, Reject, In progress, Acknowledge EMVCo Use Only EMVCo observations on each comment submitted EA 3.3 4-5 te 6.3.14 6.3.16 Processing between states 27 and 28 When the card sends its decision in the GPO response, the terminal has to still go through another terminal action analysis which can alter the decision of the card. The issue is really around the testing and tracing. Since we see the card response but the final terminal decision we don’t see what failed (during the second terminal action analysis) as it is not visible as it would be when you send the TVR where the terminal performs all the risk management before the GEN AC and then the card returns the final decision which can be traced. Follow the standard EMV flow where the card makes the final decision at the 1st Gen AC and not as part of the GPO response. Reject Please note that the card does not make a decision during the GPO response. The card’s decision is returned in the response to the Generate AC command together with the Card TVR. The Kernel uses the Card TVR to update the TVR. The TVR contains all the information as to why the transaction may have failed. 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. © 2022 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. October 2022 Page 16 of 16