Article 1.1: One time usage of authentication codes and magnetic stripe transactions
The authentication code required for the Strong Customer Authentication procedure seems to place magnetic card based transactions noncompliant, given that the customer authentication procedure for this type of cards doesn’t provide the generation of an authentication code. Likewise fallback from chip to magnetic stripe would be noncompliant. Fallback should be permitted even with limits so as to in a case of failure of the chip card or the chip card reader the transactions can be executed.
Is it correct to assume that magnetic stripe based transactions will no longer be allowed?
Article 1.2: No expiration time for CAP authentication codes
The authentication code generated by Chip Authentication Program (CAP) protocol based solutions, do not have an expiration time feature given that neither the chip cards nor the CAP readers have clock. The CAP protocol is event based i.e. a generated code is valid until it is used or a subsequent CAP code is used. This requirement places CAP solutions noncompliant.
CAP is presently one of the most secure authentication mechanisms, and one of the most used hardware based authentication codes generator.
Article 1.2.(b): Generation of an authentication code from a previous one from whatever payer
The term “generated for the same payer” should be deleted given that an authentication code should not be derivable from a previous one independent of the payer.
Article 1.3.(b): Unfeasibility in not identifying which of the elements is wrong
In some authentication implementations the user is promptly informed whenever a wrong PIN is entered. By conforming to Art 1.3.b the user would only be informed that the authentication procedure had failed near to the end of the procedure. We are of the opinion that the contribution to protect the authentication procedure does not justify the inconvenience for the user experience.
For example card-present payments and CAP based solutions do not comply to this requirement given that if the PIN is wrong the user is promptly informed of that fact avoiding going through the rest of the, sometimes cumbersome, authentication procedure.
Article 1.3.(c): Unblocking access based on the characteristics of the provided services
The term “characteristics of the service provided to the payer” must be understood as the service provided by the ASPSP and not the one provided by the PIS/AIS.
Article 1.3.(e).ii: Difficulty in detecting signs of malware in some contexts
Some of the mentioned vectors may not be feasible to guarantee in certain contexts, e.g. signs of malware infection in certain card POS terminals.
Article 1.3.(e): User device fingerprint through dedicated interface
API’s that interface with third parties will have to include “information about the customer device” such as payer IP address and browser parameters so that the ASPSP may prevent, detect and block fraudulent payment transactions.
Article 1.3.(e).i: Should include compromised payment account
Compromised payment accounts and e-mule accounts should also be considered.
Article 1.3.(e).iv: Clearer distinction between payer and payee requirements
The term “customer device” should be clarified. It is assumed that this clause refers to “payer’s device”.
Article 1.3.(e).v: Incoherence between the rational and the RTS
Rational paragraph 22c refers to requirements for detailed risk profile of the payee and/or the payee’s device while article 1.3 of the RTS only refers to payer’s requirements. There seems to be some incoherence between both.
Article 3.1: Clarification of the term “characterized by security features” and their mandatory nature
It is not clear if the enumerated security features are mandatory or if they have to be merely defined.
Article 3.1: PINs security features
Typical PIN’s, used in conjunction with magnetic cards or chip cards, barely comply with the requirements of Article 3.1 in respect to being characterized by security features including length and complexity, given that they are limited to four numeric digits. The two remaining requirements (i.e. having an expiration time and controlling the use of non-repeatable characters) rise concerning issues if those features are to be understood as mandatory.
In respect to expiration time, although bank cards do have an expiration date, PINs usually don’t. One might consider that when the cards expire the PINs also expire. Some banks actually maintain the PIN from one card to its replacement (in the card expiration process) so as to avoid having PIN’s being transported through our mail services. By doing so 80% of card issuances are not subject to attacks of PIN interception in the mail.
Present day implementations of banking PIN’s guarantee that PINs are solely processed in the clear inside FIPS 140-2 Level 3 or higher HSM’s. We have no recollection of there being an HSM in the market that may detect and avoid PINs that have repeated characters (actually studies show that approximately 10% of PINs adopted by users are the PIN 1234 and this PIN has no repeating character). An exemption should be contemplated for this situation.
Article 6.3: Clarification of mandatory nature of the mitigation measures
It is not clear if one or both of the sub clauses 6.3.a and 6.3.b are mandatory. A definition of what is considered a “separated trusted execution environment” (separated TEE) should be given. Secure Element’s or TPM’s should also be contemplated as contributions to possible mitigating measures. In practice implementing a separated trusted execution environment at present time is unfeasible given that there are no common TEE frameworks for some of the most popular mobile operating systems.
Article 6.3: Additional mitigation mechanisms
The use of complementary authentication elements as they are able to compensate the segregation limitation of other elements should be considered. For instance, TAN cards and TAN Lists can be used on m-banking solutions to overcome the limitations of SMS OTP solutions.
The Portuguese banking community welcomes the reasoning about the flexibility offered on where and when the dynamic linking can take place.
Rationale Paragraph 26
In relation to this rationale, we identify techniques other than the ones mentioned in this Rationale to create an adequately secured and protected environment to display the amount and the account number of the payee, and assuring the integrity of these data towards the PSU, on a single smart phone with a single online banking app. These techniques include, but are not limited to:
• App Hardening
• App-separation / sandboxing
• Runtime code integrity checking
• Just-in-time code decryption
• White-box cryptography
• Device fingerprinting and binding
• App-store monitoring (for malicious apps)
Brute force, dictionary and Denial of Service attacks
We identify knowledge elements as being also prone to brute force and dictionary attacks. Furthermore the blocking strategy resulting from the limit for maximum consecutive failed authentication attempts are prone to Denial of Service attacks.
Article 8: Exemption list should not be a closed one
The exemption list included on the RTS cannot rule out the use of present day methodologies that are used to ascertain risk levels and minimise the need of SCA, thus rendering a better and less demanding customer experience. Not allowing for them would result on the degradation of current user experience in a significant number of transactions and use cases, where the risk is in fact low.
Article 8.1.(b): Unbalanced requirements between contact and contactless
Contactless card transactions pose a higher risk exposure than contact card transactions given that they are similar with the major exception that contactless cards communicate through the air, thus subject to interception or manipulation in a veiled nature.
Given this fact contact card transactions should benefit from the same exemptions or even higher valued exemptions given the lower risk that they pose.
Article 8.1.(b): Contemplating low risk business sectors such as highway tolls and parking
In certain sectors the transacted services are of low risk given that they are not easily resold resulting in little appetite that attackers have for these services.
For example highway tolls and parkings should be exempted given that the services that they offer are low value and are of no value for the attackers.
Article 8.2: White lists for transactions other than credit transfers
The exemption based on white lists stated in article 8.2 seems to limit it´s applicability to “where […] the payer initiates online a credit transfer”. This exemption should be expanded to other transactions such as, for example a remote payment or a card based transaction to a white listed merchant.
Article 8.2: ASPSP defined White lists
The exemption based on white lists stated in article 8.2 seems to limit the identification of white listed destinations to “a list of trusted beneficiaries previously created by the payer”.
The exemption should also be open to white lists created by the ASPSP and by doing so reducing the unnecessary exposure of strong authentication credentials. As an example an ASPSP may white list (i.e. exempt) payments done towards governmental bodies (ex. taxes, licenses, etc) or done to reputable services companies (e.g. Electrical or water companies).
Article 8.2: Clarification on exemption applicability
On the first paragraph of Article 8.2 the text “is exempted” should be replaced by “can be exempted” so that SCA may still be requested whenever the ASPSP considers that there is additional risk that may require it, so that the protection of the customer may be guaranteed at all times.
Preventing the implementation of stronger security would be against all principles of rationality and common sense. PSPs take risks through liabilities and may be limited by regulations towards not taking too high risks. But regulations should never refrain PSPs from lowering their risks, e.g. through mandating security exemptions. Such an approach would indirectly induce also drastic reaction instead of proper risk-based reactions, should PSPs be confronted with new threats specifically targeting any of the exemption scenarios (e.g. massive low risk transaction fraud).
From our point of view, the answer depends more on the level of obligation of the exemptions from SCA for PSPs than on a PSP’s specific business model that might result in preventing the PSP from applying SCA due to the exemptions. If it is optional for PSPs to make use of the exemptions from SCA, we would not have any concerns because PSPs cannot be prevented from implementing SCA.
We strongly object to a mandatory exhaustive list of exemptions, because given an ASPSP's responsibilities and liabilities the ASPSP must be able to decide on the exemptions.
Article 9.1.(a): Clarification on the term “Data on personalised security credentials”
“Data on personalised security credentials” should be defined or alternatively the word “Data” should be deleted.
Article 9.1.(a): Risk based confidentiality measures
In respect to the confidentiality and integrity of personalised security credentials, a risk-based approach should be supported here as well. For example, there are arguments for permitting the user to get a short view of what he/she has keyed into an authentication field.
Article 9.1.(c): Clarification of the term “tamper resistant”
The use of the word “tamper resistant” should be clarified. Moreover, the cost impact of having a requirement that all distributed usage of cryptographic material must take place in tamper resistant environments should be evaluated.
Article 13.(c): Technology neutral formulation of identity of the issuer and the integrity of the software
“Digitally signed” refers to the usage of one specific technology to ensure the identity of the issuer and the integrity of the software. The market place may evolve and introduce new methods in the future. Hence a more technology neutral formulation should be used.
Article 13.(c): PIN and Card delivered through mail services
It´s common to deliver card and PIN through post office services. This process should continue to be possible provided that additional security measures are implemented such as not sending two or more elements simultaneously through the same channel and implementing activation arrangement required in Article 13.d.
Article 14: Risk based renewal of personalised security credentials
It is suggested to open up to a more risk-based approach in the renewal of personalised security credentials. There is a difference between an ordinary, scheduled renewal of an expired credential, and the replacement of something that has been stolen. It seems too rigorous to require exactly the same procedures for renewal and re-activation of credentials in a trusted setting.
Article 17.1: Bilateral identification between a card and POS
Actual EMV specifications for contact and contactless do not provide secure bilateral identification between a card or mobile device and a payment terminal because the card or mobile device doesn’t identify the terminal. Magnetic stripe cards can´t be compliant also. This requirement would invalidate the use of payments with EMV cards or mobile devices.
Article 19.4: Limit documentation availability to a need-to-know principle
The documentation should be available on a need to know basis to identified and authorised individuals or organizations so as to avoid that the information be freely available to attackers.
Article 20.4: Role attribute functionality
It is not clear what should happen in cases where the role in the certificate doesn’t correspond to the required payment service.
Article 21.5: Contacts for incident response plans
In order to implement an incident response plan the contacts of the participating incident response teams should be available to all involved parties to be used when incidents occur. In addition processes should be required for cleanup after an incident.
Article 22.4: Guarantee that the TPPs provide information collected from user devices
Guarantee that the TPPs provide ASPSPs “with the same information” collected (and not only requested) from the payment service user when directly initiating the payment transaction. This would include for instance geolocation, IP address, etc. In summary we suggest that the term “requested from the payment service user” be substituted by “collected from the payment service user”.
Article 22.5: Limitations to volume and pacing of information requests should be defined.
Limitations to the daily number of non-user triggered accesses are welcomed. Limitations to the volume of information and to the number of transactions per second should be assured.
We do not see a technical constraint that would prevent the use of ISO 20022 message elements for the communication between TPPs and the ASPSP.
We agree with the fact that QTSP will provide the certificates to be used for the identification between PSPs and for web site authentication, however, today there is a lack of QTSP.
Moreover the support for QTSP by the diverse device vendors and application (namely browsers) vendors must be guaranteed and these deployments will be a lasting process.
The need to keep on caching information periodically is not fully understood, given that the AISP may at any time collect the information in real-time, namely when the user logs on to access account information. However we are of the opinion that accessing not more than twice a day seems reasonable.
Furthermore, limitations to the volume of information and to the number of transactions per second should be assured.
National Banking Association
The Portuguese Banking Association (APB - Associação Portuguesa de Bancos) is a private, non-profit business association and the main body representing the Portuguese banking sector. APB members represent more than 95% of the assets in the Portuguese banking system. For more information about APB, please visit: www.apb.pt