The Swedish Bankers’ Association (SBA) welcomes the opportunity provided by the European Banking Authority (EBA) to respond to the Discussion Paper on future RTS on strong customer authentication and secure communication under PSD2. This position paper is divided into three parts. First, general remarks on the Discussion Paper. Second, the key areas we believe EBA should consider when developing the Consultation Paper. Third, answers/input to the questions per question (1-20). We wish that our comments are treated as disclosed.
Strong authentication can have many different purposes. To minimize the risk of making a complex matter even more confusing we suggest that the different situations and purposes are handled in their specific and relevant context. This understanding is a prerequisite to figure out the logical and most transparent process flows for all participating parties with the new roles in the payment value chain as stated in the PSD2. The new PII role should be addressed for the RTS, including evaluating the issues and processes of strong authentication. Below are some examples of different situations and points of actions where the authenticating procedures are related to totally different purposes for the participating parties:
• Connect the PIS/AIS/PII to the specific customer’s ASPSP and authentication of themselves towards the ASPSP
• Allow the ASPSPs’ customer to accept the respective PIS/AIS/PIIs service offer:
• PIS – present the payment details to the customer and ASPSP, i.e. initiate the payment
• AIS – to be given access to payment accounts
• PIIs – present a question on availability of funds on a certain account
• Allow the customer to authenticate the service offered from the PIS/AIS/PIIs towards the ASPSP
Key areas for EBA to consider
These are the key areas we argue that the EBA should consider further when developing the Consultation Paper:
• The importance of the Know Your Customer (KYC) process and origin identification and verification of physical ID-cards should be considered and described
• The SBA is of the opinion that authentication elements can be data elements but it must be personalized to a PSU and with the PSU’s adequate control of the device, platform or software used. A requirement on a physical possession of the authentication element will impact service development negatively.
The scope of article 97 has direct impact to ASPSPs production costs and requirements related to achieving a level playing field between the service providers. Therefore, the clarity of the definitions and the scope of article 97 are very important.
From a legal point of view the wording in article 97(A) is not self-explanatory. This unclarity applies also to definition 97(B) and 97(C). The definitions in article 97 have fundamental impact on the functional and technical requirements related to strong customer authentication. EBA should therefore identify, separate and specify the different processes for the roles and responsibilities for PIS/AIS and PIIs compared to those for an ASPSP. Also, it would be valuable for EBA to identify the points in the payment chain where strong customer authentication is necessary, for example:
• the procedures for changes in payment services
• changes in geographic validity of cards
• changes in payment limits
• initiation of recurring transfer/payment which signs off on ensuing money transfers/payments
• amendments in white or black lists or acceptance of electronic mandates
After these clarifications are added the RTF will provide better guidance on which the processes/transactions are and where in the payment chain strong customer authentications is required. To ensure a consistent understanding of the scope EBA could include descriptive figure(s) describing scenarios and the stakeholders involved including point of actions.
The PSU must be defined and the PSU could be a physical person or a legal entity. Minimum requirements on a two factor authentication mechanism should also be defined. The importance of the Know Your Customer (KYC) process and origin identification and verification of physical ID-cards should be considered and described. For an ASPSP it is essential that adding issuing of payment credentials" requires strong customer authentication. The requirement is valid both when issuing the original credentials and when re-issuing (new) credentials. The purpose is to minimize the risk of creating a weak link in the payment chain, a link that is designed to guarantee a secure transaction.
General comment on 4.1 point 23 “dynamically link”: EBA should provide requirements of the context in which the customer is authorizing the payment to enhance mitigation of real time phishing attacks. Dynamic link to amount and payee is not sufficient. It needs to be visible to the customer what is being signed.
Liability of the weakest link in the payment chain
Another important question is how the liability for the weakest link in the strong authentication chain will play out as this is likely to change over time. Article 74 (2) in PSD2 states that if the payee fails to accept strong authentication the financial damage shall be refunded to the payers (ASPSP). The SBA is concerned how this will be achieved in practice. The PSD does not take a stand regarding the responsibilities between the payer and payees’ ASPSPs for credit transfers. Additionally, PSD states that is not a requirement with agreements between TPPs and APSPS. As a result of this bystander-approach and lack of formal agreements risk is unfortunately increased.
Open four-party models (such as card schemes) has a liability regime built into the business agreements and technical standards. For direct debit the liability issues are handled as a part of the PSD.
Identifying whether strong authentication is necessary or not
As the ASPSP is responsible for all but “unauthorised” payments made from the PSU it must be the ASPSP that sets the level of authentication and decides whether or not to use strong authentication. There should be no difference between situations where the PSU has initiated the transaction directly through the ASPSP or through a PIS."
The possession elements can be in an electronic (data) form as well as a physical form. Cards, mobile phones, specialized separate secure authentication and signing apps can all be appropriate examples of possession. The Nordic countries (Sweden, Finland, Norway and Denmark) represent some of the most developed digital countries in the World and its banking industry has developed eID solutions where possession elements consists of both physical elements like Chip Authentication Technology (CAP) solutions and electronic elements like apps. Both solutions have provided experiences based on their ability to adapt to evolving threats (for example malware, identity theft and social engineering), potential service development (for example instant payment schemes) and feedback from end users (citizens and customers).
The experience from all the Nordic countries’ banking industry are similar: when banks began to offer eIDs as apps (in parallel to physical form solutions) – whether to log in to a bank, declare a tax return or verify an online purchase – the use of strong customer authentication increased substantially. This behaviour shift of citizens and consumers resulted in a significant increase in the number of unique users of eIDs as well as the number of transactions performed with strong customer authentication. Currently, 93% of Swedish citizens older than 13 years have access to an eID.
The driver in this transition is digitalisation in general and specifically end users’ behaviour change. Customers and citizens appreciate and use electronic possession elements for strong customer authentication purposes to a larger extent than they do physical elements. The banking industry is constantly exploring fraud levels and has detected no difference in outcome between the use of physical elements and electronic elements for strong customer authentication. Typically, the challenges remain within the manual process on how the eID is distributed. Electronic possession elements has increased flexibility for customers and citizens and has created an environment which is more conducive to digitalisation.
The SBA is therefore of the opinion that authentication elements can be data elements but it must be personalized to a PSU and with the PSU’s adequate control of the device, platform or software used. A requirement on a physical possession of the authentication element will impact service development negatively. Instead of focusing on dedicated devices or tokens, the coming 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. 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.
There are several existing eID-solutions developed and used by the SBAs member banks. To secure that the data is only controlled by the PSU it is vital to monitor mobile cyber threats like malware, identity theft and social engineering etc. When for example an App is used it also needs to be protected and the bullets below can function as input for that scenario:
• Make sure it is your software that runs on the user device
• Protect against manipulation of apps and pirated apps
• Make sure no one spies on the conversation – you are going to send sensitive data, make sure no one can listen to it or change it
• Prevent remote control – make it difficult to remote control the app
• Protected storage – store your secrets securely, use the best the OS can provide, add your own layers
• Hardware binding – tie your app to the hardware, detect if anyone copies or moves credential
• Phone security level – detect the phones security level, prepare to require step-up authentication on attacked system types"
No, the functionality and reliability of behaviour-based characteristics as a method in the context of strong customer authentication needs to be verified. The SBA considers that behaviour 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 valid for increasing the strength of a strong authentication element, for example typing patterns can be used to strengthen the use of PIN. 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.
The parameters (in 42(D) in a risk analysis are used by the ASPSP to reciprocate strong authentication measurements. If the PSU is not in the usual geographic location it is a signal of increased risk which might bring the risk analysis to prompt for strong authentication – i.e. the exemption does not apply as the risk analysis shows higher risk. 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
However, as it is difficult to predict the future regarding technological development, we would suggest for EBA to keep the option open for future innovation where behaviour could in fact serve as a factor of strong authentication (inherence).
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. From a technical perspective there are no formal requirements for foot printing of a device 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 achieved will also be required.
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 minimize the number of false events from being conducted if malware should succeed in bypassing all other measures.
A peek into the future indicates what is likely to be seen when it comes to the next level in securing mobile token apps running on mobile devices for mobile banking. Most smartphones are currently 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 also includes the option 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 appearing likely that this will be widely spread on the market within a couple of years.
As the SBA understands dynamic linking it is about assuring that an authentication or signing crypto element cannot be used for other purposes than what it was generated for. This means that the crypto element should tie the user, the session and event data (e.g. receiver account and amount) together into one element which cannot be used for other purposes or re-played.
There are several ways to obtain this and the methods are already in place and used in existing solutions. It can be obtained by a classic PKI-signing of the event/transaction. In a challenge/response-based solution the response code can be generated so that it contains crypto information about the event data which can be checked during verification and cannot be used for other purposes or re-played. This can be developed even one step further by using two different crypto keys/certificates – one for login and another one for signing. This method makes it impossible for fraudsters to phish for one code to login and then use the same code to sign a transaction.
A challenge is to define 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 levels achieved will be required."
The concept of “dynamic linking” is not defined by EBA even though it has significant importance in view of the potential authentication processes and liability related to them. The SBA has provided input into dynamic linking on question 4. Since the PSD2 does not provide help to interpret the specific content of this concept it needs to be clarified in the RTS. If both the identity of the PSU and the specific data of the single payment transaction needs to be technically combined into one “file”, the feasibility of “dynamic linking” based solutions may be low. This is also an issue when the Issuer of Payment services is different from the Issuer of Authentication mechanisms and not linked together.
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)). This is built on the known risk-level based on business risk models used for a specific set of rules.
The SBA considers that eID solutions such as Mobile BankID fulfils both the objective of independence and dynamic linking. When considering the detailed content of dynamic linking the main focus should be on functional linking of the independent security factors. See also input/answer to question 4.
Yes, clarifications including examples would be very useful. EBA should make it clear in the RTS that it is up to each PSP to decide on 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). The clarifications seems adequate if low risk payments are included and defined. The examples listed as 42(A), 42(C) and 42(E) are good examples when strong authentication should not have to be used consistently. 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.
Another question which arises is if a PSP using PSU-generated white lists has to accept all payees that a PSU would like to white list. The SBA’s opinion is that the PSP should not be required to accept all payees on the white list. This must be left at the PSPs discretion, i.e. which payees and/or categories of payees that are eligible for the PSU to white list.
An additional issue is the responsibility if a white-listed merchant does not meet the necessary requirements set up by EBA. For the above reasons and questions clarification on white lists are therefore required. Based on the responsibilities and business risks stated in the PSD2 the SBA’s firm opinion is that white lists for payees can only be issued by the payers ASPSP.
• 42 (B) What level of authentication is required for initiating payments to white-listed recipients? What is the lower level of authentication required (passwords?). Should there be monetary limits for white-listed recipients, shared white-list for all payment instruments (cards, online banking, etc.)?
• Is strong customer authentication for the secure administration of white lists in scope for the EBA RTS?
• 42 (E) Needs further explanations - non-sensitive payment data may very well be sensitive PII
In example 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 SBA’s view is that aggregation of this information is impossible to accomplish in a four-party model where most payments are carried out. 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. It could be the merchant name and a merchant category code, but the payer’s PSP lacks information about the payee´s transaction history. 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.
For the above reasons 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.
The first payment in a series of recurrent payments shall be strongly authenticated. The list in 42 (A-E) should therefore be added with “recurring payments”.
No, the level of requirements in the RTS should not be too detailed as this is all about the ASPSP's risk appetite / risk tolerance (i.e. business risk in relation to that what is stated under Paragraph 40 of the Discussion Paper and referring to Article 74 (2) of PSD2). According to the first sentence of the article – the ASPSP is responsible if it is not calling for strong customer authentication – unless the debtor has been fraudulent. The second sentence addresses the responsibility of the payees’ ASPSP, but the provision is difficult to interpret and it remains unclear how it will work in practice. This is another incentive for an ASPSP to have room to determine the extent of the risk assessment.
With reference to 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. 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.
It is SBAs opinion that the RTS should present a principle set of minimum criteria for risk analysis, not a detailed specification on how to perform risk analysis. It is up to the PSP to decide on the exact capabilities of its fraud/risk detection based on its own risk analysis model and risk tolerance/appetite. Further, a principle based approach in the RTS would not constrain development of future risk analysis models or new and innovative ways to assess transaction risks.
A future principal set should include, among other, criteria/factors for example:
• a detailed risk profile of the payer (payer level, transactional level)
• exploitation of payers or payee’s location and/or device data (consumer device level, connection level)
• behaviour-based characteristics (transaction and/or profiling level) and predefined low-risk classified beneficiaries/payees or categories thereof defined by the PSP based on market wide transaction history, risk-profile, claims and fraud rate (big data level).
Yes, 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 governance model including a corresponding certification process.
It is not clearly defined what the status is related to third parties’ using and storing of customers’ banking credentials. The SBA proposes that this should not be allowed. There are other and more appropriate ways to give third parties access without them knowing the credentials of the bank customer. As a consequence, more details must be provided in the RTS. For example, the issue regarding context is not discussed in the clarification paragraphs.
Clarification: 51(D) seems not to be covered under 52 i-iii.
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 Discussion Paper. Personal security credentials should not be stored on third party service providers and used by a third party service provider other than what is explicitly agreed by all parties.
There is a risk that the PSU does not understand the value of the security credentials if the enrolment is not managed properly and the PSU is not sufficiently informed. There is also a risk that a fraudster can issue new security credentials where the correct PSU is not aware that the new credentials have been issued. A recommendation is therefore that the PSP should notify the original PSU through a secure channel of issuance/changes to security credentials. If the PSU is in possession of a strong ID-method and needs to issue new credentials (due to expiration dates), should it be possible to use a weaker ID-method to issue the new credentials or should the PSP enforce usage of the existing stronger ID-method?
In the Nordics and Baltics personal security credentials are widely used to also access public services. This kind of usage is considered an independent service and implemented into national law. In most Nordic countries existing regulation prohibits a customer to share security credentials to anyone else including PIS/AIS/PSPs. Due to the PIS/AIS business model national laws on strong customer identification needs to reflect this development. Since these services are well established the accepted procedure on how to provide services via PIS and/or AIS needs to be analysed. The RTS should also take into consideration the time required to amend current regulations. The risks associated with ID theft (e.g. fake identification proofing document) should also be carefully analysed in the context of the RTS development.
Several of SBAs member banks have a chain of trust (strong authentication) that gives the opportunity for easy on boarding of new services including new authentication mechanisms, see Mobile BankID:
Most banking relationships begins with a customer presenting a physical ID document after which the enrolment process of the users’ personalised security begins. It is mostly government agencies that issue physical ID-cards in Sweden. These documents present challenges for banks to verify and authenticate as banks do not own the process of manufacturing, verification and underlying records. Currently it is even for the trained eye difficult to determine if an ID document presented is genuine or false. Sweden lacks an infrastructure for verification of Swedish ID documents and Swedish issuers have no obligation to provide an effective way to determine whether an ID document is valid or not. This is besides EBA’s scope of this Discussion Paper (as it deals with the second part of the process i.e. the electronic control process and not the first i.e. the manual control process). However it is a necessary component for a secure distribution of eIDs that enables strong customer authentication and secure communication under the revised Payment Services Directive (PSD2) possible.
Europol’s Cybercrime Center predicts increasingly sophisticated identity fraud within the framework of organized crime that can use readily available data and inadequate identification processes when buying online and signing of contracts. Today, almost all fraud is enabled by the internet and the web has global reach. Since it is not possible nor desirable to monitor the entire internet appropriate countermeasures needs therefore to continuously adopt to changing threats. On a European level, the implementation of a number of legislative acts (PSD2, AML4 and PAD) can substantially increase the number of ID-documents that banks are forced to accept. The SBA’s opinion is that the number of physical ID-documents that Swedish banks should accept should, in contrary, be limited to those that can be verified towards the issuer. It is unreasonable to expect that Swedish bank employees, or any other Member State bank employees for that matter, should know how to authenticate and control ID documents issued by other Member States.
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 competent 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.
For anti-fraud purposes it would be highly beneficial if the PSP is required to notify the PSU when new security credentials are issued regardless if it is a renewal or a re-certification.
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
• Risks close to the consumer (e.g. shoulder surfing", extortion etc.).
However, this will probably have low material impact of the PSP. In the PIS and the AIS the risk increases due to the current non-regulated situation where personal security credentials are visible to the PIS and AIS and there is no legal ground to prevent it.
Comment on 57v: In terms of cost allocation it is important to note that AIS/PIS providers should not be able to free ride on the banks’ infrastructure when downloading customer data as this is at the core of their business models. There should be a cost allocation or contractual agreement between AIS/PIS stipulating ASPSPs right to charge a reasonable fee for their services. Having that said, the SBA is aware that this is regulated in PSD2, i.e. no agreements are required between the AIS/PIS and the ASPSP. This is an order that complicates the payment chain substantially and decreases the actors’ willingness to take responsibility of their part."
Yes, standardization is key, for example a defined secure communication standard that incorporate all involved stakeholders. Also, governance related issues need to be taken into account. Regulatory arbitrage should be avoided as much as possible.
Lifecycle management of the developed RTS framework is essential to meet future requirements by the market players. The RTS should define and include information and/or risk level indicator(s) related to the strong customer authentication mechanism used and the transaction to be forwarded to the ASPSP. The minimum functional requirements should also include exceptions (for example time-out, non-consistent transactions etc.).
Comment on paragraph 63(B) - the clarification should be a shall" requirement.
Regarding section 4.4 it is important that the standards are well defined and strictly in accordance with PSD2. It should, for example be clear under what conditions (when and how) AIS and PIS have the right to use communication standards and what information they are entitled to have.
Comment on paragraph 63(D) - the previous paragraph relates to question 15 and 16. 63 (D) states that the standards should include minimum requirements, for example “what kind of information/services can be requested via the standard of communication". There must be no requirement on ASPSPs, within the framework of the open, secure communication providing something more than what is strictly required by the PSD2 articles 66-67; i.e. for PIS information about the payment initiation and for the AIS information on the payment account. Payment Account is defined in article 12.4 as "an account of one or more payment service users for use in the execution of payment transactions". This means that data on loans, securities and other accounts are not covered."
According to definitions and terminology of the PSD2 a PSU exploiting PIS or AIS services may also be a corporate customer. Examples and arguments on the benefits of the PIS/AIS services are however only focused on consumer/private customer services. It is important to define to what extent the PIS/AIS services may or may not be exploited by the corporate customers.
The PSU should be able to see the context (information/services and identity of the PIS/AIS) through the PSPs personal security credential solution if the PSP so choses. This in order to avoid situations where the PSU is tricked by the PIS/AIS without understanding which information/services the PSU expose.
No, most federated solutions deals with identification, not providing context for transactions. The proposed secure communication standard should be based on open transparent and by all stakeholders approved standards.
The SBA recommends applying international standards and EBA needs to develop a harmonized and transparent standard. Additionally, a robust and clear liability regime if and how a ASPSPs should be entitled to damages needs to be put in place. The SBA would like to recommend the following as input:
• Apply relevant ISO standards, for example ISO 20022
• SAML / Oauth - Identity federation standards
• Investigate the forthcoming UK open API standard
A suggested way to manage a model framework for security is to incorporate best practices forged from the years of experience of security experts around the world.
The AIS/PIS’s should be regularly audited and certified according to mandated rules and regulations from competent authorities. e.g. ISAE3402, PCI DSS.
Please see answer 17. In any case APSPS’ must have the right to decide on the accepted methods of authentication.
We have divided the answer/input into three perspectives: 1) service and security, 2) risk and, 3) technical.
1. From a service and security perspective the answer is no.
In order to assess a possible solution based on the e-IDAS regulation there is a need to understand how big the problem is. Legislation which aims to address a partly vague and non-quantified problem may require a disproportionate investment that can contradict the purpose and have negative effects on cross-border business.
First, the e-IDAS regulation is applicable for government agencies and public services and is designed to manage identification and not strong customer authentication in payments.
Second, for services in the private sector the e-IDAS regulation is voluntary and thus not entirely relevant.
Third, the past five years Sweden has experienced significant problems with identity theft. The majority of cases stems from banks’ difficulty in verifying physical identity cards issued by the Swedish government as counterfeit ID-cards presented by fraudsters have a high quality of resemblance to valid ID-cards. See also answer/input to question 12. We cannot risk to accept deficient standards on identification and all Member States have different processes, systems and business models. Even if there is an EU-standard on electronic identification there has to be a local authority in each Member State that has the responsibility to control, verify and validate that a non-domestic specific electronic identification meets the EU-standard. The same logic applies to physical ID documents. ASPSP should not be forced to accept electronic identification where the ASPSP has no knowledge on how the issuing of the ID services is controlled in the issuing Member State. This is also an important question in context of directive 2014/92/EU where consumers legally residing in the Union shall have the right to open, access and maintain an account with basic features in any member state.
2. From a risk perspective the answer is likely no. There has to be an EU-standard in regards on how the ID services are managed, for example initial enrolment, fraud prevention, scheme etc. Most important, there needs to be an enforcement mechanism on EU-level that defines which ID documents issued by Member States that are valid and how these are guaranteed by their issuers.
Security standards of e-IDAS are, if we are correctly informed, not yet decided. To respond to the question properly we need to know which authentication level is required (normal, substantial or high). Due to risk management requirements and business reasons it is at the ASPSP's interest to decide which security credentials are acceptable for account accessing purposes.
3. From a technical perspective the answer is possibly yes. For the PIS/AIS/PSP identification purposes e-IDAS may provide some benefits and additional security features. However, this should be subject to further analysis related to the e-IDAS standards.
When it comes to other e-IDAS services like “trusted sites” and “seals” they may be useful for identification of licensed PSP or secure service site.
As indicated above, the solution should be such that there is no need for the PIS, or AIS to get access to personal security credentials. This is because the ASPSP must in all cases be able to authenticate the user = the method and the credentials are provided by the ASPSP. It is up to the e-IDAS regulator to take responsibility and guarantee the risks related to the confidentiality, integrity and availability of PSCs between AIS, PIS providers and ASPSPs.
SWEDISH BANKERS' ASSOCIATION
Hans Lindberg, Lars Rutberg
Swedish Bankers' Association
The Swedish Bankers’ Association represents banks and financial institutions established in Sweden
The Swedish Bankers’ Association represents banks and financial institutions established in Sweden