Response to discussion on RTS on strong customer authentication and secure communication under PSD2
Go back
AIS players welcome the publication of the EBA’s Discussion paper as part of the Regulatory Technical Standards for the Payment Services Directive (PSD2) and we appreciate the opportunity to contribute to their drafting, in order to ensure a level playing field among all actors.
In the context of the future Regulatory Technical Standards on strong customer authentication and secure communication under the revised Payment Services Directive, AIS European players call for a balanced approach between the necessity to enhance consumer protection and the security of payment on one hand, and consumer’s wishes to benefit from innovative, easily accessible services on the other. This is perfectly coherent with the two main purposes of the Directive: improving consumer protection and promoting competition through a regulatory framework that allows new services such as Account Information Services. Therefore, we welcome the possibility given by the EBA, through this discussion paper, to contribute to the future technical standards and we call the EBA to consider our position.
AIS European players urge the EBA to implement in the technical standards, the following principles:
• Effective and risk-based requirements Taking into account the fundamental differences in terms of risks between Payment Service Providers (PSPs) and Account Information Services (AIS). As the latter are read-only services, AIS should not be regulated as if they were PSP, as the risks are different.
• Fair competition among all actors to encourage innovative, accessible and user friendly services
• Technology and business-model neutrality to stimulate future innovations.
• Banks should be in the first line to provide strong authentication processes as more people use their smartphones for managing their finances, but this should not be used as a mean to block AIS. In read-only access, banks should create user-friendly environments for their customers and AIS.
• Regulators should bear in mind that the digital development is moving at a very fast pace and adaptable regulation is key to provide a level playing field, especially for new services such as AIS. Future European innovations should not be limited.
• The finance sector is not limited to the EU and its e-security agenda. The EBA should take into account that the stakes are worldwide. Yet today most of the innovations come from the United States. European players should be enabled to innovate thanks to an adequate framework.
We would like to highlight that the provisions of the future RTS should not prevent AIS to develop new innovative services and their capacity to also provide Payment Initiation Services (PIS). Thus PIS and AIS would be provided by the same companies and integrated as one service. Hence it is very important that the authentication systems are designed to facilitate a smooth user experience through integrated authentication processes, when using these combined services. Obviously in this case, AIS will fully comply with the regulation drafted for PIS.
Last but not least, AIS players would like to highlight that many innovations are driven by very small companies and start-ups, which come to the market with services meeting European consumers’ needs and expectations regarding financial services. Therefore, the future RTS should create a secure environment for financial services without imposing administrative burdens or overtly complicated measures that could kill future innovations. RTS should avoid imposing requirement on AIS to make significant investments in technical infrastructure.
It is a difficult exercise to forecast future innovation given the continued increase in the digitalization of financial services. AIS players are in an ongoing development process to better understand the customers’ needs and expectations. We call the EBA not to lock this process at the heart of our business model and of our customers’ relations. Future RTS should be as clear as possible and create opportunities while developing adequate security requirements.
All questions are not relevant for AIS. Therefore, we concentrate our answers on the ones with decisive impact on our activity.
Recital 96 of the Directive provides that “the security measures should be compatible with the level of risk involved in the payment service. In order to allow the development of user-friendly and accessible means of payment for low-risk payments, (…), the exemptions to the application of security requirements should be specified in regulatory technical standards. This is even more applicable for AIS, which are read-only services. This means that no money is moved from one account to another by the AIS, there is indeed no transaction. This proportionality principle should be clearly enhanced in the future RTS.
Therefore, AIS players welcome the opening towards the application of the exemptions to “purely consultative services, with no display of sensitive payment data, taking into account data privacy laws”. This would indeed acknowledge the specific nature of AIS.
Nevertheless, the devil is in the details and different approaches to the notion of “sensitive payment data” could have different impacts on AIS ability to provide accessible and user’s friendly services. AIS players share the definition given by the directive on “sensitive payment data” but we also invite the EBA to stipulate that data linked to the financial activity are not sensitive data in the sense of the directive, if the customer gives his consent to the AIS for accessing and treating those data.
Moreover, it would bring more legal certainty if the future RTS states that if strong authentication is an absolute necessity to initiate electronic payments or to carry out actions which may imply a risk of payment fraud or other abuses, the same level of requirements should not apply for accessing read-only-data. Requiring strong authentication processes to access to read-only-data will not only bring no added value in terms of security/consumers protection but it will also impede the development of AIS used by customers on a voluntary basis and with their consent regarding data collection and treatment, in order to be informed about their financial activity.
In order to bring more certainty, AIS players ask the EBA to clearly indicate that data related only to money activities which cannot be used to initiate a payment, are not considered as sensitive payment data and would therefore not require strong authentication. EBA could clearly indicate that data related to transactions on bank account: balances, rates, international securities identification numbers, debit cards, credit cards, current accounts, credits accounts, loans, mortgages, savings accounts, life insurance, trading accounts (…) should not require strong authentication processes. The mentioned transactions should not be interpreted as an exhaustive list. The idea is that all the data accessible by the user from the bank website or the bank applications should be accessible without discrimination by AIS in order for them to fulfill their missions as the user initially requested when calling for AIS services.
Last but not least, future RTS should also clarify that AIS players can store the credentials. Those credentials should be identical to those used to consult online accounts. In order to fulfil their services expected by their customers, AIS should be granted the same access, the same credentials and the same accessibility that our customers have when they want to view their account online. There should not be any discrimination or connecting differences or personalized access for AIS. Once again, our business model relies on our customers’ consent to access their data in order to keep them informed about their personal finances.
This would bring clarity for AIS and would be fully aligned with PSD2 principles.
RTS may specify that security measures should be implemented by AIS to protect users credentials during transit and at rest. AIS players have already implemented systems that ensure a high level of security to protect users credentials. We can provide more information on those systems upon request by the EBA.
The table below indicates the data collected by AIS, the frequency of the collection, the finality of the data treatment and the data’s recipients. Since PSD2 requires basing the exemption on the level of risks, AIS players highlight the risks associated. This table provides an accurate overview of the low level of risk in the access and use of banking data by AIS. AIS players are at the EBA disposal to provide any clarification of the elements provided. The table below should not be interpreted as an exhaustive list, nor should it be interpreted that all AIS retrieve the same transactions or with the same level of detail.
DATA COLLECTED BY AIS
Banking data
Current accounts / Savings accounts
• Account name; Historical Balance ; Opening date ; Currency ; Transactions
Card Account
• Account name ; Historical Balance ; Opening date ; Expiration date ; Currency ; Withdrawal limits ; Ceilings payment ; Transactions
Trading Accounts / PEA / Life Insurance
• Account name ; Balance ; Historical balances ; Opening date ; Rate ; Payments ; Withdrawals ; Currency ; Securities
Securities (as part of a PEA / trading account)
• Type of shares ; Number of shares purchased / sold ; Capital gains ;
Accounts Loans / Loans
• Nature of the loan ; Amount borrowed ; Duration ; Starting date ; End date ; Rate ; Amount remaining due ; Amount reimbursed ; Amount of the next deadline ; Date of the next deadline ; Periodicity ; Amount of the last payment ; Date of the last payment ; Loan repays
Deadlines (within a credit)
• Due dates ; Amount deadlines ; Remaining amounts due ; Amounts reimbursed ; Different dates / deadlines linked to contracts
Transactions
• Wording ; Amount ; Debit / Credit ; Category ; Value date ; Date of transaction ; Location ; All data provided by cards payment providers
FREQUENCY OF THE ACCESS TO THE DATA
To provide their services in a useful manner for their customers, AIS players need to access their data several times per day.
They also need real-time access to the newest data.
FINALITY OF THE DATA TREATMENT & RECIPIENTS OF THE DATA
With the data collected, AIS provide services and advices through internet providers towards the final user:
- User’s aggregated information in AIS apps.
- Alerts sent by emails, sms, push, in-app based on banking data (unusual transactions, alert about the thresholds …)
- Analysis of the user’s banking data in AIS apps
- Possibility for the user to manage the budget
- Forecasting services
- Innovative Personal Finance Management Functionality only for the final users
- Financial advices based on the data which can be provided by the AIS if they are authorized to do so by the customers
In terms of advertising, no banking information is communicated to third part without the explicit consent of the user.
Data or aggregated elements are communicated to third parties only when the customer explicitly asks for it. The future data protection regulation will provide the right framework. There is no need to overregulate.
Without the explicit consent of the user, only anonymized market studies (buying behaviors, evolution of the consumption …) are forwarded to third parties.
Companies using AIS services in Software As A Service (SAAS) for their customers with their explicit consent (example banks or accountant)
Regarding the data recipients, internet providers don’t have access to data linked with the user’s accounts. Those data are encrypted in all communications among devices.
RISKS ASSOCIATED
In read-only access there is no risk of fraud or of money transfer: no account could be cleaned out.
There is always a risk when you have access to online data. Most AIS are already audited by third parties mandated by banks (audit companies specialized in computer security). We have to comply with significant requirements. Moreover, we have to respect various procedures to ensure that no data is wrongly used.
There are several elements developed by AIS to mitigate risks:
- Most AIS players use already technical providers which respect security norms such as ISO/IEC 27001 and strong security standards.
- AIS employees don’t have access to users’ data – unless for the strict and legitimate need to fulfill their work.
- Third parts can’t have access to non-anonymized data unless the user explicitly asks for it.
DATA COLLECTED BY AIS
Personal data
• Civility, Name, First name, Sex, Age, Address, Date of birth, E-mail, Phone number, Tax declaration or tax bill, Sheet salaries
Those data are not comprehensive. The principle should be that any data accessible to the user from the bank website or its apps must be accessible by AIS without discrimination.
FINALITY OF THE DATA TREATMENT & RECIPIENTS OF THE DATA
Provision of AIS services (as described above) asked by the user who owns the data
Pre-fills forms on behalf of the user
Security in the user's interest
Anonymized market studies for third parties
DATA COLLECTED BY AIS
Data connections
Online banking credentials for access to read-only data
FINALITY OF THE DATA TREATMENT & RECIPIENTS OF THE DATA
AIS players need the access to the same online banking credentials in order to fulfill their services and inform their users:
To serve their customers (information and advices based on aggregated data), AIS players need a real-time data access and the access to the same information that the end user without discrimination
RISKS ASSOCIATED
Most banks have already developed different accesses according to the associated risks:
- Simple authentication for read-only access (balance, transactions…)
- Strong authentication for access allowing money transfers / payments and access to sensitive data
AIS players need to access information via the bank's website, API, and any other reliable protocol established by the banks. Banks are ultimately in charge of insuring the security of the access they provide according to the final use.
AIS players invite the EBA to require that every bank in Europe, develop internal processes to ensure that even with the PSCs of AIS users, it will not be possible to make an unwanted or fraudulent use, to access to sensitive data or to initiate fraudulent payments.
a) Regarding the definition of what makes a standard “common” and “open”, AIS players invite the EBA to ensure that the same information will be accessible from the different banks in Europe. Moreover, the information format should be the same across Europe and information should be updated in real time, or at least with the same frequency as the bank application for its own customers. Data should be accessible for AIS at all time. An open standard would mean that there is no constraint/limit for its use, no discrimination in the use and that it is royalty-free. To ensure that standards are common and open, there should be a sanction if banks fail to comply with the standards. An alternative solution would be for AIS to be able to access the same system as banks do for their own online application.
b) Regarding the way AIS, PIS providers will have to identify themselves towards the ASPSPs, the most secure way would be through the IP address, message headers or a combination of both. Banks have already an obligation to track access to their website and they are doing so through the IP address. With this solution, banks will be able to trace the history of each access by AIS. This solution generates no cost, is fully operational and has proved its efficiency. As we said, the RTS should rely on existing solutions and not necessarily invent new system that can be costly, especially for start-ups. To enhance security, the EBA could deliver a certificate to trusted third parties that comply with high level security standards. This certificate would be based on IP address, message headers or a combination of both, allowing banks to identify AIS and to monitor them.
c) Regarding the way AIS, PIS and ASPSPs communicate between themselves and with the PSUs in a secure manner, AIS players invite the EBA to consider how they are currently functioning. Today, AIS connect through the usual application / website of the user to aggregate his information. Connecting through the official website of the banks is the most effective and secured way to get updated, valid and accessible information that are necessary for the AIS to provide our services. We used official APIs of Banks and the experience was terrible: the API could not handle all of our users (too much users for their API), the API was never up-to-date (information was older than on their website, or sometime missing), there were errors on the information returned by the API ... The problem when we do not use the « official website » of the Bank is that when there are errors, the user (our customer) thinks this is the AIS fault. The bank is not impacted by those errors, slowness or unavailability. Therefore, they have little incentive to fix the error or provide updated information. This is why this is important for AIS to have the exact same source of information as the Bank does. If AIS and Banks cannot use the same source of information, it is important that AIS keep the right to connect to the official website, to access the most reliable information. There is no justification in terms of security or data protection or anything else that would prevent AIS to have the same access to our customers’ financial data as the bank website or own application.
d) Regarding the minimum functionalities requirements that the future common and secure open standards of communication will have to provide, AIS players share the view that all communication must be encrypted. No clear communication should be allowed in order to create a secure environment. At the same time, the same read-only credentials should be used between the AIS and the Banks’ applications/websites. As we have already insisted on, payments orders should require strong authentication.
e) Regarding the minimum technical requirements that could apply to the common and secure open standards of communication, the minimum reachability requirements for each ASPSPs, AIS players invite the EBA to consider the following elements:
Firstly, in order to foster innovation for the benefit of consumers, a single set of read-only identifier should be used, without distinction between AIS applications and banks applications. These identifiers must be secure and allow exclusively a read-only access (of course strong authentication is required to initiate payment). This is the system currently in place and there is no evidence that it is non-efficient to ensure a secure environment.
Secondly, access to data must be reactive. It would not be normal to have a faster access to data from the bank website or application than the one granted via the standard of communication. In case this situation occurs, AIS should be granted the right to connect via the site or bank applications to access read-only data.
Third, access to data must be as comprehensive as on the banks’ website or application. It would not be normal that AIS have access to less information than that offered to customers on the bank’s website, otherwise our service will be pointless for them. In case this situation occurs, AIS should be allowed to connect via the website or the bank applications to access read-only data.
Fourth, the connecting availability through the standard must be at least as high as the one for bank applications or websites. It would not be normal that the user can access the data via his bank’s website but not via his AIS. In case this situation occurs, AIS should be allowed to connect via the website or the bank applications to access read-only data.
Finally, the standard must provide access to updated information in real time. It would not be normal that the user can access more recent information via his bank website than via its AIS. In case this situation occurs, AIS should be allowed to connect via the website or the bank applications to access read-only data.
It would be particularly unfair to let AIS business model totally in the hand of banks, as it would be naive to believe they will always provide the highest standard to ease or even allow AIS access. For instance, some AIS have worked with banks, via their APIs and they had to back down because those APIs were not updated, access was sometimes blocked and they were too slow. To enable AIS to always innovate, today and in the future, RTS should create the framework allowing them to aggregate data directly via the user’s bank website. This would mitigate the risk of poor implementation of the standard by banks. This would also provide a solution if the standard did not forecast situations, preventing AIS to properly aggregate data to which today, they have access to, thanks to their technologies.
Therefore, the future RTS should stipulate the right for AIS to keep their technology, in order to be able to provide their service even in case the standard is badly functioning. Moreover, as technology is moving very fast, the future RTS should impose on banks a strict obligation to maintain and upgrade the standard. A fast track alert could also be developed allowing AIS to complain about deficient standard and creating an obligation on banks to fix the problem, as they would do for their own website or application.
1/ There should be no discrimination in terms of accessible data on the bank website and for AIS
2/ Same data should be available for a bank customer accessing his bank website as well as for a bank customer accessing information through an AIS. If the bank publishes data through distinct interfaces, new data should be made available at the same time on all interfaces. There should be no discrimination in terms of updating data and information between bank website and AIS
3/ The future RTS should clearly impose an obligation on banks and AIS to cooperate.
4/ New fee should not be imposed to access banks interfaces by AIS.
AIS players are willing to work with the EBA to define the requirements allowing them to become qualified trust services, as it would benefit our ecosystem and accelerate our development at European level.
However special care has to be taken to ensure that unproven or problematic technologies are rolled out to the market and imposed as a security measure for AIS. As proven in other areas such as electronic invoicing, security based in electronic certificates can be extremely problematic, as it brings many compatibility issues, is not supported in many hardware and software devices, or different versions are supported.
1. With respect to Article 97(1) (c), are there any additional examples of transactions or actions implying a risk of payment fraud or other abuses that would need to be considered for the RTS? If so, please give details and explain the risks involved.
INTRODUCTIONAIS players welcome the publication of the EBA’s Discussion paper as part of the Regulatory Technical Standards for the Payment Services Directive (PSD2) and we appreciate the opportunity to contribute to their drafting, in order to ensure a level playing field among all actors.
In the context of the future Regulatory Technical Standards on strong customer authentication and secure communication under the revised Payment Services Directive, AIS European players call for a balanced approach between the necessity to enhance consumer protection and the security of payment on one hand, and consumer’s wishes to benefit from innovative, easily accessible services on the other. This is perfectly coherent with the two main purposes of the Directive: improving consumer protection and promoting competition through a regulatory framework that allows new services such as Account Information Services. Therefore, we welcome the possibility given by the EBA, through this discussion paper, to contribute to the future technical standards and we call the EBA to consider our position.
AIS European players urge the EBA to implement in the technical standards, the following principles:
• Effective and risk-based requirements Taking into account the fundamental differences in terms of risks between Payment Service Providers (PSPs) and Account Information Services (AIS). As the latter are read-only services, AIS should not be regulated as if they were PSP, as the risks are different.
• Fair competition among all actors to encourage innovative, accessible and user friendly services
• Technology and business-model neutrality to stimulate future innovations.
• Banks should be in the first line to provide strong authentication processes as more people use their smartphones for managing their finances, but this should not be used as a mean to block AIS. In read-only access, banks should create user-friendly environments for their customers and AIS.
• Regulators should bear in mind that the digital development is moving at a very fast pace and adaptable regulation is key to provide a level playing field, especially for new services such as AIS. Future European innovations should not be limited.
• The finance sector is not limited to the EU and its e-security agenda. The EBA should take into account that the stakes are worldwide. Yet today most of the innovations come from the United States. European players should be enabled to innovate thanks to an adequate framework.
We would like to highlight that the provisions of the future RTS should not prevent AIS to develop new innovative services and their capacity to also provide Payment Initiation Services (PIS). Thus PIS and AIS would be provided by the same companies and integrated as one service. Hence it is very important that the authentication systems are designed to facilitate a smooth user experience through integrated authentication processes, when using these combined services. Obviously in this case, AIS will fully comply with the regulation drafted for PIS.
Last but not least, AIS players would like to highlight that many innovations are driven by very small companies and start-ups, which come to the market with services meeting European consumers’ needs and expectations regarding financial services. Therefore, the future RTS should create a secure environment for financial services without imposing administrative burdens or overtly complicated measures that could kill future innovations. RTS should avoid imposing requirement on AIS to make significant investments in technical infrastructure.
It is a difficult exercise to forecast future innovation given the continued increase in the digitalization of financial services. AIS players are in an ongoing development process to better understand the customers’ needs and expectations. We call the EBA not to lock this process at the heart of our business model and of our customers’ relations. Future RTS should be as clear as possible and create opportunities while developing adequate security requirements.
All questions are not relevant for AIS. Therefore, we concentrate our answers on the ones with decisive impact on our activity.
2. Which examples of possession elements do you consider as appropriate to be used in the context of strong customer authentication, must these have a physical form or can they be data? If so, can you provide details on how it can be ensured that these data can only be controlled by the PSU?
Possession elements bring additional security and maybe desirable for strong authentication. However, the requirement to have a possession element has to be either valid for any user or have an alternative. If these are used, there has to be an alternative for the visually impaired, those who do not have a smartphone or those who do not have a smartphone with a particular technology. At this point in time, we consider a combination of something the user knows i.e. a user Id and password combination with something the user has, a mobile phone with SMS to be sufficient. As technology evolves and becomes pervasive, other technologies such as biometric identification might present a valid alternative.3. Do you consider that in the context of “inherence” elements, behaviour-based characteristics are appropriate to be used in the context of strong customer authentication? If so, can you specify under which conditions?
AIS players are not in favor of using inherence elements as primary authentication factors for strong authentication in the standards being developed. Common examples of inherence elements such as fingerprints, voiceprints, retinal patterns and other biometric data does not add any additional security to other knowledge and ownership factors, as they can be copied and replay, but not revoked. However, using inherence elements as a tool to simplify the user-experience of a strong authentication process; for example to unlock a protected ownership factor, in the form of a public key certificate on the user’s mobile device, is fine, as long as the inherence element is not used as a primary authentication factor.4. Which challenges do you identify for fulfilling the objectives of strong customer authentication with respect to the independence of the authentication elements used (e.g. for mobile devices)?
In our opinion, the main challenge will be to adopt a balanced approach between the level of constraints on the user to enhance protection, the need for a user friendly environment and cost. By no means should an ad-hoc physical device be imposed on the consumer, such as a crypto-calculator, be it a hardware device or a software device hosted in a smart-phone. In addition, there should always be alternatives to make strong authentication universal.7. Do you consider the clarifications suggested regarding the potential exemptions to strong customer authentication, to be useful?
AIS players share the principle written in PSD2 linking strong customer authentication with the level of risk involved in the service provided or the payment channel used for the execution of the transaction.Recital 96 of the Directive provides that “the security measures should be compatible with the level of risk involved in the payment service. In order to allow the development of user-friendly and accessible means of payment for low-risk payments, (…), the exemptions to the application of security requirements should be specified in regulatory technical standards. This is even more applicable for AIS, which are read-only services. This means that no money is moved from one account to another by the AIS, there is indeed no transaction. This proportionality principle should be clearly enhanced in the future RTS.
Therefore, AIS players welcome the opening towards the application of the exemptions to “purely consultative services, with no display of sensitive payment data, taking into account data privacy laws”. This would indeed acknowledge the specific nature of AIS.
Nevertheless, the devil is in the details and different approaches to the notion of “sensitive payment data” could have different impacts on AIS ability to provide accessible and user’s friendly services. AIS players share the definition given by the directive on “sensitive payment data” but we also invite the EBA to stipulate that data linked to the financial activity are not sensitive data in the sense of the directive, if the customer gives his consent to the AIS for accessing and treating those data.
Moreover, it would bring more legal certainty if the future RTS states that if strong authentication is an absolute necessity to initiate electronic payments or to carry out actions which may imply a risk of payment fraud or other abuses, the same level of requirements should not apply for accessing read-only-data. Requiring strong authentication processes to access to read-only-data will not only bring no added value in terms of security/consumers protection but it will also impede the development of AIS used by customers on a voluntary basis and with their consent regarding data collection and treatment, in order to be informed about their financial activity.
In order to bring more certainty, AIS players ask the EBA to clearly indicate that data related only to money activities which cannot be used to initiate a payment, are not considered as sensitive payment data and would therefore not require strong authentication. EBA could clearly indicate that data related to transactions on bank account: balances, rates, international securities identification numbers, debit cards, credit cards, current accounts, credits accounts, loans, mortgages, savings accounts, life insurance, trading accounts (…) should not require strong authentication processes. The mentioned transactions should not be interpreted as an exhaustive list. The idea is that all the data accessible by the user from the bank website or the bank applications should be accessible without discrimination by AIS in order for them to fulfill their missions as the user initially requested when calling for AIS services.
Last but not least, future RTS should also clarify that AIS players can store the credentials. Those credentials should be identical to those used to consult online accounts. In order to fulfil their services expected by their customers, AIS should be granted the same access, the same credentials and the same accessibility that our customers have when they want to view their account online. There should not be any discrimination or connecting differences or personalized access for AIS. Once again, our business model relies on our customers’ consent to access their data in order to keep them informed about their personal finances.
This would bring clarity for AIS and would be fully aligned with PSD2 principles.
RTS may specify that security measures should be implemented by AIS to protect users credentials during transit and at rest. AIS players have already implemented systems that ensure a high level of security to protect users credentials. We can provide more information on those systems upon request by the EBA.
The table below indicates the data collected by AIS, the frequency of the collection, the finality of the data treatment and the data’s recipients. Since PSD2 requires basing the exemption on the level of risks, AIS players highlight the risks associated. This table provides an accurate overview of the low level of risk in the access and use of banking data by AIS. AIS players are at the EBA disposal to provide any clarification of the elements provided. The table below should not be interpreted as an exhaustive list, nor should it be interpreted that all AIS retrieve the same transactions or with the same level of detail.
DATA COLLECTED BY AIS
Banking data
Current accounts / Savings accounts
• Account name; Historical Balance ; Opening date ; Currency ; Transactions
Card Account
• Account name ; Historical Balance ; Opening date ; Expiration date ; Currency ; Withdrawal limits ; Ceilings payment ; Transactions
Trading Accounts / PEA / Life Insurance
• Account name ; Balance ; Historical balances ; Opening date ; Rate ; Payments ; Withdrawals ; Currency ; Securities
Securities (as part of a PEA / trading account)
• Type of shares ; Number of shares purchased / sold ; Capital gains ;
Accounts Loans / Loans
• Nature of the loan ; Amount borrowed ; Duration ; Starting date ; End date ; Rate ; Amount remaining due ; Amount reimbursed ; Amount of the next deadline ; Date of the next deadline ; Periodicity ; Amount of the last payment ; Date of the last payment ; Loan repays
Deadlines (within a credit)
• Due dates ; Amount deadlines ; Remaining amounts due ; Amounts reimbursed ; Different dates / deadlines linked to contracts
Transactions
• Wording ; Amount ; Debit / Credit ; Category ; Value date ; Date of transaction ; Location ; All data provided by cards payment providers
FREQUENCY OF THE ACCESS TO THE DATA
To provide their services in a useful manner for their customers, AIS players need to access their data several times per day.
They also need real-time access to the newest data.
FINALITY OF THE DATA TREATMENT & RECIPIENTS OF THE DATA
With the data collected, AIS provide services and advices through internet providers towards the final user:
- User’s aggregated information in AIS apps.
- Alerts sent by emails, sms, push, in-app based on banking data (unusual transactions, alert about the thresholds …)
- Analysis of the user’s banking data in AIS apps
- Possibility for the user to manage the budget
- Forecasting services
- Innovative Personal Finance Management Functionality only for the final users
- Financial advices based on the data which can be provided by the AIS if they are authorized to do so by the customers
In terms of advertising, no banking information is communicated to third part without the explicit consent of the user.
Data or aggregated elements are communicated to third parties only when the customer explicitly asks for it. The future data protection regulation will provide the right framework. There is no need to overregulate.
Without the explicit consent of the user, only anonymized market studies (buying behaviors, evolution of the consumption …) are forwarded to third parties.
Companies using AIS services in Software As A Service (SAAS) for their customers with their explicit consent (example banks or accountant)
Regarding the data recipients, internet providers don’t have access to data linked with the user’s accounts. Those data are encrypted in all communications among devices.
RISKS ASSOCIATED
In read-only access there is no risk of fraud or of money transfer: no account could be cleaned out.
There is always a risk when you have access to online data. Most AIS are already audited by third parties mandated by banks (audit companies specialized in computer security). We have to comply with significant requirements. Moreover, we have to respect various procedures to ensure that no data is wrongly used.
There are several elements developed by AIS to mitigate risks:
- Most AIS players use already technical providers which respect security norms such as ISO/IEC 27001 and strong security standards.
- AIS employees don’t have access to users’ data – unless for the strict and legitimate need to fulfill their work.
- Third parts can’t have access to non-anonymized data unless the user explicitly asks for it.
DATA COLLECTED BY AIS
Personal data
• Civility, Name, First name, Sex, Age, Address, Date of birth, E-mail, Phone number, Tax declaration or tax bill, Sheet salaries
Those data are not comprehensive. The principle should be that any data accessible to the user from the bank website or its apps must be accessible by AIS without discrimination.
FINALITY OF THE DATA TREATMENT & RECIPIENTS OF THE DATA
Provision of AIS services (as described above) asked by the user who owns the data
Pre-fills forms on behalf of the user
Security in the user's interest
Anonymized market studies for third parties
DATA COLLECTED BY AIS
Data connections
Online banking credentials for access to read-only data
FINALITY OF THE DATA TREATMENT & RECIPIENTS OF THE DATA
AIS players need the access to the same online banking credentials in order to fulfill their services and inform their users:
To serve their customers (information and advices based on aggregated data), AIS players need a real-time data access and the access to the same information that the end user without discrimination
RISKS ASSOCIATED
Most banks have already developed different accesses according to the associated risks:
- Simple authentication for read-only access (balance, transactions…)
- Strong authentication for access allowing money transfers / payments and access to sensitive data
AIS players need to access information via the bank's website, API, and any other reliable protocol established by the banks. Banks are ultimately in charge of insuring the security of the access they provide according to the final use.
8. Are there any other factors the EBA should consider when deciding on the exemptions applicable to the forthcoming regulatory technical standards?
AIS players invite the EBA to consider the way banks are currently dealing with security issues while offering user friendly services for their customers, for read-only data. For many years now banks have answered to their customer needs for a user friendly online access to their financial data disregarding the device used. On the other hand, they also meet the safety concerns by requiring strong authentication for money transfers or the creation of new beneficiaries. Risks are already mitigated by banks. This is a fact that the EBA should keep in mind. EBA responsibility would be therefore to verify that there are two levels of authentication for accessing online bank accounts. The environment would require a simple authentication for read-only services and a strong authentication whenever it is possible to initiate a payment. This model is already used by banks in several countries and such model could inspire the EBA as best practices.10. Do you consider the clarification suggested regarding the protection of users personalised security credentials to be useful?
AIS players welcome the clarifications suggested by the discussion Paper and especially the idea that the security measures to protect the confidentiality and the integrity of the payment service users’ personalised security credentials, should be proportionate to the risks related to a fraudulent use of the PSCs to carry out fraud or to access sensitive payment data. Once again this acknowledges the fundamental difference between AIS and PSP in the use of the PSU’s data and the execution of operations (read-only services versus initiation of payments).AIS players invite the EBA to require that every bank in Europe, develop internal processes to ensure that even with the PSCs of AIS users, it will not be possible to make an unwanted or fraudulent use, to access to sensitive data or to initiate fraudulent payments.
15. For each of the topics identified under paragraph 63 above (a to f), do you consider the clarifications provided to be comprehensive and suitable? If not, why not?
AIS players understand that the future RTS will have to balance between several competing demands, in an area driven by ongoing innovations and diverging interests among the parties involved. Therefore, we strongly support the clarifications that the EBA will provide. We call the EBA to adopt a cautious approach in order to avoid solutions that could become a barrier for AIS to provide their services. Moreover, the EBA should ensure a good fluidity, easy-operation for customers.16. For each agreed clarification suggested above on which you agree, what should they contain in your view in order to achieve an appropriate balance between harmonisation, innovation while preventing too divergent practical implementations by ASPSPs of the future requirements?
AIS players welcome the clarifications that the EBA will provide to enhance legal certainty. In doing so, we urge the EBA to adopt a technologically neutral approach. If the ideal of a common standard is an appealing idea, it is also practically difficult to implement. Yet, the EBA rightly points out the need to ensure a certain level of convergence in the practical implementation of the requirements. Therefore, AIS players would like to highlight the following elements:a) Regarding the definition of what makes a standard “common” and “open”, AIS players invite the EBA to ensure that the same information will be accessible from the different banks in Europe. Moreover, the information format should be the same across Europe and information should be updated in real time, or at least with the same frequency as the bank application for its own customers. Data should be accessible for AIS at all time. An open standard would mean that there is no constraint/limit for its use, no discrimination in the use and that it is royalty-free. To ensure that standards are common and open, there should be a sanction if banks fail to comply with the standards. An alternative solution would be for AIS to be able to access the same system as banks do for their own online application.
b) Regarding the way AIS, PIS providers will have to identify themselves towards the ASPSPs, the most secure way would be through the IP address, message headers or a combination of both. Banks have already an obligation to track access to their website and they are doing so through the IP address. With this solution, banks will be able to trace the history of each access by AIS. This solution generates no cost, is fully operational and has proved its efficiency. As we said, the RTS should rely on existing solutions and not necessarily invent new system that can be costly, especially for start-ups. To enhance security, the EBA could deliver a certificate to trusted third parties that comply with high level security standards. This certificate would be based on IP address, message headers or a combination of both, allowing banks to identify AIS and to monitor them.
c) Regarding the way AIS, PIS and ASPSPs communicate between themselves and with the PSUs in a secure manner, AIS players invite the EBA to consider how they are currently functioning. Today, AIS connect through the usual application / website of the user to aggregate his information. Connecting through the official website of the banks is the most effective and secured way to get updated, valid and accessible information that are necessary for the AIS to provide our services. We used official APIs of Banks and the experience was terrible: the API could not handle all of our users (too much users for their API), the API was never up-to-date (information was older than on their website, or sometime missing), there were errors on the information returned by the API ... The problem when we do not use the « official website » of the Bank is that when there are errors, the user (our customer) thinks this is the AIS fault. The bank is not impacted by those errors, slowness or unavailability. Therefore, they have little incentive to fix the error or provide updated information. This is why this is important for AIS to have the exact same source of information as the Bank does. If AIS and Banks cannot use the same source of information, it is important that AIS keep the right to connect to the official website, to access the most reliable information. There is no justification in terms of security or data protection or anything else that would prevent AIS to have the same access to our customers’ financial data as the bank website or own application.
d) Regarding the minimum functionalities requirements that the future common and secure open standards of communication will have to provide, AIS players share the view that all communication must be encrypted. No clear communication should be allowed in order to create a secure environment. At the same time, the same read-only credentials should be used between the AIS and the Banks’ applications/websites. As we have already insisted on, payments orders should require strong authentication.
e) Regarding the minimum technical requirements that could apply to the common and secure open standards of communication, the minimum reachability requirements for each ASPSPs, AIS players invite the EBA to consider the following elements:
Firstly, in order to foster innovation for the benefit of consumers, a single set of read-only identifier should be used, without distinction between AIS applications and banks applications. These identifiers must be secure and allow exclusively a read-only access (of course strong authentication is required to initiate payment). This is the system currently in place and there is no evidence that it is non-efficient to ensure a secure environment.
Secondly, access to data must be reactive. It would not be normal to have a faster access to data from the bank website or application than the one granted via the standard of communication. In case this situation occurs, AIS should be granted the right to connect via the site or bank applications to access read-only data.
Third, access to data must be as comprehensive as on the banks’ website or application. It would not be normal that AIS have access to less information than that offered to customers on the bank’s website, otherwise our service will be pointless for them. In case this situation occurs, AIS should be allowed to connect via the website or the bank applications to access read-only data.
Fourth, the connecting availability through the standard must be at least as high as the one for bank applications or websites. It would not be normal that the user can access the data via his bank’s website but not via his AIS. In case this situation occurs, AIS should be allowed to connect via the website or the bank applications to access read-only data.
Finally, the standard must provide access to updated information in real time. It would not be normal that the user can access more recent information via his bank website than via its AIS. In case this situation occurs, AIS should be allowed to connect via the website or the bank applications to access read-only data.
It would be particularly unfair to let AIS business model totally in the hand of banks, as it would be naive to believe they will always provide the highest standard to ease or even allow AIS access. For instance, some AIS have worked with banks, via their APIs and they had to back down because those APIs were not updated, access was sometimes blocked and they were too slow. To enable AIS to always innovate, today and in the future, RTS should create the framework allowing them to aggregate data directly via the user’s bank website. This would mitigate the risk of poor implementation of the standard by banks. This would also provide a solution if the standard did not forecast situations, preventing AIS to properly aggregate data to which today, they have access to, thanks to their technologies.
Therefore, the future RTS should stipulate the right for AIS to keep their technology, in order to be able to provide their service even in case the standard is badly functioning. Moreover, as technology is moving very fast, the future RTS should impose on banks a strict obligation to maintain and upgrade the standard. A fast track alert could also be developed allowing AIS to complain about deficient standard and creating an obligation on banks to fix the problem, as they would do for their own website or application.
18. How would these requirement for common and open standards need to be designed and maintained to ensure that these are able to securely integrate other innovative business models than the one explicitly mentioned under article 66 and 67 (e.g. issuing of own credentials by the AIS/PIS)?
AIS players fully support the EBA initiative. Article 67 already provides useful requirements. In order to securely integrate new innovative business models (some of them being still unknown for the time being), AIS players urge the EBA to respect the following principles:1/ There should be no discrimination in terms of accessible data on the bank website and for AIS
2/ Same data should be available for a bank customer accessing his bank website as well as for a bank customer accessing information through an AIS. If the bank publishes data through distinct interfaces, new data should be made available at the same time on all interfaces. There should be no discrimination in terms of updating data and information between bank website and AIS
3/ The future RTS should clearly impose an obligation on banks and AIS to cooperate.
4/ New fee should not be imposed to access banks interfaces by AIS.
19. Do you agree that the e-IDAS regulation could be considered as a possible solution for facilitating the strong customer authentication, protecting the confidentiality and the integrity of the payment service users’ personalised security credentials as well as for common and secure open standards of communication for the purpose of identification, DP on future RTS on strong customer and secure communication under PSD2 31 authentication, notification, and information? If yes, please explain how. If no, please explain why.
AIS players support the use by the EBA of the e-IDAS regulation as a good basis for future work. AIS players are willing to contribute efficiently to assess how this regulation could bring solutions, as long as they are pragmatic, with no cost (or a reasonable one). The real challenge will be to ensure that new barriers are not created by traditional actors.AIS players are willing to work with the EBA to define the requirements allowing them to become qualified trust services, as it would benefit our ecosystem and accelerate our development at European level.
However special care has to be taken to ensure that unproven or problematic technologies are rolled out to the market and imposed as a security measure for AIS. As proven in other areas such as electronic invoicing, security based in electronic certificates can be extremely problematic, as it brings many compatibility issues, is not supported in many hardware and software devices, or different versions are supported.