The association Technical Cooperation ep2 (TeCo ep2) has published the ep2 Specification Version 8.1.0. We had to adapt the newly specified ep2 security in V.8.0.0 due to changed underlying standards and feedback from the development.

In 2022, the ep2 working group treated 27 change requests (CR). Of these, 3 CRs were rejected, 21 CRs were accepted and the 3 topics MiFare, Sonic/Sensory Branding and UI facilitations for visually handicapped persons were continued into 2023 for further treatment. The most important enhancements & changes in V.8.1.0 are:

• CR 493 ICC Data Retrieval and Storage: With this function the terminal can retrieve transaction and chip data (according to the specified data object list) and store them in the container. This container will be sent to the acquirer via the FE interface and transmitted (BE) or submitted (MI) in container. With this functionality, which is generically defined in ep2, the new transaction flows introduced in Sweden by MasterCard and Visa can be implemented:
  • A new transaction flow for contactless transactions in Sweden allows consumers to present a contactless payment device to a merchant’s contactless reader at the beginning of the tender process and then verify the final amount at the end of the transaction.
  • This new flow will reduce friction at checkout and facilitate the use of card-linked loyalty and incentive services.
    This allows data to be read from the cardholder payment device and used by the merchant for proprietary purposes, such as a loyalty program, within the contact of the transaction session.

• CR 495 Reversal Rework: In the ep2 protocol a reversal notification message shall be repeated periodically until it is successful. This rule can lead to operational problems in case of software bugs or longer host outages, as more and more terminals start sending auto-reversals and continuously increase the load on the host. In theory, the load for smaller hosts can become so high that even if they fix the fault, the host will overload and a recovery is only possible with manual intervention. CR 495 specifies a contingency mechanism by allowing each acquirer to configure whether reversals are deleted after a certain number of attempts.

• CR 498 Enhance Contactless Application Selection: EMV Bulletin No 230 and EMV Contacltess Book B Entry Point Specification V.2.10 specify the Enhance Contactless Application Selection, which is now also supported by ep2. This allows the terminal in the entry point to tell the card which POI type it is (e.g. transit) so that the card can preselect the corresponding application.

• CR 505 EMV Contactless Kernel C8 (EMVCo) defines the additional parameters required for the EMVCo C8 contactless kernel

• CR 508 Security Changes for Version 8: Due to various changes of the general conditions since the definition of the ep2 V.8.0.0 Security four topics need to be adapted:
  • The TLS “cross-signed certificates” approach was due to complexity replaced by an approach with two root certificates: the primary root certificate is mandatory and the secondary root certificate is optional but recommended to support the exchange of root certificates without service disruption.
  • PAN Surrogate algorithm shall be adapted due to the latest PCI DSS 4.0 specification
  • KeyPANReceipt Algorithm, the specification has to be clarified regarding the implementation of the encryption of the PAN on the receipt.
  • The usage of the nonce in the session key cryptogram has been changed

• CR 509 ExpressPay Dynamic Reader Limits (DRL): AMEX has also introduced DRL (Dynamic Reader Limits) from ExpressPay Kernel 3.1 specification. This feature is now supported by ep2 for kernel C4 too.

• CR 516 <POS Entry Mode> for PAN Retrieval: In the ep2 protocol, there is currently no or no clear definition when exactly a transaction is to be considered as a complete EMV transaction and when not (as e.g. Credit with PAN Retrieval from chip). Therefore, the two additional <POS Entry Mode> ’06’ and ’99’ were defined by ep2.

• CR 517 <Order-ID> Card Present: Certain merchants would like to associate their own reference number with a transaction. This reference number will be printed on the receipt and sent to the acquirer in the <Batch Data Financial> container (DSF), who in turn then sends the number back to the merchant in the <Reconciliation Advice File> (RAF).