The responder is of an opinion principle based approach should be limited to extensions, while specific requirements, and actual specifications should be provider for basic services to be provided by ASPSP. As part of the specification a common vocabulary, categorisation and derived dictionaries, basically a taxonomy of accounts and transactions, should be named, so that the semantics remains clear and can be consumed by tools without adaptation, in the basic scope. Extension points should be named.
In the opinion of the responder additional clarifications are required about the nature and requirements of the “separation or segregation” prescribed by the RTS, otherwise it is impossible for the implementer to decide if given method is satisfying the requirement. The sentence of the RTS, read literally, implies for example a mobile payment initiated using a mobile phone of PSU, cannot be authorised using the same phone – as such phone would be the same device. Also any hopes of using applications that aggregate access to several accounts, without the need of using ASPSP-provided applications, might be rendered void – as the SCA required to get access to the account would require separate channel or application – effectively the one provided by the ASPSP.
Additionally, as the SCA and dynamic linking method is under control of the ASPSP, it is imaginable the ASPSP may require a SCA method rendering use of given payment instrument impossible or impractical. In an exaggerated example, it is imaginable the ASPSP would require confirmation of the transaction to be performed via a device issued by the ASPSP that is networked via a proprietary network infrastructure, hardly available – rendering all mobile payments undoable. Additional requirements and limits to the freedom of choice of SCA and dynamic linking method to be requested by the ASPSP are required.
Assuming the RTS is not trying to limit the ability of existing card acquisition infrastructure to authorize transactions by the PSU using PIN entered on the card terminal, the card payments, despite being named in scope of the RTS (see Rational point 3.2.1, subpoint 17.), are incompatible with the requirement of “the channel, mobile application, or device where the information about the amount and the payee of the transaction is displayed to be independent or segregated from the channel, mobile application or device used for initiating the payment” – as the card terminal is the device and channel both payment initiation and authorisation, including displaying the amount, takes place. As already hinted, these two aspects of the directive (card vs. non-card transaction channels) might lead to a self-contradictory situation of non-apparent preference of one of the channels over another, and the proposed RTS fails to comment on this discrepancy, and it is unclear if this is a result of different interpretation of “card present” as a “non-remote” transaction.
No specific threats known to the responder. However a set of requirements towards means used to protect credentials on PSU’s device, would benefit the RTS. In particular requirements for Trusted Execution Platforms as means for separation / independence of initiation and authorisation are missing.
The responder is of an opinion that exemptions based on risk analysis, in particular allowing exemptions based on behavioural analysis and also specific patterns defined by the PSU himself/herself, should be allowed. A typical example would be an ability to define a rule for exempting typical daily routine payments, like transport tickets, grocery, lunch, drinks etc. performed in some geography and time of day, without the need to register all participating parties as trusted beneficiaries (which actually should be avoided, as this is one of potential attack vector – tricking the PSU to accept a rogue party as a trusted beneficiary to execute fraud at a later moment).
Having said that, the PSU should be given full control, if such exemptions are to be used (within the limits designed to limit the impact of potential fraud on ASPSP), and the consent to actually use them should be explicit (those should be inactive by default).
Any payment instrument dependent for payment initiation on a channel such as card terminal (be it really a card terminal, or other kind of instrument using similar terminals) deployed to the point of sale, may be adversely affected if the location or other conditions make it impossible for the PSU to use the SCA as prescribed by the ASPSP. For example lack of connectivity to the cellular network, and inability to execute a form of SCA depending on network connectivity, would result in a situation when some transactions would be accepted (those exempted and not happening to be 10th in a row or above the cumulative limit), while some will be rejected, with no option of performing the SCA, while the customer could have reasonably expected the transaction to be exempted. ASPSPs may choose to require a form of SCA adding significant friction, effectively being able to control third parties (by requesting SCA in the form zeroing benefits of the payment instrument provided by third party).
The similarity to contactless card payments is superficial, as the card payment PIN authorisation can always be performed using the connectivity of the card terminal, while other payment instruments are likely (or actually required to, based on the requirement of using separate channel and device for payment initiation and authorisation in the RTS?) to use a separate channel, and not the payment terminal used for initiation.
The list of exemptions proposed creates unjustified competitive advantage for card schemes (especially contactless cards), by using more restrictive requirements for transaction to be exempted, including the transaction and cumulative amount lower than similar exemption criteria for cards, introducing requirements possibly rendering the payment instrument unusable in a place or situation a card payment can be accepted, and last, but not least allowing card payments to use risk-based exemption criteria, while explicitly forbidding other kind of instruments from using such criteria.
In the opinion of the responder the expected outcome will be long lasting dominance of card based payments, as the only reliable instrument will be the card.
It is also worth noting that point 3.2.1 paragraph 17. of the rationale about the scope of payments instruments implies the change is required to existing card acquisition schemes, as the existing card acquisition is not compatible with the limits named in the RTS (in particular contactless payments allow higher limits and allow for risk based authorisation).
So it remains unclear how the existing practices are to be impacted by the RTS – and as such the RTS fails to satisfy its goals.
The responder finds the provisions proposed in Chapter 3 to be mostly correct, but insufficient.
In particular, it is the responder’s belief that the payment service users’ personalised security credentials issued for the PSU by any PSP (in particular the ASPSP) should under no circumstances be made available to any third party (other than the PSU and the PSP the credentials were meant to be used with), and remain known only to the PSU.
Any authentication scheme or interface depending on sharing the personalized service users’ security credentials with a party other than the PSP the credentials were originally meant for should be explicitly forbidden by the RTS. Such schemes are basically depending on impersonation of the PSU by the third party provider, and as such are rendering the credentials invalid for the purpose of authentication (while, as long as not used by a rogue party or otherwise compromised, the credentials would remain valid for authorisation).
Use of “screen scraping” techniques using the ASPSP internet channel, or interfaces using OAuth2 “resource owner password credentials flow” are examples of the above mentioned approaches, to be forbidden by the RTS, as inherently unsafe, and with a more secure alternatives readily available.
The request above is justified by analysis of the risks. In our opinion techniques such as phishing and social engineering, tricking the PSU to disclose the user’s credentials to a malicious party, are, and will likely remain, a larger risk than any technically enabled attack vector. The only way of preventing those kinds of attacks is education of the users (PSUs), both by the ASPSPs and authorities. The message conveyed must be unambiguous, and leave no room for mistakes: under no circumstances the user should be requested to reveal his/her credentials to any party other than the (only) party the credentials were meant for. Examples of successful informational campaigns run by appropriate authorities, as well as the organisations of ASPSPs, exist, for example the tone run in the last years by Polish regulator KNF – which led to abandoning screen scraping based approach to payment initiation by PayPal. There may be no exceptions, just one simple rule: credentials used with my bank, can only be given to my bank, and nobody else.
Also, in case of compromising a Third Party Provider by a malicious attacker, which will inevitably happen one day (as proven by history of numerous security breaches and resulting leaks of customer sensitive data, including payment related data), the impact of leaking the personalized security credentials is significantly larger than any other data related to the PSU, especially as it leaves the PSU with no means of proving any particular transaction was performed by a malicious attacker and not the PSU himself/herself.
While currently several legitimate companies operate basing on the knowledge of PSU’s personalized security credentials issued by the PSU’s ASPSPs (the banks) and screen scraping, eg. Sofort Gmbh or Kontomatic to name just two, it seems their method of accessing customer account and payment initiation, can, and should be, replaced, by use of a channels made available by the ASPSPs in the response to PSD2, when those become available.
It is the responder belief the provisions of the RTS do not describe interoperable technical communication standard (in the sense the provisions do not go far enough to make a derived solution interoperable without additional clarifications and bilateral agreements), and as such there is a risk of fragmentation, thus limiting acceptance of the regulation, and making it more difficult (costly) to benefit from.
Use of ISO 20022 elements, components or approved message definitions may help build interoperable interfaces between PSPs, but, in the opinion of the responder, ISO 20022 in its current form and the draft RTS are insufficient to define interoperable service of the scope required by PSD2.
In the opinion of the responder, the provisions of the RTS, in particular “to require that account servicing payment service provider’s communication interface uses common and open standards which are developed by international or European standardisation organisations as well as ISO 20022 elements, components or approved message definitions” leave to much of undefined, while taking away enough of the freedom of choice, to render several mature APIs in use currently non-compliant. The only way interoperable API can be derived from ISO 20022, is by use of messages. To the best knowledge of the responder, the messages defined do not cover all possible PSD2 related APIs.
The only way interoperability of interfaces can be ENSURED, is by providing formal specification of the interface, and a method of verification of compliance of an interface to the specification provided. EBA must not shy away from providing such specification (or appointing a partner to prepare it on its behalf) and certification services, or face inevitable fragmentation of the PSD2.
Ensuring interoperability of interfaces exposed by different ASPSP is instrumental for acceptance of the regulation by the users. Otherwise several incompatible flavours will appear, and as the result versions offered
Also maintaining ability to use several (potentially hundreds) of incompatible interfaces constitutes significant cost for the AISP/PISP, prohibitive for smaller players. This may lead to a situation where the payment space will be dominated by just a few intermediaries, able to implement the variety of variants of interfaces exposed by the PSPs, and charging all other users for just the fact of unification of the exposed API.
For merchants becoming a PISP would be an interesting opportunity of reducing transaction costs (thus offering better prices for the end customer), however, if the technical barrier associated to lack of single interoperable interface is high, only largest retailers will be able to overcome it, while the small players will be forced to operate as of now, with the use of intermediaries, paying part of their margin as provisions. This might create a situation of substantial competitive advantage for the largest merchants, as the amortised, per transaction, cost, of maintaining their technical ability to use numerous interfaces, will be significantly lower than small merchants.
It is also worth observing that no (known to the responder) open banking APIs currently exposed by the banks directly use ISO 20022 messages or elements.
Most of existing interfaces are RESTful, and as such use the transport protocol to convey semantic value, while ISO 20022 makes no provision for that, embedding semantics in the message only.
Also, the majority of APIs used contemporary use JSON for syntax of the requests and responses. ISO 20022 currently does not define JSON syntax (only XML and ASN.1), which will lead to even more interoperability problems (assuming PSPs will attempt JSON based API, despite its unclear status in the RTS – as no syntax will be truly ISO 20022 compliant, and the RTS requires it to be).
The responder concurs to the reasoning and solution described in the RTS, with one remark: while support for e-IDAS based approach should be mandatorily supported, provision for other method of authenticating the PSPs to each other should be possible in order to allow future development of the framework and implementation variants specific to the member states.
The responder agrees it is necessary to impose limits to the frequency AISPs can request information from the ASPSP’s interfaces. The limit of no more than two times a day seems arbitrary, and as such is difficult to discuss.
It is however worth considering a minimum requirement, of e.g. 2 times a day, the ASPSP should prepare their interfaces for, while allowing the ASPSP to specify a higher number as part of their interface specification. AISP should be legally obligated to respect the specification published by ASPSP.
It is also advisable that the load generated by requesting information by the applications provided by AISPs is distributed evenly during the day, or at least sharp peaks are avoided. For example hardcoded, same time of day for all mobile or desktop clients provided by AISP to request account information, should be avoided. Otherwise a sharp increase of load may appear rendering ASPSP interface unavailable, despite AISP not exceeding the daily limit.