PCI Watch

Tracking changes across the Payment Card Industry

SB nº 158: EMV® Book C-4, Version 2.4 Various Errata and Clarification (Spec Change)

v1.0 Specification Bulletins
Contactless

Specification Bulletin No. 158 First Edition February 2015 EMV Book C-4, Version 2.4 Various Errata and Clarification This Specification Bulletin contains various errata and clarifications to EMV Book C-4, Version 2.4.

Applicability

This Specification Bulletin applies to: EMV Contactless Specifications for Payment Systems, Book C-4, Kernel 4 Specification, Version 2.4. February 2014.

Related Documents

None

Description

This Specification Bulletin lists a number of errata for EMV Book C-4, Version 2.4 [EMVC4]. The changes in this bulletin have been categorized by the functionality specified in the relevant sections found in [EMVC4]. Each specification change is defined by the content of the relevant part as is in the Version 2.4 specification, followed by the content to be in the updated specification. Any respective differences in the content to be have been underlined accordingly.

http://www.emvco.com.

A. Read Application Data A.1. Changes to 5.3 Processing Requirements The third paragraph in Section 5.3, Processing Requirements, needs to be updated to remove unnecessary statements on determining support for Dynamic Transaction Limits and Delayed Authorization from the presence of the Card Interface and Payment Capabilities data element. The actual functional behavior is specified in Section 7, Processing Restrictions, which is the step in the transaction flow where the checks on Dynamic Transaction Limits and Delayed Authorization are applied. As Is: During Read Application Data the card may also return the Card Interface and Payment Capabilities data element as defined in Table 5-1. The reader uses the Card Interface and Payment Capabilities in order to determine whether a request to use an alternative interface can be made. The Card Interface and Payment Capabilities data element also determines if the reader supports Delayed Authorizations and Dynamic limits. If the card does not return the Card Interface and Payment Capabilities, then the reader shall assume that an alternative interface is supported by the Card, and that Delayed Authorizations and Dynamic limits are not supported. To Be: During Read Application Data the card may also return the Card Interface and Payment Capabilities data element as defined in Table 5-1. The reader uses specifically the Card Interface and Payment Capabilities Byte 1 Bit 6, ‘Contact EMV Interface Supported’, in order to determine whether a request to use an alternative interface can be made. If the reader supports Dynamic Transaction Limits or Delayed Authorizations, then it uses the Card Interface and Payment Capabilities data element to determine the Dynamic Transaction Limits to be applied and the usage settings for Delayed Authorizations respectively. Section 7, Processing Restrictions, gives further information on the application of Dynamic Transaction Limits and Delayed Authorization Usage Control to determine the validity of the transaction. If the card does not return Card Interface and Payment Capabilities data element, then the reader shall assume that:  Alternative interface is supported by the card,  A specific set of Dynamic Reader Limits are not specified by the card,  Delayed Authorizations are supported by the card.

http://www.emvco.com.

B. Offline Data Authentication B.1. Changes to 6.2 Processing Requirements Additional paragraphs need to be appended to the end of Section 6.2, Processing Requirements [EMVC4]. The new paragraphs specify that the relevant bit in the TVR must be updated when ODA is not performed. In addition, ODA must not be performed when the transaction is to be declined. As Is: The reader determines whether the card should be authenticated using either SDA or CDA based on the card’s ability to support these methods, as indicated in the AIP. The methods supported by the reader are identified in Terminal Capabilities (Tag '9F33'). To Be: The reader determines whether the card should be authenticated using either SDA or CDA based on the card’s ability to support these methods, as indicated in the AIP. The methods supported by the reader are identified in Terminal Capabilities (Tag '9F33'). If Offline Data Authentication is not performed, then the reader must set TVR byte 1 bit 8 to 1b, ‘Offline data authentication was not performed’. If the reader and card support Offline Data Authentication and the transaction is to be declined offline, then Offline Data Authentication must not be performed and the reader sets the TVR byte 1 bit 8 to 1b, ‘Offline data authentication was not performed’. Requirements

  • Offline Data Authentication not performed 6.2.1a If ODA is not performed, Then the reader shall set TVR byte 1 bit 8 to 1b, ‘Offline data authentication was not performed’. 6.2.2a If the card and the reader support ODA, and the transaction is to be declined offline, Then ODA is not performed and the reader shall set TVR byte 1 bit 8 to 1b, ‘Offline data authentication was not performed’. http://www.emvco.com. B.2. Changes to 6.2.1 Single ODA Method Supported Section 6.2.1, Single ODA Method Supported, needs to be updated to clearly specify that the reader is also required to support the corresponding ODA method in use by the card, for ODA to be carried out. As Is: If CDA is the only Offline Data Authentication method supported by the card, then the reader shall authenticate the card using CDA. If SDA is the only Offline Data Authentication method supported by the card, then the reader shall authenticate the card using SDA. Requirements
  • Offline Data Authentication When Card Supports a Single Method 6.2.1.1a If a card indicates support of only CDA method, and ODA is required, then the reader performs CDA. 6.2.1.2a If a card indicates support of only SDA method, and ODA is required, then the reader performs SDA. To Be: If CDA is the only Offline Data Authentication method supported by the card and by the reader, then the reader shall authenticate the card using CDA. If SDA is the only Offline Data Authentication method supported by the card and by the reader, then the reader shall authenticate the card using SDA. Requirements
  • Offline Data Authentication When Card Supports a Single Method 6.2.1.1a If a card indicates support for only CDA method, and the following conditions are true:  ODA is required  Reader also supports CDA Then the reader performs CDA. 6.2.1.2a If a card indicates support for only SDA method, and the following conditions are true:  ODA is required  Reader also supports SDA Then the reader performs SDA. http://www.emvco.com. B.3. Changes to 6.2.2 Multiple ODA Methods Supported Section 6.2.2, Multiple ODA Methods Supported, must be updated to clearly specify that the reader is also required to support the corresponding ODA methods in use by the card, in order for ODA to be carried out. As Is: If more than one Offline Data Authentication method is supported by the card, then CDA takes priority over SDA. Requirements
  • Offline Data Authentication Priority 6.2.2.1a If a card indicates support of both SDA and CDA methods, and ODA is required, then the reader performs CDA. To Be: If more than one Offline Data Authentication method is supported by both the card and the reader, then CDA takes priority over SDA. Requirements
  • Offline Data Authentication Priority 6.2.2.1a If a card indicates support of both SDA and CDA methods, and the following conditions are true:  ODA is required  Reader also supports both SDA and CDA Then the reader performs CDA. B.4. Changes to 6.2.4 Static Data Authentication Section 6.2.4, Static Data Authentication, needs to be changed to specify that the reader must update the relevant bit in the TVR when SDA is the chosen Offline Data Authentication method. As Is: If SDA is determined to be performed, it must be performed as described in [EMV 4.3 Book 2], sections 5 and 6, and [EMV 4.3 Book 3], section 10.3. Requirements
  • Static Offline Data Authentication 6.2.4.1a If the Offline Data Authentication method being employed is SDA, then it shall be performed as per [EMV 4.3 Book 2], section 5 and 6, and [EMV 4.3 Book 3], section 10.3. http://www.emvco.com. To Be: If SDA is determined to be performed, it must be performed as described in [EMV4.3 Book 2], sections 5 and 6, and [EMV 4.3 Book 3], section 10.3. The reader must set the TVR byte 1 bit 2 to 1b, ‘SDA Selected’. Requirements
  • Static Offline Data Authentication 6.2.4.1a If the Offline Data Authentication method being employed is SDA, Then:  It shall be performed as per [EMV 4.3 Book 2], section 5 and 6, and [EMV 4.3 Book 3], section 10.3.  The reader shall set the TVR byte 1 bit 2 to 1b, ‘SDA Selected’. http://www.emvco.com. C. Processing Restrictions C.1. Changes to 7.2.1 Apply Dynamic Transaction Limits The first part of Section 7.2.1, Apply Dynamic Transaction Limits, up to and including requirement 7.2.1.2a needs to be updated to clarify the functional behavior that determines reader support for Dynamic Transaction Limits. As Is: The reader may contain a number of different limits to control the attributes of a contactless transaction. A set of Dynamic Reader Limits may comprise of one or more of data elements: Reader Contactless Transaction Limit, Reader Contactless Floor Limit and Reader CVM Required Limit. If one or more sets of Dynamic Reader Limits are present on the reader, they are collectively referred to as the Sets of Dynamic Reader Limits. The Kernel selects a particular Dynamic Reader Limits for a transaction based on the “Dynamic Limits Set” identifier on the card. The limits from this selection are used by the Kernel to override the limits used by Entry Point. If the card returns Card Interface and Payment Capabilities, the Kernel shall use Card Interface and Payment Capabilities Byte 2 Bits 4-1 as the card’s “Dynamic Limit Set”, otherwise, the card shall be deemed to not have a specified a particular set of reader limits and the default set from the reader will be used (the Dynamic Reader Limits – Default). If Sets of Dynamic Reader Limits is present and contains at least one set of Dynamic Reader Limits and the card has a non-zero “Dynamic Limit Set”, the Kernel shall use the card’s “Dynamic Limit Set” to attempt to select a set of Dynamic Reader Limits from Sets of Dynamic Reader Limits. Requirements – Processing Restrictions: Select Non-Default Dynamic Reader Limits 7.2.1.1a If Sets of Dynamic Reader Limits is present, and Card Interface and Payment Capabilities is present, and Card Interface and Payment Capabilities Byte 2 Bits 4-1 are not set to 0000b, then the reader shall attempt to select a set of Dynamic Reader Limits from Sets of Dynamic Reader Limits using Card Interface and Payment Capabilities Byte 2 Bits 4-1 as “Dynamic Limit Set”. If Dynamic Reader Limits – Default is present, the Kernel shall select this set of Dynamic Reader Limits if any of the following conditions apply:  Card Interface and Payment Capabilities was not returned by the card.  Card Interface and Payment Capabilities was returned by the card and “Dynamic Limit Set” is zero. http://www.emvco.com.  Card Interface and Payment Capabilities was returned by the card and “Dynamic Limit Set” is non-zero but Sets of Dynamic Reader Limits does not contain a set of Dynamic Reader Limits corresponding to the card’s “Dynamic Limit Set”. Requirements – Processing Restrictions: Select Default Dynamic Reader Limits 7.2.1.2a If Dynamic Reader Limits – Default is present and any of the following is true:  Card Interface and Payment Capabilities is absent, or  Card Interface and Payment Capabilities Byte 2 Bits 4-1 are set to 0000b, or  Card Interface and Payment Capabilities Byte 2 Bits 4-1 are not set to 0000b and Sets of Dynamic Reader Limits is not present or does not contain a set of Dynamic Reader Limits corresponding to the card’s “Dynamic Limit Set”, then the reader shall select Dynamic Reader Limits from Dynamic Reader Limits – Default. To Be: The reader may contain three transaction amount limits, which are configured per Application Identifier (AID), which control the parameters of a contactless transaction. Specifically, a set of transaction amount limits may be comprised of one or more of the following:  Reader Contactless Transaction Limit - the amount limit allowed for contactless transactions,  Reader Contactless Floor Limit - the amount limit at which online authorization is requested, and  Reader CVM Required Limit - the amount limit at which cardholder verification is requested In addition to these AID Reader Limits, the reader may also support one or more set of dynamic transaction amount limits, known as a set of Dynamic Reader Limits. Multiple sets of Dynamic Reader Limits may be present on the reader, and are collectively referred to as the Sets of Dynamic Reader Limits. In order for the reader to support Dynamic Transaction Limits, then it must be configured with a default set of dynamic transaction amount limits, known as Dynamic Reader Limits – Default. Figure 7-1 illustrates the part of the process flow relevant to applying Dynamic Transaction Limits that control the parameters of a transaction: http://www.emvco.com. AID Reader Limits Reader Contactless Transaction Limit Reader Contactless Floor Limit Reader CVM Required Limit Transaction Start Apply the static AID Reader Limits Default Dynamic Reader Limits Reader Contactless Transaction Limit Reader Contactless Floor Limit Reader CVM Required Limit Sets of Dynamic Reader Limits Reader Contactless Transaction Limit 1st Reader Contactless Floor Limit Reader CVM Required Limit Reader Contactless Transaction Limit 2nd Reader Contactless Floor Limit Reader CVM Required Limit Up to 16 sets of Limits Application Selected and Data Read No Dynamic Reader Limits – Yes Default configured? Reader not configured to support Dynamic Reader Limits, process continues with static AID Reader Limits Card provides Card No Interface and Payment Capabilities? Card not configured to support Dynamic Reader Limits, Reader Yes applies the Dynamic Reader Limits
  • Default Mutually supported set of No Dynamic Reader Limits identified? Reader applies the Dynamic Reader Limits
  • Default Yes Reader applies the identified set within the Sets of Dynamic Reader Limits Figure 7-1: Dynamic Reader Limits The following is the process description for when the reader supports Dynamic Transaction Limits: 1. If the reader has Dynamic Reader Limits – Default configured, And the card provides the Card Interface and Payment Capabilities data element (Tag ‘9F70’), Then the reader shall attempt to select specific set of Dynamic Reader Limits from the Sets of Dynamic Reader Limits for a transaction, based on the ‘Dynamic Limits Set’ identifier value specified in Card Interface and Payment Capabilities Byte 2 Bits 4-1, with the following outcome: a. If a corresponding set of Dynamic Reader Limits is successfully selected within the Sets of Dynamic Reader Limits present on the reader, Then the referenced set of Dynamic Reader Limits from this selection is used by the reader to dynamically override the AID Reader Limits applied by Entry Point. Else the reader shall apply Dynamic Reader Limits – Default as the set of Dynamic Reader Limits to override the AID Reader Limits applied by Entry Point. http://www.emvco.com. 2. Else if the card does not provide the Card Interface and Payment Capabilities data element, Then the Card is deemed to not support Dynamic Reader Limits and the reader shall apply Dynamic Reader Limits – Default as the set of Dynamic Reader Limits to override the AID Reader Limits applied by Entry Point. The following is the process description for when the reader does not support Dynamic Transaction Limits: 1. If the reader does not have Dynamic Reader Limits – Default configured, Then the reader does not support Dynamic Transaction Limits and the reader shall continue to apply the AID Reader Limits for the transaction. Requirements – Processing Restrictions: Select Non-Default Dynamic Reader Limits 7.2.1.1a If Reader is configured with Dynamic Reader Limits – Default, and Card Interface and Payment Capabilities is present, Then the reader shall attempt to select a set of Dynamic Reader Limits from Sets of Dynamic Reader Limits identified using Card Interface and Payment Capabilities Byte 2 Bits 4-1, ‘Dynamic Limits Set’. Requirements – Processing Restrictions: Select Default Dynamic Reader Limits 7.2.1.2a If Reader is configured with Dynamic Reader Limits – Default, and any of the following is true:  Card Interface and Payment Capabilities is absent, or  Card Interface and Payment Capabilities Byte 2 Bits 4-1, ‘Dynamic Limits Set’, does not correspond to a set of Dynamic Reader Limits present on the Reader Then the reader shall apply Dynamic Reader Limits – Default as the set of Dynamic Reader Limits to be used for the transaction. Requirements – Processing Restrictions: Reader does not support Dynamic Transaction Limits 7.2.1.2b If the Reader is not configured with Dynamic Reader Limits – Default, Then the reader does not support Dynamic Transaction Limits and the reader shall continue to apply the AID Reader Limits for the transaction. http://www.emvco.com. C.2. Changes to Testable Requirements 7.2.1.6a and 7.2.1.7a Requirements 7.2.1.6a and 7.2.1.7a must remove checks on the Card Interface and Payment Capabilities Byte 1 Bit 7, ‘Physical Magnetic Stripe Supported’ and Byte 1 Bit 8, ‘Keyed Data Entry Supported’, to determine whether an alternative card interface is supported to conduct a transaction. As Is: Requirements – Processing Restrictions: ‘Contactless Application Not Allowed’ indicator 7.2.1.6a If the ‘Contactless Application Not Allowed’ indicator is set to 1, and any of the following bits is set to 1:  Card Interface and Payment Capabilities Byte 1 Bit 6  Card Interface and Payment Capabilities Byte 1 Bit 7  Card Interface and Payment Capabilities Byte 1 Bit 8, then the kernel returns control to Entry Point, passing a Final Outcome of Try Another Interface. Requirements – Processing Restrictions: ‘Contactless Application Not Allowed’ indicator 7.2.1.7a If the ‘Contactless Application Not Allowed’ indicator is set to 1, and Card Interface and Payment Capabilities Byte 1 Bit 6 is set to 0, and Card Interface and Payment Capabilities Byte 1 Bit 7 is set to 0, and Card Interface and Payment Capabilities Byte 1 Bit 8 is set to 0, then the kernel returns control to Entry Point, passing a Final Outcome of End Application. To Be: Requirements – Processing Restrictions: ‘Contactless Application Not Allowed’ indicator 7.2.1.6a If the ‘Contactless Application Not Allowed’ indicator is set to 1, and any of the following conditions are true:  Card Interface and Payment Capabilities is not present,  Card Interface and Payment Capabilities Byte 1 Bit 6 is set to 1b, ‘Contact EMV interface supported’, Then the kernel returns control to Entry Point, passing a Final Outcome of Try Another Interface. http://www.emvco.com. Requirements – Processing Restrictions: ‘Contactless Application Not Allowed’ indicator 7.2.1.7a If the ‘Contactless Application Not Allowed’ indicator is set to 1, and Card Interface and Payment Capabilities Byte 1 Bit 6 is set to 0b, ‘Contact EMV interface supported’, Then the kernel returns control to Entry Point, passing a Final Outcome of End Application. C.3. Changes to 7.2.2.2 Application Usage Control A table defining the Application Usage Control (AUC) bit settings must be appended to Section 7.2.2.2, Application Usage Control i.e. following requirement 7.2.2.5a. As Is: Requirements – Processing Restrictions: AUC Environment for other than an ATM 7.2.2.5a If the reader is not an ATM, then: The reader shall check the Application Usage Control to determine whether the card can be used at other than an ATM. If the transaction cannot be performed at other than an ATM, then the reader shall set TVR Byte 2 Bit 5 to 1b, ‘Requested service not allowed for card product’. To Be: Requirements – Processing Restrictions: AUC Environment for other than an ATM 7.2.2.5a If the reader is not an ATM, then: The reader shall check the Application Usage Control to determine whether the card can be used at other than an ATM. If the transaction cannot be performed at other than an ATM, then the reader shall set TVR Byte 2 Bit 5 to 1b, ‘Requested service not allowed for card product’. Table 7-1 illustrates the bit settings for the AUC data element retrieved from the card. http://www.emvco.com. Table 7-1: Bit Settings for Application Usage Control (AUC) Byte 1 (leftmost) b8 b7 b6 b5 b4 b3 b2 b1 Meaning X 1 = Valid for Domestic Cash Transactions X 1 = Valid for International Cash Transactions X 1 = Valid for Domestic Goods X 1 = Valid for International Goods X 1 = Valid for Domestic Services X 1 = Valid for International Services X 1 = Valid at ATMs X 1 = Valid at Terminals other than ATMs Byte 2 (rightmost) b8 b7 b6 b5 b4 b3 b2 b1 Meaning 0 0 = Domestic Cashback not allowed 0 0 = International Cashback not allowed 0 RFU by EMV Specifications 0 RFU by EMV Specifications 0 RFU by EMV Specifications 0 RFU by EMV Specifications 0 RFU by EMV Specifications 0 RFU by EMV Specifications Note: The ISO Country Code of the Chip Card Issuer determines whether a transaction is domestic or international. If the ISO Country Code for the Chip Card and the reader are the same, then the transaction is domestic. If the ISO Country Code in the reader is different from the Chip Card, then the transaction is international. C.4. Changes to 7.2.3.1 Delayed Authorization Usage Check The third and fourth paragraphs in Section 7.2.3.1, Delayed Authorization Usage Check, need to be amended to improve the general sense of the expressed functionality. As Is: Domestic Delayed Authorization Usage Check
  • If the Issuer Country Code read from the card is equal to the Terminal Country Code, then the transaction is defined as ‘Domestic’. If the reader supports delayed authorization, it checks whether a delayed authorization transaction is not permitted in a ‘Domestic’ environment according to the card’s Delayed Authorization Usage Check bits. International Delayed Authorization Usage Check – If the Issuer Country Code read from the card is not equal to the Terminal Country Code, then the transaction is defined as ‘International’. If the reader supports delayed authorization, it checks whether a delayed authorization transaction is not http://www.emvco.com. permitted in an ‘International’ environment according to the card’s Delayed Authorization Usage Check bits. To Be: Domestic Delayed Authorization Usage Check
  • If the Issuer Country Code read from the card is equal to the Terminal Country Code, then the transaction is defined as ‘Domestic’. If the reader supports delayed authorization, it checks whether a delayed authorization transaction is permitted in a ‘Domestic’ environment according to the card’s Delayed Authorization Usage Check bits. International Delayed Authorization Usage Check – If the Issuer Country Code read from the card is not equal to the Terminal Country Code, then the transaction is defined as ‘International’. If the reader supports delayed authorization, it checks whether a delayed authorization transaction is permitted in an ‘International’ environment according to the card’s Delayed Authorization Usage Check bits. http://www.emvco.com. D. Cardholder Verification D.1. Changes to 8.2.1 Process Control Section 8.2.1, Process Control, needs to be updated to clarify the process flow. As Is: Figure Error! No text of specified style in document.-1: Process Control 8.2.1 Process Control Reader CVM Set Limit Exceeded Not set 8.2.6 Reader CVM Required Limit Exceeded Indictor Not Set Card Supports No Cardholder Verification Yes 8.2.2 CVM Processing 8.2.5 Cardholder Verification Unable To Complete over Contactless Interface Cardholder Verification processing must be performed as follows: If the Reader CVM Required Limit Exceeded indicator is set, then:  If the Card Supports Cardholder Verification (AIP Byte 1 Bit 5 is set to 1b), then perform Cardholder Verification processing as described in section Error! Reference source not found..  Else if the Card does not support Cardholder Verification (AIP Byte 1 Bit 5 is set to 0b), then continue processing as described in section Error! Reference source not found.. Otherwise perform Cardholder Verification processing as described in section Error! Reference source not found.. Requirements – Cardholder Verification Processing 8.2.1.1a If Reader CVM Required Limit Exceeded indicator is set, and the Card supports Cardholder Verification (AIP Byte 1 Bit 5 is set to 1b), then the reader shall perform Cardholder Verification 8.2.1.2a If Reader CVM Required Limit Exceeded indicator is set, and the Card does not supports Cardholder Verification (AIP Byte 1 Bit 5 is set to 0b), then the reader shall complete transaction processing as described in section 8.2.5. 8.2.1.3a If Reader CVM Required Limit Exceeded indicator is not set, http://www.emvco.com. Requirements – Cardholder Verification Processing then the reader shall perform Cardholder Verification processing as described in section 8.2.6 To Be: Figure Error! No text of specified style in document.-2: Process Control 8.2.1 Process Control Card supports Reader CVM Limit Set Cardholder No Exceeded? Verification? Not set 8.2.6 Reader CVM Required Limit Exceeded indicator not set Yes 8.2.2 CVM Processing 8.2.5 Cardholder Verification Unable To Complete over Contactless Interface Cardholder Verification processing must be performed as follows: If the Reader CVM Required Limit Exceeded indicator is set, then:  If the Card Supports Cardholder Verification (AIP Byte 1 Bit 5 is set to 1b), then perform Cardholder Verification processing as described in section Error! Reference source not found., CVM Processing.  Else if the Card does not support Cardholder Verification (AIP Byte 1 Bit 5 is set to 0b), then continue processing as described in section Error! Reference source not found., Cardholder Verification Unable To Complete over Contactless Interface. Otherwise perform Cardholder Verification processing as described in section Error! Reference source not found., Reader CVM Required Limit Exceeded Indicator Not Set. Requirements – Cardholder Verification Processing 8.2.1.1a If Reader CVM Required Limit Exceeded indicator is set, and the Card supports Cardholder Verification (AIP Byte 1 Bit 5 is set to 1b), Then the reader shall perform Cardholder Verification processing as described in section 8.2.2, CVM Processing. http://www.emvco.com. Requirements – Cardholder Verification Processing 8.2.1.2a If Reader CVM Required Limit Exceeded indicator is set, and the Card does not supports Cardholder Verification (AIP Byte 1 Bit 5 is set to 0b), Then the reader shall complete transaction processing as described in section 8.2.5, Cardholder Verification Unable To Complete over Contactless Interface. 8.2.1.3a If Reader CVM Required Limit Exceeded indicator is not set, Then the reader shall perform Cardholder Verification processing as described in section 8.2.6, Reader CVM Required Limit Exceeded Indicator Not Set. D.2. Changes to 8.2.2.2 Supported CVM Methods This change inserts a statement in Section 8.2.2.2, Supported CVM Methods in order to provide process continuity to Section 8.2.3, CVM List Processing. As Is: The reader shall create a list of supported CVM methods, as described in [EMV 4.3 Book 3], section 10.5, with the additional conditions: The reader shall not include ‘No CVM required’ as one of its supported methods. If the reader or the associated acquiring infrastructure does not support Online PIN, then ‘Online PIN’ shall not be included as one of the supported methods. Requirements – Reader CVM Supported Methods 8.2.2.2a The reader creates a list of Supported CVM Methods: The reader must not include ‘No CVM required’ as one of its supported methods. If either the reader or the associated acquiring infrastructure for the payment system card being processed does not support the Cardholder Verification Method of Online PIN, then the reader must not include ‘Online PIN’ as one of its supported methods. To Be: The reader shall create a list of supported CVM methods, as described in [EMV 4.3 Book 3], section 10.5, with the additional conditions: http://www.emvco.com.  The reader shall not include ‘No CVM required’ as one of its supported methods.  If the reader or the associated acquiring infrastructure does not support Online PIN, then ‘Online PIN’ shall not be included as one of the supported methods. Once the list of supported CVM methods is created, the process continues as described in Section 8.2.3, CVM List Processing. Requirements – Reader CVM Supported Methods 8.2.2.2a The reader creates a list of Supported CVM Methods with the below conditions, following which processing proceeds as described in Section 8.2.3, CVM List Processing:  The reader must not include ‘No CVM required’ as one of its supported methods.  If either the reader or the associated acquiring infrastructure for the payment system card being processed does not support the Cardholder Verification Method of Online PIN, Then the reader must not include ‘Online PIN’ as one of its supported methods. D.3. Changes to 8.2.3 CVM List Processing The changes in Section 8.2.3, CVM List Processing clarify further the CVM list processing, also providing additional information on the applicable CVM methods. As such the entire section must be reorganized to present the information in a more structured manner that facilitates the understanding of the process flow. Some functional statements mentioned in Section 8.2.4, Contactless Mobile CVM Processing need to be moved to a new subsection under Section 8.2.3 for better relevance. As Is:

8.2.3 CVM List Processing 8.2.3.1 Mutually Supported CVM Identified CVM List Processing proceeds as described in [EMV 4.3 Book 3], section 10.5 If the card contains a CVM List with a method which both card and reader support, then the reader shall store the CVM determined and use it to set the CVM Outcome parameter when subsequently requested (i.e. as part of Final Outcome parameter settings during a request for online processing or transaction completion).

http://www.emvco.com.

If mobile CVM is to be performed, then CVM processing is carried out as described in section 8.2.4. Else if the card supports Cardholder Verification, but there is no common method shared by both card and reader, then the processing continues as described in section 8.2.5. Else CVM processing continues. Requirements – CVM List Processing 8.2.3.1a If all of the following are true: The Reader CVM Required Limit Exceeded indicator is set. The card supports Cardholder Verification (Card AIP Byte 1 Bit 5 is set to 1b). The CVM List is present and contains at least one entry. Then: The reader shall examine the first CVM in the CVM List. |A| If the reader supports the CVM, and the Condition Code of the CVM is equal to ‘00’, ‘02’ or ‘03'‘If reader supports the CVM’, then the reader shall save the matching CVM and return the CVM recorded in the Final Outcome. Else:  If another CVM is present in the CVM List, then the reader shall repeat this requirement from point “|A|”, using the next CVM in the CVM List. Requirements – CVM List Processing 8.2.3.2a If all of the following are true: CVM is not successful (CVM Results '3F 00 00') on completion of CVM List processing. CVM is Mobile CVM and Mobile CVM is not blocked (Mobile CVM Results Byte 1 is '01', ‘Mobile CVM performed’ and Byte 3, CVM Result, is '01', ‘Failed’). The transaction has not previously been restarted. Then the kernel returns control to Entry Point, passing a Final Outcome of Try Again.

http://www.emvco.com.

If the CVM for the transaction is Online PIN, then the reader shall set the TVR bit ‘Online PIN entered’ in anticipation of Online PIN being entered. Online PIN shall be entered once the card can be removed from the reader. Requirements – Online PIN 8.2.3.3a If Online PIN is to be performed, then the reader shall request a PIN and shall set TVR Byte 3 Bit 3 to 1b, ‘Online PIN entered’. To Be:

8.2.3 CVM List Processing CVM List Processing proceeds as described in [EMV 4.3 Book 3], section 10.5, with the following modifications:  If the card contains a CVM List with a CVM method which is mutually supported by both card and reader, and satisfies the CVM condition codes, Then the reader shall store the CVM determined and use it to set the CVM Outcome parameter when subsequently requested (i.e. as part of Final Outcome parameter settings during a request for online processing or transaction completion).  ‘Online PIN’ CVM is carried out as per Section 8.2.3.1, Online PIN CVM.  ‘Mobile CVM’ is processed as per Section 8.2.3.2, Mobile CVM.  If there is no common CVM method shared by both the card and reader, Then the processing continues as described in Section 8.2.5, Cardholder Verification Unable To Complete over Contactless Interface.

http://www.emvco.com.

Requirements – CVM List Processing 8.2.3.1a If all of the following are true:  The Reader CVM Required Limit Exceeded indicator is set.  The card supports Cardholder Verification (Card AIP Byte 1 Bit 5 is set to 1b).  The CVM List is present and contains at least one entry. Then, the following steps are carried out: 1. The reader shall examine the first CVM in the CVM List. 2. If the reader supports the CVM, and the Condition Code of the CVM method is equal to ‘00’, ‘02’ or ‘03’, Then the reader shall save the matching CVM and return the CVM recorded in the Final Outcome. 3. Else if another CVM is present in the CVM List, Then the reader shall repeat the process in this requirement from step 2, using the next CVM in the CVM List. Requirements – CVM List Processing 8.2.3.2a TR removed 8.2.3.1 Online PIN CVM If the applicable CVM for the transaction is Online PIN, then the reader shall set the TVR Byte 3 Bit 3, ‘Online PIN entered’ in anticipation of online PIN being entered. The process then proceeds with Section 9, Terminal Risk Management. The online PIN shall be entered after 1st Card Action Analysis, once the card processing is complete and the card can be removed from the reader. Following PIN entry, the reader proceeds to online authorization as described in Section 12, Online Processing (online PIN transactions require online authorization). Requirements – Online PIN 8.2.3.2a If Online PIN CVM is to be performed, Then the reader shall set TVR Byte 3 Bit 3 to 1b, ‘Online PIN

http://www.emvco.com.

Requirements – Online PIN entered’ and request a PIN after the card is removed.

8.2.3.2 Mobile CVM In the context of Contactless Mobile transaction processing, Plaintext Offline PIN is redefined as ‘Mobile CVM’. (The Mobile CVM is typically an offline “Passcode” stored in the Card application.) Reader support for Mobile CVM is indicated by the Enhanced Contactless Reader Capabilities Byte 2 Bit 8 as 1b, ‘Mobile CVM is Supported’. Card support for Mobile CVM is indicated in the CV Rule, as Byte 1 Bit 6-1 = 000001b, ‘Plaintext PIN verification performed by ICC’. When the applicable CVM is Mobile CVM, then CVM processing is carried out as described in section 8.2.4, Contactless Mobile CVM Processing. D.4. Changes to 8.2.4 Contactless Mobile CVM Processing The following changes need to be applied to Section 8.2.4, Contactless Mobile CVM Processing; they essentially: relocate functional statements not relevant to the section, include a default condition when Mobile CVM Results, Byte 1 or Byte 3, has an undefined value, and add a new subsection to clarify the outcome of an unsuccessful Mobile CVM method, depending on whether the transaction has been previously restarted or not. As Is:

http://www.emvco.com.

Figure 8-3: Contactless Mobile CVM Processing 8.2.4 Contactless Mobile CVM Processing Mobile CVM N supported? Y Mobile CVM N Result from GPO? Y N Mobile CVM Y Result ‘Blocked’? Result = Y “No CVM Performed”? N CVM Results: ‘Failed’ Mobile CVM N Result Successful? Y CVM Results: ‘Successful’ CVM Processing Complete Previously Y Restarted? N CVM Results set as EMV4.3iv section 6.3.4.5 Process Next CVM 9 Terminal Risk Management Entry Point: Try Again 8.2.3 CVM List Processing In the context of Contactless Mobile transaction processing, Plaintext Offline PIN is redefined as ‘Mobile CVM’. (The Mobile CVM is typically an offline “Passcode” stored in the Card application.) For CVM List processing, reader support for Mobile CVM is indicated in Enhanced Contactless Reader Capabilities Byte 2 Bit 8 as 1b, ‘Mobile CVM is Supported’. During CVM List processing, Card support for Mobile CVM is indicated in the CV Rule, as Byte 1 Bit 6-1 = 000001b, ‘Plaintext PIN verification performed by ICC’. The Card Application includes the Mobile CVM Results as defined in Table 81 in the Format 2 response to the GET PROCESSING OPTIONS command.

http://www.emvco.com.

Table 8-1: Mobile CVM Results – Tag '9F71' Mobile CVM Results Byte 1 – CVM Performed b8 b7 b6 b5 b4 b3 b2 b1 Meaning 0 0 0 0 0 0 0 1 Mobile CVM Performed 0 0 1 1 1 1 1 1 No CVM Performed Mobile CVM Results Byte 2 – CVM Condition b8 b7 b6 b5 b4 b3 b2 b1 Meaning 0 0 0 0 0 0 0 0 Mobile CVM not Required 0 0 0 0 0 0 1 1 Terminal Required CVM Mobile CVM Results Byte 3 – CVM Result b8 b7 b6 b5 b4 b3 b2 b1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 1 Meaning Unknown (if Mobile CVM not performed) Mobile CVM Failed Mobile CVM Successful Mobile CVM Blocked If the reader is to perform Mobile CVM as a result of CVM List processing, it must not be carried out as ‘Plaintext Offline PIN’ described in [EMV 4.3 Book 3], section 10.5.1, but must be processed as follows: If Enhanced Contactless Reader Capabilities Byte 2 Bit 8 is 0b, ‘Mobile CVM supported’, then it shall consider that the Mobile CVM is unsuccessful and CVM List processing continues as defined in section 8.2.3. If Mobile CVM Results was not returned in the GET PROCESSING OPTIONS response, it shall consider that the Mobile CVM is unsuccessful and processing continues as defined in section 8.2.3. If CVM Result (Byte 3 of Mobile CVM Results) is '03', ‘Mobile CVM Blocked’, then it shall consider that the Mobile CVM is unsuccessful and processing continues as defined in section 8.2.3. Mobile CVM Results Byte 1, CVM Performed, is processed as follows: If Mobile CVM Results Byte 1 is equal to '3F' (‘No CVM Performed’), then the reader shall set CVM Results, Byte 3, CVM Result to ‘01’, ‘Failed’ and shall consider that Mobile CVM is unsuccessful. If Mobile CVM Results Byte 1 is equal to '01' (‘Mobile CVM Performed’), then CVM processing continues, as below. Mobile CVM Results Byte 3, CVM Result, is processed as follows: If Byte 3 is equal to '02', ‘Mobile CVM Successful’, then the reader sets CVM Results, Byte 3, CVM Result to '02', ‘Successful’. It shall consider

http://www.emvco.com.

that Mobile CVM is successful and set Cardholder Verification was Performed in TSI and consider CVM List processing is complete and proceed with 9 Terminal Risk Management. If Byte 3 is equal to '01', ‘Failed’, then it shall consider that Mobile CVM is unsuccessful and CVM List processing continues. (CVM List processing sets CVM Results, Byte 3, CVM Result to '01', ‘Failed’.) If Mobile CVM is considered unsuccessful, then: If the current transaction has not previously been restarted, then the reader sets a Restart indicator to indicate that the transaction is exiting with a Try Again Outcome with the following parameters set: Start Online Response Data CVM UI Request on Outcome Present UI Request on Restart Present Data Record Present Discretionary Data Present Alternate Interface Preference Receipt Field Off Request Removal Timeout B N/A N/A Yes  Message Identifier: '20' (“See Phone for Instructions”)  Status: Processing Error  Hold Time: 10  Language Preference Yes  Message Identifier: '21' (“Present Card Again”)  Status: Processing Error  Hold Time: 0  Language Preference No No N/A N/A N/A Zero else the current transaction is already marked as having been Restarted, then Mobile CVM is considered unsuccessful and CVM list processing continues as defined in section 8.2.3. Requirements – Contactless Mobile CVM Processing 8.2.4.1a If the reader is to perform Mobile CVM as a result of CVM List processing, then: If Enhanced Contactless Reader Capabilities Byte 2 Bit 8 is 0b, ‘Mobile CVM supported’, then Mobile CVM is unsuccessful and CVM List processing continues.

http://www.emvco.com.

Requirements – Contactless Mobile CVM Processing 8.2.4.2a If Mobile CVM Results was not returned in the GET PROCESSING OPTIONS response, then Mobile CVM is unsuccessful and CVM List processing continues. 8.2.4.3a If Mobile CVM Results Byte 3, CVM Result, is equal to '03', ‘Mobile CVM Blocked’, then Mobile CVM is unsuccessful and CVM List processing continues as defined in 8.2.3. 8.2.4.4a If Mobile CVM Results Byte 1, CVM Performed, is equal to '3F', ‘No CVM performed’, and the transaction has previously been restarted, then Mobile CVM is unsuccessful and the reader shall set CVM Results Byte 3, CVM Result to ‘01’, ‘Failed’ and CVM List processing continues as defined in 8.2.3. 8.2.4.5a If Mobile CVM Results Byte 1, CVM Performed, is equal to '3F', ‘No CVM performed’, and the transaction has not previously been restarted, then the kernel returns control to Entry Point, passing a Final Outcome of Try Again. 8.2.4.6a If Mobile CVM Results Byte 1, CVM Performed, is equal to '01', and Mobile CVM Results Byte 3, CVM Result is equal to '02', ‘Successful’, then the reader sets CVM Results, Byte 3, CVM Result to '02', ‘Successful’, and shall set TSI ‘Cardholder Verification was Performed’, and shall consider that Mobile CVM is successful. 8.2.4.7a If Mobile CVM Results Byte 1, CVM Performed, is equal to '01', and Mobile CVM Results Byte 3, CVM Result, is equal to '01', ‘Failed’, then Mobile CVM is unsuccessful and the reader shall set CVM Results, Byte 3, CVM Result, to '01', ‘Failed’.

http://www.emvco.com.

To Be: Figure 8-3: Contactless Mobile CVM Processing 8.2.4 Contactless Mobile CVM Processing Mobile CVM Results returned No from GPO? Yes No Mobile CVM Yes Result ‘Blocked’? Result = “No CVM Yes CVM Results: Performed”? ‘Failed’ No Mobile CVM Result No Successful? Transaction previously restarted? Yes CVM Results set as EMV 4.3iv section 6.3.4.5 Yes CVM Results: ‘Successful’ No CVM Processing Complete Process Next CVM 9. Terminal Risk Management Entry Point: Try Again 8.2.3 CVM List Processing When Mobile CVM is supported, the Card Application includes the Mobile CVM Results as defined in Table 8-1 in the Format 2 response to the GET PROCESSING OPTIONS command.

http://www.emvco.com.

Table 8-1: Mobile CVM Results – Tag '9F71' Mobile CVM Results Byte 1 – CVM Performed b8 b7 b6 b5 b4 b3 b2 b1 Meaning 0 0 0 0 0 0 0 1 Mobile CVM Performed 0 0 1 1 1 1 1 1 No CVM Performed Mobile CVM Results Byte 2 – CVM Condition b8 b7 b6 b5 b4 b3 b2 b1 Meaning 0 0 0 0 0 0 0 0 Mobile CVM not Required 0 0 0 0 0 0 1 1 Terminal Required CVM Mobile CVM Results Byte 3 – CVM Result b8 b7 b6 b5 b4 b3 b2 b1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 1 Meaning Unknown (if Mobile CVM not performed) Mobile CVM Failed Mobile CVM Successful Mobile CVM Blocked When the reader is to perform Mobile CVM as a result of CVM List processing, it must not be carried out as ‘Plaintext Offline PIN’ described in [EMV 4.3 Book 3], section 10.5.1, but must be processed as follows: If Mobile CVM Results was not returned in the GET PROCESSING OPTIONS response, the reader shall consider that the Mobile CVM is unsuccessful and set the CVM results as per [EMV 4.3 Book 4], section 6.3.4.5. The processing then continues as defined in section 8.2.3, CVM List Processing. If Mobile CVM Results was returned in the GET PROCESSING OPTIONS response, then:  If CVM Result (Byte 3 of Mobile CVM Results) is '03', ‘Mobile CVM Blocked’, then the reader shall consider that the Mobile CVM is unsuccessful and set the CVM results as per [EMV 4.3 Book 4], section 6.3.4.5. The processing then continues as defined in section 8.2.3, CVM List Processing.  Mobile CVM Results Byte 1, CVM Performed, is processed as follows:

  • If Mobile CVM Results Byte 1 is a value other than ‘3F’ or ‘01’, then Mobile CVM is considered unsuccessful and the process continues as per Section 8.2.4.1, Mobile CVM Outcome.
  • If Mobile CVM Results Byte 1 is equal to '3F' (‘No CVM Performed’), then the reader shall set CVM Results, Byte 3, CVM Result to ‘01’, ‘Failed’ and shall consider that Mobile http://www.emvco.com. CVM is unsuccessful. The process continues as per Section 8.2.4.1, Mobile CVM Outcome.
  • If Mobile CVM Results Byte 1 is equal to '01' (‘Mobile CVM Performed’), then CVM method processing continues by examining Mobile CVM Results Byte 3, CVM Result, as per below.  Mobile CVM Results Byte 3, CVM Result, is processed as follows:
  • If Byte 3 is equal to '02', ‘Mobile CVM Successful’, Then the reader sets CVM Results, Byte 3, CVM Result to '02', ‘Successful’. It shall consider that Mobile CVM is successful and the process continues as per Section 8.2.4.1, Mobile CVM Outcome. Else the reader sets CVM Results, Byte 3, CVM Result to '01', ‘Failed’. It shall consider that Mobile CVM is unsuccessful and the process continues as per Section 8.2.4.1, Mobile CVM Outcome.

8.2.4.1 Mobile CVM Outcome If Mobile CVM is considered successful then the CVM List processing is complete. The process continues with Section 9, Terminal Risk Management. If Mobile CVM is considered unsuccessful and the current transaction has not previously been restarted, then the reader sets a Restart indicator to indicate that the transaction is exiting with a Try Again Outcome with the below parameters set:

http://www.emvco.com.

Start Online Response Data CVM UI Request on Outcome Present UI Request on Restart Present Data Record Present Discretionary Data Present Alternate Interface Preference Receipt Field Off Request Removal Timeout B N/A N/A Yes  Message Identifier: '20' (“See Phone for Instructions”)  Status: Processing Error  Hold Time: 10  Language Preference Yes  Message Identifier: '21' (“Present Card Again”)  Status: Processing Error  Hold Time: 0  Language Preference No No N/A N/A N/A Zero If Mobile CVM is considered unsuccessful and the current transaction has previously been restarted, then Mobile CVM method has failed and the CVM list processing continues as defined in section 8.2.3, CVM List Processing. Requirements – Contactless Mobile CVM Processing 8.2.4.1a TR Removed 8.2.4.1a If Mobile CVM Results was not returned in the GET PROCESSING OPTIONS response, Then Mobile CVM is unsuccessful and the CVM results are set as per [EMV 4.3 Book 4], section 6.3.4.5. The processing then continues with CVM List processing as defined in section 8.2.3, CVM List Processing. 8.2.4.2a If Mobile CVM Results Byte 3, CVM Result, is equal to '03', ‘Mobile CVM Blocked’, Then Mobile CVM is unsuccessful and the CVM results are set as per [EMV 4.3 Book 4], section 6.3.4.5. The processing then continues with CVM List processing as defined in section 8.2.3, CVM List Processing. 8.2.4.3a If Mobile CVM Results Byte 1, CVM Performed, is equal to '3F', ‘No CVM performed’, and the transaction has previously been restarted, Then Mobile CVM is unsuccessful and the reader shall set CVM

http://www.emvco.com.

Requirements – Contactless Mobile CVM Processing Results Byte 3, CVM Result to ‘01’, ‘Failed’ and CVM List processing continues as defined in section 8.2.3, CVM List Processing. 8.2.4.4a If Mobile CVM Results Byte 1, CVM Performed, is equal to '3F', ‘No CVM performed’, and the transaction has not previously been restarted, Then the kernel returns control to Entry Point, passing a Final Outcome of Try Again. 8.2.4.5a If Mobile CVM Results Byte 1, CVM Performed, is equal to '01', and Mobile CVM Results Byte 3, CVM Result is equal to '02', ‘Successful’, Then, the reader considers Mobile CVM successful and:  Sets CVM Results, Byte 3, CVM Result to '02',‘Successful’,  Continues the transaction process with Section 9, Terminal Risk Management. 8.2.4.6a If Mobile CVM Results Byte 1, CVM Performed, is equal to '01', and Mobile CVM Results Byte 3, CVM Result, is equal to '01', ‘Failed’, then Mobile CVM is unsuccessful and the reader shall set CVM Results, Byte 3, CVM Result, to '01', ‘Failed’. 8.2.4.7a If all of the following are true:  Mobile CVM Results Byte 1, CVM Performed, is equal to '01',  Mobile CVM Results Byte 3, CVM Result, is not equal to '02', ‘Successful’,  Transaction has not previously been restarted Then the kernel returns control to Entry Point, passing a Final Outcome of Try Again. 8.2.4.8a If all of the following are true:  Mobile CVM Results Byte 1, CVM Performed, is equal to '01',  Mobile CVM Results Byte 3, CVM Result, is not equal to '02', ‘Successful’,  Transaction has previously been restarted Then Mobile CVM has failed and the reader shall set CVM Results, Byte 3, CVM Result, to '01', ‘Failed’ and CVM List processing continues as defined in section 8.2.3, CVM List Processing.

http://www.emvco.com.

Requirements – Contactless Mobile CVM Processing 8.2.4.9a If all of the following are true:  Mobile CVM Results Byte 1, CVM Performed, is not equal to ‘3F', ‘No CVM performed’ or ‘01’, ‘CVM Performed’,  The transaction has previously been restarted, Then Mobile CVM has failed and the reader shall set CVM Results Byte 3, CVM Result to ‘01’, ‘Failed’ and CVM List processing continues as defined in section 8.2.3, CVM List Processing. 8.2.4.10a If all of the following are true:  Mobile CVM Results Byte 1, CVM Performed, is not equal to ‘3F', ‘No CVM performed’ or ‘01’, ‘CVM performed’,  The transaction has not previously been restarted, Then the kernel returns control to Entry Point, passing a Final Outcome of Try Again. D.5. Changes to 8.2.6.1 Contactless Mobile CVM Result Validation These changes apply to Section 8.2.6.1, Contactless Mobile CVM Result Validation (EMV, 2014). Figure 8-5, Contactless Mobile CVM Result Validation needs to be updated with some minor changes that clarify further the functional flow.

http://www.emvco.com.

As Is: Figure 8-5: Contactless Mobile CVM Result Validation If the Mobile CVM Results were returned in the GET PROCESSING OPTIONS response then: If Mobile CVM Results Byte 1 is equal to '01', ‘Mobile CVM Performed’, and Mobile CVM Results Byte 3 is equal to '01', ‘Failed’, and the transaction has not previously been restarted, then the kernel returns control to Entry Point, passing a Final Outcome of Try Again with the following parameter settings:

http://www.emvco.com.

Start Online Response Data CVM UI Request on Outcome Present UI Request on Restart Present Data Record Present Discretionary Data Present Alternate Interface Preference Receipt Field Off Request Removal Timeout B N/A N/A Yes  Message Identifier: '20' (“See Phone for Instructions”)  Status: Processing Error  Hold Time: 10  Language Preference Yes  Message Identifier: '21' (“Present Card Again”)  Status: Processing Error  Hold Time: 0  Language Preference No No N/A N/A N/A Zero Else If the Card supports Cardholder Verification (AIP Byte 1 Bit 5 is set to 1b), then: If the CVM List is not present or is empty, then the reader shall set TVR byte 1, bit 6 ‘ICC Data missing’ to 1b, and set the CVM Results as per [EMV 4.3 Book 4], section 6.3.4.5, and transaction processing continues with Terminal Risk Management. Else If the Card contains a CVM list that includes ‘No CVM Required’ and CVM Condition Code supported for the transaction, then ‘No CVM’ is performed and the transaction continues as per [EMV 4.3 Book 3], section 10.5. Else If the CVM list does not include ‘No CVM Required’ and CVM Condition Code applicable for the transaction, then perform CVM List processing as defined in 8.2.3. Else the Card does not support Cardholder Verification (AIP Byte 1 bit 5 is set to 0b) and CVM List processing is not performed. The CVM Results as per [EMV 4.3 Book 4], section 6.3.4.5, and transaction processing continues with Terminal Risk Management.

http://www.emvco.com.

To Be: Figure 8-5: Contactless Mobile CVM Result Validation 8.2.6 Reader CVM Required Limit Exceeded Indicator Not Set Card is Mobile? Mobile CVM (AIP B2b7 = 1b) Yes Results returned from GPO? No 8.2.6.2 Card Handling Reader CVM Required Limit Exceeded Indicator Not Set Yes Mobile CVM performed? Yes No Transaction previously restarted? No Mobile CVM Result successful? No Yes Entry Point: Try Again Yes Set CVM results to ‘No CVM Performed’ and TVR B1b6 to Yes 1b, ‘ICC Data Missing’ Card supports Cardholder Verification? Yes No Set CVM results to ‘No CVM Performed’ No CVM List or no rules present? No ‘No CVM Required’ valid? Yes Choose ‘No CVM Required’ as applicable CVM 9. Terminal Risk Management No 8.2.2.2 Supported CVM Methods 9. Terminal Risk Management When the value of the Amount Authorized does not exceed the Reader CVM Required Limit, the reader determines if the card application is Mobile-based by checking the setting for AIP Byte 2 Bit 7, ‘Contactless Mobile Supported’ as follows.  If AIP Byte 2 Bit 7 is equal to 0b, ‘Contactless Mobile Supported’, Then the transaction is not Contactless Mobile and processing continues as per section 8.2.6.2, Card Handling Reader CVM Required Limit Exceeded Indicator Not Set.

http://www.emvco.com.

Else the transaction is Contactless Mobile and processing continues as below. The following process happens when the transaction is Contactless Mobile: 1. If the Mobile CVM Results was returned in the GET PROCESSING OPTIONS response Then: a. If Mobile CVM Results Byte 1 is equal to '01', ‘Mobile CVM Performed’, And Mobile CVM Results Byte 3 is equal to '01', ‘Failed’, And the transaction has not previously been restarted, Then the kernel returns control to Entry Point, passing a Final Outcome of Try Again with the parameter settings defined in Table 8-2. b. Else process continues with step 2 below. 2. Else If the Card supports Cardholder Verification (AIP Byte 1 Bit 5 is set to 1b), Then: a. If the CVM List is not present or is empty, Then the reader shall set TVR byte 1, bit 6 ‘ICC Data missing’ to 1b, and set the CVM Results as per [EMV 4.3 Book 4], section 6.3.4.5, and transaction processing continues with Section 9, Terminal Risk Management. b. Else If the Card contains a CVM list that includes the ‘No CVM Required’ method and CVM Condition Code that is valid for the transaction, Then ‘No CVM Required’ is performed as per [EMV 4.3 Book 3], section 10.5, thus considering the CVM successful and the transaction flow continues with Section 9, Terminal Risk Management. c. Else If the CVM list does not include ‘No CVM Required’ and an applicable CVM Condition Code that is valid for the transaction, Then continue CVM processing as defined in section 8.2.2.2, Supported CVM Methods. 3. Else the Card does not support Cardholder Verification (AIP Byte 1 bit 5 is set to 0b) and CVM List processing is not performed. The CVM Results are set as per [EMV 4.3 Book 4], section 6.3.4.5, and transaction processing continues with Section 9, Terminal Risk Management.

http://www.emvco.com.

Start Online Response Data CVM UI Request on Outcome Present UI Request on Restart Present Data Record Present Discretionary Data Present Alternate Interface Preference Receipt Field Off Request Removal Timeout B N/A N/A Yes  Message Identifier: '20' (“See Phone for Instructions”)  Status: Processing Error  Hold Time: 10  Language Preference Yes  Message Identifier: '21' (“Present Card Again”)  Status: Processing Error  Hold Time: 0  Language Preference No No N/A N/A N/A Zero Table Error! No text of specified style in document.-2: Final Outcome Parameter Settings

http://www.emvco.com.

D.6. Changes to 8.2.6.2 Card Handling Reader CVM Required Limit Exceeded Indicator Not Set The following changes apply to Section 8.2.6.2, Card Handling CVM Required Limit Exceeded Indicator Not Set (EMV, 2014). The entire section and Figure 8-6 needs to be updated to provide further clarification on the functional flow. Requirement 8.2.6.14a and 8.2.6.15a need to be replaced with more granular requirements that clearly depict the process in the applicable conditions. As Is: Figure 8-6: Card Handling Reader CVM Required Limit Exceeded Indicator Not Set 8.2.6.2 Card Handling Reader CVM Required Limit Exceeded Indicator Not Set Card Supports N Cardholder Verification? Y Y No CVM list or no rules? N Set CVM ‘No CVM’ Required ‘No CVM Y Required’ valid? N Mutual Y supported CVM? N 8.2.5 Cardholder Verification unable to complete 8.2.3 CVM List Processing 9 Terminal Risk Management If the card is not mobile, and does not support Cardholder Verification or has no CVM List, then the reader shall set the CVM to ‘No CVM required’ and use this when returning a Final Outcome. Else If the card supports Cardholder Verification and the card contains a CVM List with the CVM of ‘No CVM required’ supported for the transaction, then the reader shall set the CVM to ‘No CVM required’ and use this to set the CVM parameter when returning a Final Outcome.

http://www.emvco.com.

Else if the card does not support ‘No CVM required’ for this transaction, then the reader will determine if any mutually supported Cardholder Verification Method is supported and use the identified CVM to set the CVM parameter when returning a Final Outcome. If no mutually supported CVM is identified, then processing continues as in section 8.2.5. Requirements – CVM Processing – Card Does Not Support Cardholder Verification or CVM List Not Present 8.2.6.14a If the Reader CVM Required Limit Exceeded indicator is not set, and the card AIP Byte 2 Bit 7 is 0b (‘Expresspay Mobile is not supported’), and any of the following is true: The card AIP Byte 1 Bit 5 is 0b, (‘Cardholder verification not supported’), or no CVM List is present, or the CVM List is empty, then the reader sets the CVM to ‘No CVM required’ and this shall be stored and used to set the CVM Parameter as part of the Final Outcome parameter settings when sending the transaction online or completing an approved transaction. Requirements – CVM Processing – Card Supports Cardholder Verification 8.2.6.15a If the Reader CVM Required Limit Exceeded indicator is not set, and the card AIP Byte 2 Bit 7 is 0b (‘Expresspay Mobile is not supported’), and the card AIP Byte 1 Bit 5 is 1b, (‘Cardholder verification supported’), then: If the card’s CVM List indicates that ‘No CVM required’ is supported, then the reader sets the CVM to ‘No CVM required’ and this shall be stored and used to set the CVM Parameter as part of the Final Outcome parameter settings when sending the transaction online or completing an approved transaction. Else:  The reader creates a list of Supported CVM Methods. If either the reader or the associated acquiring infrastructure for the payment system card being processed does not support the Cardholder Verification Method of Online PIN, then the reader must not include ‘Online PIN’ as one of its supported methods.  The reader shall examine the first CVM in the CVM List.  |A| If the reader supports the CVM,

http://www.emvco.com.

Requirements – CVM Processing – Card Supports Cardholder Verification and the Condition Code of the CVM is equal to ‘00’, ‘02’ or ‘03', then the reader shall save the matching CVM and return the CVM recorded in the Final Outcome. Else: If another CVM is present in the CVM List, then the reader shall repeat this requirement from point |A|, using the next CVM in the CVM List.  If no mutually supported CVM is shared by the card and the reader, then: If another interface is supported, then the transaction terminates with a request that the transaction be attempted using another interface (contact chip, mag-stripe swiped transaction, etc.). Else the transaction proceeds with Terminal Risk Management, 9.

http://www.emvco.com.

To Be: Figure 8-6: Card Handling Reader CVM Required Limit Exceeded Indicator Not Set 8.2.6.2 Card Handling Reader CVM Required Limit Exceeded Indicator Not Set Card supports Cardholder Verification? Yes No CVM List or no rules present? No No Set CVM results to ‘No CVM Performed’ Set CVM results to ‘No CVM Yes Performed’ and TVR B1b6 to 1b, ‘ICC Data Missing’ ‘No CVM Required’ valid? Yes Choose ‘No CVM Required’ as applicable CVM No 8.2.2.2 Supported CVM Methods 9. Terminal Risk Management The following process, also depicted in Figure 8-6, is carried out when the transaction is not Contactless Mobile, i.e. AIP Byte 2 Bit 7 is equal to 0b, ‘Contactless Mobile Supported’: 1. If the Card supports Cardholder Verification (AIP Byte 1 Bit 5 is set to 1b), Then: 1. If the CVM List is not present or is empty, Then the reader shall set TVR byte 1, bit 6 ‘ICC Data missing’ to 1b, and set the CVM Results as per [EMV 4.3 Book 4], section 6.3.4.5, and transaction processing continues with Section 9, Terminal Risk Management. 2. Else If the Card contains a CVM list which includes the ‘No CVM Required’ method and CVM Condition Code that is valid for the transaction, Then ‘No CVM Required’ is performed as per [EMV 4.3 Book 3], section 10.5, thus considering the CVM successful and the transaction flow continues with Section 9, Terminal Risk Management.

http://www.emvco.com.

3. Else If the Card contains a CVM list which does not include ‘No CVM Required’ and an applicable CVM Condition Code that is valid for the transaction, Then continue CVM processing as defined in section 8.2.2.2, Supported CVM Methods. 2. Else the Card does not support Cardholder Verification (AIP Byte 1 bit 5 is set to 0b) and CVM List processing is not performed. The CVM Results are set as per [EMV 4.3 Book 4], section 6.3.4.5, and transaction processing continues with Section 9, Terminal Risk Management. Requirements – CVM Processing – Card Supports Cardholder Verification but CVM List Not Present or Empty 8.2.6.14a If the Reader CVM Required Limit Exceeded indicator is not set, and the card AIP Byte 2 Bit 7 is 0b (‘Contactless Mobile Supported’), and the following are true:  The card AIP Byte 1 Bit 5 is 1b, (‘Cardholder verification supported’), and  CVM List is not present, or  CVM List is empty, Then the reader sets the CVM Results to ‘No CVM Performed’ and this shall be stored and used to set the CVM Parameter as part of the Final Outcome parameter settings. The transaction processing continues with Section 9, Terminal Risk Management. Requirements – CVM Processing – Card Supports Cardholder Verification and CVM List contains ‘No CVM Required’ 8.2.6.15a If the Reader CVM Required Limit Exceeded indicator is not set, and the card AIP Byte 2 Bit 7 is 0b (‘Contactless Mobile Supported’), and the following are true:  The card AIP Byte 1 Bit 5 is 1b, (‘Cardholder verification supported’), and  CVM List contains ‘No CVM required’, and  Valid CVM condition code for the transaction Then the reader shall perform ‘No CVM Required’ as per [EMV 4.3 Book 3], section 10.5, thus considering the CVM successful and the transaction flow continues with Section 9, Terminal Risk Management.

http://www.emvco.com.

Requirements – CVM Processing – Card Supports Cardholder Verification and CVM list is present but does not contain ‘No CVM Required’ 8.2.6.16a If the Reader CVM Required Limit Exceeded indicator is not set, and the card AIP Byte 2 Bit 7 is 0b (‘Contactless Mobile Supported’), and the following are true:  The card AIP Byte 1 Bit 5 is 1b, (‘Cardholder verification supported’), and  CVM List is present, and  CVM List does not contain ‘No CVM required’ Then the reader shall continue CVM processing as defined in section 8.2.2.2, Supported CVM Methods. Requirements – CVM Processing – Card does not Support Cardholder Verification 8.2.6.17a If the Reader CVM Required Limit Exceeded indicator is not set, and the card AIP Byte 2 Bit 7 is 0b (‘Contactless Mobile Supported’), and the card AIP Byte 1 Bit 5 is 0b, (‘Cardholder verification supported’), Then the reader shall not perform CVM List processing. The CVM Results are set as per [EMV 4.3 Book 4], section 6.3.4.5, and transaction processing continues with Section 9, Terminal Risk Management.

http://www.emvco.com.

E. Terminal Risk Management E.1. Changes to 9.1 Overview Requirement 9.1.1.1a and the third paragraph in Section 9.1, Overview, need to be updated to improve the grammar and thereby clarify

Shown in part. Read the original for the full text.