Eurobits Technologies

About Eurobits Technologies and our AIS
Eurobits has been offering AIS for well over 12 years, being the pioneer in offering such services in the EU. We work together with some of the major EU ASPSP and services companies that provide consumers AIS with a variety of value added services (PFM, Portfolio Management, Financial Management and Planning for adults on guardianship and Accounting and Treasury services for SMBs). Eurobits account aggregation service can obtain information on behalf of the end user on several ways, depending on the bank being accessed and the degree of collaboration between Eurobits and the bank, they are as follows:
• Via an API agreed between Eurobits and the bank. The bank publishes an API that is securely accessed by Eurobits using the regular end user credentials.
• Via agreed access to electronic banking JSON of XML files through the public banking URLs via the use of special parameters.
• Via HTTP Get and Post requests to the public banking site with or without collaboration from the bank.
In addition to an API or a special access, there are several ways in which Eurobits collaborates with the target bank, for example:
• Agreed IP addresses to avoid unnecessary alerts from network devices.
• Agreed HTTP headers to help identify the robot.
• Batch aggregation windows to avoid the creation of bottlenecks in peak hours.
• Access to pre-production environments in order to fine tune the robots before they are staged into production.
Eurobits hasn’t had a single security breach in the last 12 years and the account information service has passed the strictest security requirements of some of the top Euro Zone banks as well as being inspected on-site by many of them. The most notable security features of the service are the following:
• Secure communications: Eurobits only uses proven secure communication channels and mechanisms, such as point to point networks, VPNs and HTTPS connections using TLS.
• Read-only credentials: Eurobits does not use credentials other than read only credentials.
• Non-storage of credentials: Eurobits does not store the end user credentials;
• Non-storage of customer data: Eurobits does not store end user data other than the user id on Eurobits customer’s system for billing purposes. It is required that this user id does not identify the real end user.
• Asymmetric cryptography option: Eurobits offers its customer the possibility of using asymmetric cryptography to safeguard the end user credentials. What this effectively means is that the credentials are never accessible except by Eurobits software in memory during runtime.
General remarks on the consultation:
In terms of Account Information Services (AIS) and Account Information Service Providers (AISP) the following has to be noted. The AISP is the provider that gives AIS to the PSU. The AISP can be independent from the ASPSP hosting the payment accounts, or it can be a service provided by the ASPSP. The electronic banking provided by an ASPSP (“direct online access to payment accounts” in the RTS) is an AISP for all purposes of PSD2 and for all purposes of the RTS. Consequently, in order to fulfil the neutrality and level playing field aimed by PSD2, all measures imposed to AISP have to be fulfilled by both independent AISP and by the AIS provided by an ASPSP. So for all the questions we will keep in mind that the provisions proposed have to be neutral and provide a level playing field between independent AISP and AIS provided by the ASPSP which is the purpose of PSD2 in regards to AIS. Any provisions that do not guarantee neutrality or a level playing field, now or in the future, must be amended in the shortest possible time since they are identified.
In that respect, it should be noted the fact that certain payment information is available to the PSU from direct online access to the payment accounts (the AIS of the ASPSP) that is not available when the PSU access his information via an independent AIS is clearly against the principle of neutrality and does not provide a level playing field between independent AIS and direct online access to the payment accounts (the AIS of the ASPSP). Furthermore, per the European Data Protection Directive the data is owned by the PSU and he is free to decide with whom to share it. The contrary would jeopardize this directive and limit the portability of data.
Also, it should be noted that the AISP is the provider that gives AIS to the PSU. The AISP can be independent from the ASPSP hosting the payment accounts, or it can be a service provided by the ASPSP. The electronic banking provided by an ASPSP (“direct online access to payment accounts” in the RTS) is an AISP for all purposes of PSD2 and for all purposes of the RTS. Consequently, to fulfil the neutrality and level playing field aimed by PSD2, all measures imposed to AISP must be fulfilled by both independent AISP and by the AIS provided by an ASPSP.
The exact same restrictions should apply to both:
• Same PSC. That is, the same user id and password for the ASPSP AIS (the electronic banking) than for any independent AIS. This would impede other passwords being revoked while the online banking can be accessed. In other words, if the credentials are revoked, they are revoked for everyone.
• Same restrictions. That is, if there are only two daily access (or whatever number may finally come out), then there is one counter. If the PSU accesses his payment account twice through an independent AIS in the same day, then he will not be able to login to the electronic banking until tomorrow. If the access must go through a strong authentication the first time and then once every month, it must be for all AIS. Both independent AIS and ASPSP AIS (the electronic banking).
• Same information. Any information that is accessible through the AIS of the ASPSP (the electronic banking) is accessible through an independent AIS. Otherwise it would be against the Data Protection Directive. Any attempt by PSD2 to restrict PSU consumer rights to share his financial information or put difficulties in the way this information is accessed would not only put the business of AISP seriously at risk, it would also seriously affect the access of European Consumers to transparent information, unbiased advice and better and more competitive products.
• Same technology. If ISO 20022, ISO 27001 and eIDAS are imposed to AIS, then they are also imposed to ASPSP AIS (the electronic banking)
• Independence. To guarantee full independence, the ASPSP AIS must be one of the means available for independent AIS to access the PSU data. It is the only way to guarantee that the availability and the data that is available is the same for the ASPSP AIS (the electronic banking) and the independent AIS.
When answering this, and the following questions, we will keep in mind that the provisions proposed must be neutral and provide a level playing field between independent AISP and AIS provided by the ASPSP which is the purpose of PSD2 in regards to AIS. Any provisions that do not guarantee neutrality or a level playing field, now or in the future, must be amended in the shortest possible time since they are identified.
As we understand it, this chapter is not applicable to AISP as access to payment accounts through an AISP has to be exempt from strong customer authentication. What has to be required is that level 1 of the PSC (typically a user ID and password) gives read only access to payment accounts. If level 1 of the PSC gives read only access to payment accounts, there is no need for strong authentication for AIS. As stated in preamble (96) of the directive, “The security measures should be compatible with the level of risk involved in the payment service.” In this case the risk does not justify the use of strong customer authentication.
In any case, we understand that the only way to guarantee neutrality and a level playing field is that the PSC that give access to a given ASPSP are unique for the PSU independently of the AISP chosen for access. In other words, there is only one set of PSC for every PSU ASPSP combination. If this is not the case, it will be impossible to ensure that they receive the same treatment.
• Revocation thresholds: if the PSC are different it is impossible to guarantee that the revocation thresholds and treatment are the same for different sets of PSC as the ASPSP has vested interests in one of them.
• Reactivation procedures: if the PSC are different it is impossible to guarantee that the reactivation procedures and treatment are the same for different sets of PSC as the ASPSP has vested interests in one of them.
We partially agree with the reasoning.
a. The use of the term payer instead of the term Payment Service User is misleading. Payment Service User should be used instead.
b. It refers to access to payment accounts online in an unclear way. To all effects access to payment accounts online is an AIS, although it is provided directly by the ASPSP. The exemption should clearly include the access to payment accounts through an independent AISP whether it is initiated directly by the PSU or programmatically by the AISP, as there is no way for the ASPSP to distinguish between both. Otherwise it would be in violation of (21), (93) and (96) from the preamble and 98.2.d because it would not be a neutral measure and would not provide a level playing field between independent AISP and the AISP (electronic banking or PFM) of the ASPSP.
c. The term sensitive payment data requires further specification. The definition in PSD2 is ambiguous in that it is not exhaustive “(32) ‘sensitive payment data’ means data, including personalized security credentials which can be used to carry out fraud. For the activities of payment initiation service providers and account information service providers, the name of the account owner and the account number do not constitute sensitive payment data;”. For the purposes of RTS the definition of what is and what is not sensitive payment data should be more complete. In addition, any information that is provided by the direct online access to the payment accounts (the AIS of the ASPSP) should be fully accessible through independent AISP, otherwise the principle of neutrality and equivalent operating conditions would be violated. It has to be taken into account that the data ownership belongs to the PSU, and the RTS cannot limit its use or allow ASPSP to do so. Allowing such would go against the General Data Protection Regulation and the data portability principle.
d. In i. the exemption excludes the first access to the payment account. It should be specified that this first time access has to be independent of the access path. That is, it could be directly via the direct online access to the payment accounts (the AIS of the ASPSP) or indirectly via an independent AISP.
e. In ii. It is implied that there must be a strong authentication at least once every month. This is contrary to (96) which indicates that “The security measures should be compatible with the level of risk involved in the payment service.” In addition, currently ASPSP do not require this security measure for read only access to payment accounts, so it is surprising, that it is required in this RTS. Its admission would imply that currently electronic banking in Europe is not safe according to EBA for the majority of banks.” What has to be required, as indicated in the answer to question 1, is that PSC have a first level of read only access, which would deem unnecessary any strong authentication.
We agree that the personalised security credentials require an adequate level of protection. However, as chapter 3 is written only Article 9 is applicable to AIS, although this should be more explicit.
We agree that the use of a common and secure open standard is desirable for the purpose of identification, authentication, notification and information. However, we disagree on several of the resultant provisions proposed in chapter 4. Namely
a. Section 1. It is surprising that the section titled “General Requirements” has no general requirements that are applicable to AIS. This should need further clarification in order to bring certainty.
b. Section 2.19.1. It is said “Account servicing payment service providers that are offering to a payer a payment account that is accessible online shall offer at least one communication interface…”. It should be specified that in order to warrant the neutrality and a level playing field between independent AISP and the AIS of an ASPSP one of this interfaces has to be the direct online access to the payment accounts (the AIS of the ASPSP) with the same PSCs. The only difference should be that the communication requirements for authentication between independent AISP and the ASPSP are in place. This is the only practical way to ensure that the availability and the information that is accessible for the PSU is the same independently of the AIS chosen to access the payments information.
c. Section 2.19.1. (c) As noted above, the authentication process referred should use the same PSC for independent AISP as for direct online access to the payment accounts (the AIS of the ASPSP).
d. Section 2.19.3. ISO 20022 is not a widely recognized, accepted and mature standard and should not be used at this stage for the communication interface. However, if this is to be the final standard, then to respect and apply the principle of neutrality direct online access to the payment accounts (the AIS of the ASPSP) would have to connect to the ASPSP using the same standard in the same way as the communication interface must be the same.
e. Section 2.19.5. Determines a three-month period for publication of changes in communication technical specification before they are implemented. It is surprising that the procedure for emergency situations is specified before the standard procedure, where the change can be implemented without prior notification. It is required that:
• Legitimate emergency situations are listed and defined.
• A procedure for the notification of the emergency situation and the change in the technical specification for each emergency situation.
• As the direct online access to the payment accounts (the AIS of the ASPSP) should be one of the communications interface it can be used as a backup by AISP in case others are not available. In case the change in technical specification affects the communication channel, direct online access to the payment accounts (the AIS of the ASPSP), if available, can be used until the conditions are restored. Otherwise there would be no neutrality and no level playing field.
f. Section 2.19.6. It should be specified that independent AISP can monitor the service level of both the direct online access to the payment accounts (the AIS of the ASPSP) as well as the alternative communications interface made available by ASPSP. This is the only way to ensure the same level of service is provided in both interfaces.
g. Section 2.22.2. Further definition of “as short as possible” and “as soon as the requested action has been completed” is required. As defined, ASPSP could impose a fixed time limit for a session to be completed and consider the requested action has been completed with an error code that specifies that the time limit has been exceeded.
h. Section 2.22.1.(a) Specifies that ASPSP shall provide the same information to AIS via the proposed communication interface as is available to the PSU directly online. However, an exception is made to the information that displays sensitive payment data. It shall be noted:
• Unless “sensitive payment data” is exhaustively defined this is a potential loop hole that allows ASPSP to cherry-pick the information made available to independent AISP.
• The fact that certain payment information is available to the PSU from direct online access to the payment accounts (the AIS of the ASPSP) that is not available when the PSU access his information via an independent AIS is clearly against the principle of neutrality and does not provide a level playing field between independent AIS and direct online access to the payment accounts (the AIS of the ASPSP).
i. Section 2.22.2. It should be specified that the notification messages have to be properly documented and be exhaustive and provide sufficient level of detail as to be valuable in the tracking and resolution of errors.
j. Section 2.22.5.(a) Determines that AISP can request information any time the PSU is requesting such information. However, it does not define how it is determined if the request is performed directly by the PSU or not actively requested as in 2.22.5.(b). A way for the AIS, independent AIS in particular, to inform the ASPSP that the request has been performed directly by the PSU has to be defined, and it has to be trusted. Otherwise 2.22.5.(a) is void.
k. Section 2.22.5.(b) Establishes a limit of no more than 2 connections a day when the user is not actively requesting such information. This does not ensure neutrality and a level playing field between independent AIS and direct online access to the payment accounts (the AIS of the ASPSP) unless the limit is shared and applied between both. Furthermore, the limit is suggested regardless of the result of the information request, which means that even in case of failure in retrieving the data it still counts. Therefore, if there is going to a limitation to the number of attempts, then the RTS should read “successful “ connections.
ISO 20022 is not a widely recognized, accepted and mature standard and should not be used at this stage for the communication interface. However, it should be noted that if this was the final standard to be used, direct online access to the payment accounts (the AIS of the ASPSP) would have to connect to the ASPSP using the same standard in the same way as the communication interface has to be the same. Furthermore, adoption is still in its early stages within the financial sector as can be seen in
• https://www.iso20022.org/adoption.page and
• https://www.iso20022.org/documents/adoption/ISO20022_Adoption_mApp_Overview.pptx.
• https://www.iso20022.org/sites/default/files/documents/adoption/ISO20022_adoption_report.pdf
We agree on the use of website certificates issued by a qualified trust service provider for AIS authentication. However, eIDAS is not a mature standard and should not be used at this stage for the communication interface. However, it should be noted that if this was the final standard to be used, direct online access to the payment accounts (the AIS of the ASPSP) would have to connect to the ASPSP using the same standard in the same way as the communication interface must be the same.
Since it is not covered in any particular question we have included the following in the answer to this one, as it is where we see a closer relation. Article 221 6 requires that the processing and routing of personalised security credentials and authentication codes take place in secure environments in accordance with common security standards in compliance with ISO 27001. It must be noted that this requirement has to be complied when there is direct online access to the payment accounts (the AIS of the ASPSP).
There are several issues around this matter that require further analysis:
a. In order fulfil their function as Account Information Services, the AIS need to be able to retrieve financial data. The impossibility of doing so would make their existence superfluous.
b. The result of the request information: whatever the appropriate number is, it cannot be taken in isolation. The relevant number of requests is the number of successful requests. That is, the number of requests that have successfully obtained the requested information.
c. Neutrality and level playing field: whatever the appropriate number is, it must be either the same number of requests for an independent AISP or direct online access to the payment accounts (the AIS of the ASPSP) or a global measure that can be consumed through any AISP. If the payment user receives a different treatment depending on how he accesses his payment accounts this would be against PSD2 principle of neutrality and equal level playing field between market incumbents and new players. The different treatment in this case would be imposing a lower limit of connections for an independent AISP vs the traditional online banking interface.
d. The differentiation made between the payment service user requesting such information (22.5.a) vs the payment service user not actively requesting such information (22.5.b): since this distinction cannot be made when the payment service user is accessing his payment accounts through an independent AISP, it gives the direct online access to the payment accounts (the AIS of the ASPSP) a definite advantage over independent AISPs whether it is intentional or not. This goes against PSD2 principle of neutrality and equal level playing field.
e. The number of updates itself: 2 updates per day, even if they are successful is clearly not enough in many cases. Although it is understandable that banks want to limit the number in order to mitigate the load in their communication interface, it is too early to determine what the appropriate number is. Whatever the appropriate number is, it has to be either the same number of requests for an independent AISP or direct online access to the payment accounts (the AIS of the ASPSP) or a global measurer that can be consumed through any AISP.
[IT services provider "]"
[Other"]"
Account Information Services
Yes
arturog@eurobits.es
Arturo González Mac Dowell
+34-917080300
Yes