The additional examples could the issuing of payment credentials" as an item where strong customer authentication is required. The requirement is valid both when issuing the original credentials and when re-issuing (new) credentials. The purpose is to prevent creating a weak link in the payment chain/flow, a link that is a prerequisite for a secure transaction. Also, there is probably a need for using strong authentication in a situation where the PSU orders the PIS to execute future and/or recurring payments.
Article 63 Derogation for low value payment instruments and electronic money includes several exceptions regarding low value payments, but still requires strong customer authentication in accordance with Article 97 (1). The proposal is to evaluate one-factor authentication requirements for those payment. Otherwise, the payment chains (e.g., SMS based payments, NFC based payments widely used in public transport) based on one-factor authentication, will not meet new legal requirements. Article 97 doesn’t allow some basic access to the payment account such as a choice of specific account, check of available balance, currency, which is a crucial payment process part in any payment, including low-value payment.
Additionally, PSP can use several risk minimizing services, such as immediate account notifications in the form of SMS or Push notification or real-time reply on customer request on Account Balance, allowing PSU to perform real-time account monitoring. The proposal is to allow some basic access to the payment account online without allowing the access to the new payment initiation or a payment instrument directly based on one-factor authentication in order to ensure PSU with real-time monitoring services.
Additionally, the exception on lower-level authorization could be added for white-listed payers."
Authentication elements can be data elements and a link with a physical device with the PSU’s adequate control of the device, platform or software used. A requirement for a physical possession of the authentication element will impact service development. Instead of focusing on dedicated devices or tokens, the RTS should focus on generic security factors of the authentication and not limit the means of authentication methods as such.
It is important that the RTS allows for the use of general purpose devices, such as mobile phones and universal identification methods. Other physical devices constitute additional cost and typically have a shorter life span and are less customer-friendly. Therefore, the RTS must allow data, e.g. mobile apps, to be appropriate as a possession element. That requires, however, that the data is stored in a device that is strongly foot printed" by the software issuer. In practice this means, that the possession of the unique mobile device is necessary to make the authentication."
Currently some behavior-based patterns are used for monitoring reasons, but still the personal behavior will always change (e.g., first purchase of car, first utility payments etc.) and can’t be included in strong authentication process as an element or part of any element. Additionally new behavior-based characteristics could appear in the context of the PISPs and the current impact on monitoring result is not fully clear. Therefore, the behavior does not qualify for inherence as it is not strong enough to be considered as a strong authentication element by its own right.
The use of behaviour-based characteristics is also valid as parameters together with other parameters in a risk-based analysis to conclude, if the transaction could qualify for an exemption from the requirement on strong authentication, as example D in paragraph 42 in section 4.2 of the DP, which concerns the application of exemptions.
It is very important that these two areas are clearly separated: 1) what is required of an element to qualify as a strong customer authentication factor, and 2) what are the valid parameters to use in a risk-based decision not to require strong authentication. It is important to have clear discrepancy in definitions in the risk analysis between what strong authentication is and what low risk is. There are two main reasons for this: 1) to understand the dynamics between the two in the practical implementation; 2) to understand the context of determining liabilities according to PSD2. When exemptions are used in compliance with the potential RTS that will allow risk analysis – and strong authentication is therefore not done on a transaction – the liability falls on the party not supporting strong authentication for the specific transaction.
We see challenges in combining customer and security needs particularly in multipurpose devices used via multichannel communication. From a security perspective, isolation of the authentication application needs to be separated and secured apart from the “generic” mobile apps. The generic nature of the device may lead to weak foot printing" of the device from the issuer of the authentication elements. There are no formal requirements for foot printing of a device from a technical perspective and it would be positive if there were. The architecture in all devices are also different which provides challenges as well as setting the appropriate definition of strong customer authentication method for the various devices/tools being used. A governance model for assurance of the level of security level achieved will too be required.
There are several ways to obtain the required security features of the mobile token app. The most central is to secure a strong hardware connection between the app and the mobile device. This is done during the initial enrolment process of the mobile token app.
Making the mobile device a true and independent “possession” element is about avoiding that the software token app can be migrated on to another mobile device. This means that the software is tied to the physical mobile device and therefore can be considered independent. The only condition is that the app is not storing the password “knowledge” element. This means that you cannot login if you get hold of the mobile device alone as you will also need to know the user id and password. Vice versa, it must also not be possible to download the mobile token app on another mobile device and using the name of another user if you know the user’s knowledge element (password).
By splitting crypto keys/certificates used in the authentication and signing process some parts are stored on the mobile inside the app and some parts are stored centrally on the host. This makes it very difficult to move the app to another mobile and get it operational.
Independence of authentication elements in mobile banking
• A software token authentication app is exposed to malware with the potential ability to intercept communication and compromise the security. Currently, there are no commercial authentication solutions (mobile or other) that cannot be tampered with by malware. As a consequence, security is focused on building adequate measure that minimizes and mitigates the risks. This is done by adding several security layers, for example:
• All communication between the apps and the host is encrypted. The app will only communicate to the host as the communication crypto key/certificate is pinned
• Complete separation of the mobile banking app from the mobile token app - i.e. two independent apps
• No direct communication on the mobile device between the two apps
• No app switching on the mobile via the mobile operating system
• Encrypted communication goes from the banking app to the host, from the host back to the mobile and pushes an authentication request to the mobile token app
• The mobile token app conducts the crypto mechanisms required in the authentication process through encrypted communication with the host and returns an “ok” or “not ok” to the authentication request
• The host sends the result to the banking app via encrypted communication
• Not allowing the banking app and the mobile token app to run on rooted/jailbroken mobile devices. This reduces the risk of having malware running on the mobile trying to intercept the banking session
• Sealing mechanisms built into the mobile token app can also protect the app from malware interference
• Additionally and on top of that there are several commercial solutions that can detect if malware is trying to intercept the session. Malware detection is also running on the host and issue alarms if malware is detected. Additionally, fraud monitoring and risk engines can stop any false events from being conducted if malware should succeed in bypassing all other measures.
• There are indications on what is likely to be seen in the future when it comes to the next level in securing mobile token apps running on mobile devices for mobile banking. Currently, most smartphones are equipped with so called Trusted Execution Environment (TEE) in the hardware. This will make it possible to step up security measures even further having the mobile token app running towards the TEE isolated and bypassing the mobile device’s operating system. This includes also the possibility to have a Trusted Display that cannot be reached from the mobile operating system. The mobile handset industry is working on identifying a commercial standard for this TEE and it is likely that this will be widely spread on the market within a couple of years."
The concept of “dynamic linking” could be a good additional layer of the security and the main reason and objective behind is very clear, but it can have some limitations or potential business restrictions.
• Currently, several security tokens (devices generating challenge/response OTPs) exist in the market and fulfill the dynamic linking requirement. But this type of devices has extremely low user acceptance and quite high production costs. In case of many PSPs would move to that specific type of tokens, the penetration of specific technology would increase and it could become more attractive target for any kind of attack.
• Is the usage of qualified electronic signatures to sign a specific transaction fits the requirements of dynamic link to the payee and a specific sum. A content of signed document gets fixed, so is it treated as dynamic linking with specific sum and a payee?
• How dynamic linking should work in case of inherence data element usage, e.g., password and fingerprint?
• The requirement to link a transaction with specific amount and payee definitely should protect a PSU, but would not allow to perform the approval of standing order or a multiply payment approval?
For card transactions the 3D Secure infrastructure provides a dynamic linking to the amount and the payee, for whatever authentication method the card issuer chooses to use (strong, weak or suppressed (risk-based).
Several MobileID solutions (MobileID in Estonia, Mobile BankID in Sweden etc.) fulfil both the objective of independence and dynamic linking. Solutions with strong foot-printing currently fulfil both the objective of independence and dynamic linking. When considering the detailed content of the dynamic linking the main focus should be on functional linking of the independent security factors.
Yes, clarifications including examples would be very useful. The clarifications seems adequate if low risk payments are included and defined. The examples listed as DP 42(A), 42(C) and 42(E) are good examples when strong authentication should not have to be used consistently
• Additional the issue double authorization appears. Currently, there is a requirement to apply strong authentication for the access for the payment account online and then every specific transaction should be authorized. From usability perspective, it’s always double authorization for PSU. The requirements should allow to authorize each transaction once. So, a minimal access to the payment account (e.g., checking a balance, choosing of account and currency) without performing a transaction should be allowed without strong authorization at all or based on one-factor authorization. It should be possible at least for DP 42 examples.
• Proposal to include a PSP accepted white-list, e.g., state-owned companies or organizations (State Revenue Centre), municipalities.
• Informational services without full set of sensitive data, such as Push notifications, SMS notification on outgoing transactions, card reservation (addressing IT security issues) and incoming transactions (addressing AML issues). Notification services are important part of risk minimizing service, allowing customer instant overview and control on his account.
DP Example 42(B) raises additional questions, such as how and on what ground white lists are collected and applied. It would be beneficial if EBA can elaborate on this in the RTS, for example:
• Can a white list consist (in part or in whole) of payees that the payer have payed to before, i.e. “passive collection”? Additionally, with an opportunity for the payer to delete payees from the list.
• Does a PSP using PSU-generated white lists have to accept all payees that a PSU would like to white list?
• What level of authentication is required for initiating payments to white-listed recipients? What is the lowest level of authentication required?
In example DP 42 (D) EBA states in paragraph 44 that it “currently observes in the market that the reliability of such analysis is closely related to the availability of sufficiently detailed information and history from both, the payer and payee.” Further, EBA states in paragraph 45 that it should be required “to be based on comprehensive real-time risk analysis taking into account (a) an adequate transaction history of that customer to evaluate the latter’s typical spending and behaviour patterns, (b) information about the customer device used (e.g. IP address, model, operating system, language preferences) and where applicable (c) a detailed risk profile of the payee (e.g. types of service provided, transaction history) and the payees device (where applicable).”
• A lack of detailed history of data from both the payer and payee will result in difficult assessments for all parties in the payment chain.
• The PSP of the payer has the necessary information on the payer (at least if the PSP is also the ASPSP), but little information on the payee.
• The other way around, the PSP of the payee has the necessary information about the payee, but lacks information about the payer, apart from any transaction history on this specific payee (and if the same payment instrument was used by that payer).
EBA should consider and elaborate under what circumstances risk-based analysis should be possible to be used by the payer’s PSP or the payee’s PSP, or both. For a card transaction, for example, if the PSP of the payee (the acquirer) together with the payee (merchant) decides to use a risk-based decision not to support strong authentication (i.e. 3D Secure infrastructure which enables the dynamic linking of the authentication method used by the issuer) for a specific transaction, the PSP of the payer, the issuer, does not get any possibility to do a risk-based decision of its own, the decision is already taken from the point of interaction. This strongly relates to the allocation of liability for fraudulent transactions, as provided by Article 74(2) in PSD2. (skriv om stycket)
EBA should also make it clear in the RTS, that it is up to each PSP to what extent the PSP uses the possible reasons for exemptions from the requirements on strong authentication. The RTS should specify what maximum that can be allowed as criteria for exemptions. With this in place the individual PSP can decide not to exercise this possibility or to a lesser extent than possible (i.e. with stricter requirements than stated in the RTS for when the strong authentication is not prompted).
With reference to the question 19 and the e-IDAS regulation the premise in the RTS should be that authentication requirements arising from PSD2 are not the same as the requirements arising from e-IDAS. Also, the security levels defined in e-IDAS have neither been assessed nor decided regarding payment services. For this reason the methods or processes and actual requirements of strong authentication in PSD2 are not the same as in e-IDAS. The PSD2 approach should be based merely on definitions in the PSD2 (i.e. two security factor approaches). In practice this would mean that strong authentication which meets the e-IDAS requirements meet the requirements arising from PSD2. In addition to this there may also be other methods which can be used for authentication of PSD2 related transactions
• Yes, for example 1) a detailed risk profile of the payer, 2) exploitation of payer’s or payee’s location data and, 3) behavior-based characteristics.
• Finally, limits on contactless payments. The value in PSD2 is currently set at 30 euro, is this reasonable in the long run?
• The RTS should define and include information and/or risk level indicator(s) related to the strong customer authentication mechanism used. This should be forwarded to the ASPSP as part of the communication. If the ASPSP considers the transaction as a high risk then it should be possible to request a step-up procedure.
Yes and a clarification, should and how PSP can ensure the protection of data in case of PISP involvement? Article 67 (b) says, the PASP ensure the personalized security credentials are not accessible to the other parties and are transmitted through safe and efficient channel, but at the same time the Article 66 (3) (b) says, PISP can transmit that data also through safe and efficient channel. So, that means PASP can’t ensure and be responsible for the data at the moment when PSU communicates with PISP. So, there is needed a shift of liability and explanation. The right to initiate a payment through the PIS service will increase the vulnerability of the services e.g. due to risk of social engineering or lack of information. To protect different payment entities standardization is crucial and it is also important to implement a standard governance model including a corresponding certification process.
PISP doesn’t need to have any agreement with PSP, the PSU should have an easy possibility (easy available register with good search function, mobile friendly) to check and track a legal aspect of any PISP.
Strong consideration and additional measurements and security requirements toward treating personal inherence data should be done. If constantly many PSP or PISP will provide inherence data based authentication means, PSU can face situation, when his inherence data is spread and available to the several issuer of authentication means. In case of usage of inherence data, the possibility to block a payment instrument is very limited. As far as fingerprint is the unique, not changeable, not revocable etc.
It is not clearly defined what the status is related to third parties’ using and storing of customers’ banking credentials. This should not be allowed since there are other ways to give third parties access without them knowing the credentials of the bank customer. More details must be provided in the RTS. For example, the issue regarding context is not discussed in the clarification paragraphs.
The highest risk if a possibility to perform phishing services and low protection of consumer. Consumer can provide security credentials’ data to the PISP or fake PISP, e.g., fingerprint, and relies on it. Attacks can become much more scalable, so consumer protection mechanism should be analyzed. New attacks against PISP could appear.
There is an inherent risk that the technology protecting the users’ personalised security credentials becomes too complicated as the payment chain changes. Therefore, it is important that each part in the payment chain identifies, carries and is responsible for their risk in that chain. A lack of common oversight of the payment chain can create problems for those parties under oversight and can push regulatory arbitrage which is a contradiction to the purpose of the DP. Personal security credentials should not be stored on third party service providers and used by a third party service providers other than what is explicitly agreed by all parties.
There is a risk that the PSU doesn't understand the value of the security credentials if the enrolment is not managed properly and the PSU is not sufficiently informed. Information on new setup of payment chain and new role of PIS should be explained to the society.
No real innovative solutions, but there is important to remember, if the full set of security credentials is issued to the user, or there is a replacement of one element not compromising another. Possible channels: Post, SMS, stand-alone disconnected device.
No, certification should be a global standard. Otherwise the whole concept of TPPs access to account becomes chaotic. The TPPs should be regularly audited and certified according to mandated rules and regulations from approved authorities. e.g. ISAE3402, PCI DSS. The applicable rules should apply to all parties involved, i. e. AIS and PIS should be certified in the same way as the ASPSP. To secure a level playing field AIS and PIS should be certified at and on the same level.
In general, additional layers drive complexity and reduces control, for example third parties and their environments. The highest risk/threat segment will likely be a moving target and the weakest link in the chain will change over time. The following points in the payment chain should be taken into account when EBA develops the RTS:
• Identification of the licensed PSP. The main concern is how a PSU can make a distinction between the licensed PIS/AISPSP and a fraudster. This is the point in the payment chain which is most likely to be subject to social engineering
• PSU has no effective control over the factual exploitation of the service credentials in the PIS/AIS services. The risks related to PIS and/or AIS services are embedded into their business models and not connected to specific technology or legislation
• Payment platforms exploited by the payee or payee’s PSP may be technically unsecure
• In the PIS and the AIS the risk increases due to current non-regulated situation where personal security credentials are visible to the PIS and AIS and there is no legal ground to prevent it
• Anti-money laundering part can suffer. User will be able to use payment services through PISP for a long-term, but PSP should ensure AML requirements? If PSP and ASP is the same entity, it should ensure infrastructure, but at the same time ensure Know you customer principle
• What is the vision on consumer protection regarding inherence data, for example, fingerprint. In case it’s compromised, what will be next step? It can’t be canceled or blocked etc.?
• Better conditions for Trojan attacks. Less possibility to differ a behavior between human taping and robot data input, the number of tool for issuer of security credentials becomes much smaller.
a) “Common and open” standards: a common definition would be welcome – as there are currently a range of definitions and interpretations available. Such definition should include a view on the required governance to evolve the standards concerned.
b) Identification of AIS and PIS providers towards ASPSPs for access: yes, including providing evidence that they are duly registered and regulated.
c) Secure communication between ASPSPs and PSUs, and AIS/PÏS providers: PKI architectures should be used.
d) Minimum functionalities requirements for the future common and secure open standards of communication: yes, and full automatization should be included as minimum.
e) Minimum security controls: there should be 3 layers of security controls:
- The PSU should be able to verify that he gives consent to a registered and regulated AIS/PIS provider;
- The AIS/PIS provider should be able to verify that he deals with a genuine PSU.
- The ASPSP should be able to verify automatically that any request originates from a registered and regulated AIS/PIS provider, on behalf (i.e. with the express consent of) a genuine PSU. The ASPSP should be able to reject any request that i.a. does not meet this test.
f) Minimum technical requirements for the common and secure open standards of communication: a wide range of market solutions already exist to supporting such secure communication. For due reasons interoperability is required. It can however not be expected that all existing solutions become interoperable with each other. For practicality yet mostly for cost efficiency purposes EBA should the requirements for a small (e.g. 3) set of default secure communication standards, for interoperability purposes. Such approach would support channel independence and allow for the gradual introduction of innovations.
Not only innovation, but also market continuity is to be enabled. The RTS thus should specify a small range (e.g. 3) of communication protocols, how ASPSPs and AIS/PIS providers will identify themselves and how they will be authenticated, and a set of generic request, response and authentication messages. On the basis of the RTS market players will have to work on implementation guidelines in order to over time achieve full interoperability.
There are a small number of well accepted market solutions in Europe which leverage the PKI architecture and which would continue to be used by AIS/PIS providers. Work on interoperability between these solutions should be enouraged.
We would submit that for the period until the planned review of PSD2, the transposition of the latter’s new dispositions whilst maintaining customer confidence and system efficiency already constitutes a significant challenge – “other innovative business models” could be contemplated at a later stage.
Currently it can’t be basis or mandatory part included to the strong authentication requirements and/or communication. The e-IDAS Regulation has been drafted with mainly government services in mind, most of its definitions and dispositions could be applied to the development of market services, where identities would be issued by PSD2 registered and regulated market participants within own schemes or joint schemes with government authorities (processes may however need to be adapted to the realities and obligations of a primarily commercial environment).
Yes, it could address authentication and communication part, but as not mandatory part. Mutual recognition of schemes includes high costs, which could destroy small business models and would overcomplicate a payment market.
When it comes to other e-IDAS services like “trusted sites” and “seals” they may be useful for identification of licensed PSP, PISP, AISP, ASP or secure service site.
Association of Latvian Commercial Banks
[Non-financial, private sector institution"]"
The Association of Latvian Commercial Banks (ALCB) is a public organization, uniting on voluntary principle the banks registered in Latvia and branches of foreign banks.