Thursday, 23 March 2017

Main highlights of the HM Treasury consultation paper on the implementation of PSD2

Objectives of the third party provider access rules

“The CMA included in its final remedies published on 9 August 2016 a requirement for nine banks across Great Britain and Northern Ireland, working with other ASPSPs and current and potential “third party” providers to deliver an Open Banking Application Programming Interface (API) Standard. The CMA make clear that this API Standard will need to align with the PSDII, requiring banks to deliver it by January 2018 when the PSDII comes into effect.”

“Within the PSDII context, the Open Banking API Standard is expected to provide the framework for how AISP and PISP software authenticates, accesses data, and initiates payments with an ASPSP.”

“The government therefore sees the PSDII implementing regulations as providing the legislative foundations on which the Open Banking API Standard then sits. Although APIs are only one method by which ASPSPs could provide the access to AISPs or PISPs mandated under the PSDII, the government believes a commonly utilised API framework will lead to greater competition in the retail banking and “third party” services market and better outcomes for payers and other end users.”


“Best practice is expected to involve customers authenticating themselves directly with their ASPSP, i.e. providing their payment account login details only to their ASPSP, rather than to the AISP or PISP, with confirmation of access then provided by the ASPSP back to the AISP or PISP. This mechanism will limit risk to payers and other end users and is expected to form a part of the Open Banking API Standard.”

“Subject to the EBA RTS, the government expects an AISP will be able to access the information contained within the payment account held by an ASPSP on both a one-off and ongoing basis. Ongoing basis means that users will be required to authenticate their identity once and then, with appropriate consent, the AISP will continue to be able to access their information even after the user’s immediate session has ceased. ASPSPs are expected to allow for regular communication sessions with the AISP, but not necessarily to provide an uninterrupted data stream.”

“Subject to the EBA RTS, the government expects the initiation of transactions through a PISP to require authentication each time a payment is initiated.”

Role of the competent authority

"In line with current authorisation arrangement for payment institutions, the government believes that the FCA should undertakes the role of registering and authorising AISPs and PISPs, and ensuring that ASPSPs, AISPs and PISPs are meeting their obligations under the legislation. As part of this, ASPSPs must notify the FCA where access is denied to AISPs or PISPs."


“The PSDII, and the proposed draft implementing regulations, are clear that where a payer is using an AIS or PIS, explicit consent must be obtained by the AISP or PISP for the service or payment transaction in question. The authorisation of a payment transaction does not have to be given by the user directly to the ASPSP but can be given only to the PISP.”


“The following types of accounts likely to fall within the definition of online payment accounts:

personal current accounts
business current accounts
credit card accounts
flexible savings accounts
e-money accounts”

“ASPSPs are expected to provide to an AISP access to the same information regarding a payment account as is available to the user when accessing their account online directly with the ASPSP. This could include:

account information, such as name on the account, address of the account holder, account number
product details, such as the product type, interest rate when in credit, overdraft amount, interest rate when overdrawn
transaction data to the same level of granularity and covering the same time periods as is available to the end user online”

“ASPSPs are expected to provide to a PISP access to the same functionality that is available to the user when accessing their payment account online directly with the ASPSP. For the majority of online payment accounts this is likely to include credit transfers and the establishment of standing orders, but not the establishment of direct debit mandates if this is not already available to the user online.”

“The government interprets the definition of AIS as meaning that an AISP uses some or all of the information from one or more payment accounts held by the PSU with one or more ASPSPs, to provide an information service. The government expects these services to include, though not be limited to:

dashboard services that show aggregated information across a number of payment accounts
price comparison and product identification services
income and expenditure analysis, including affordability and credit rating or credit worthiness assessments, and
expenditure analysis that alerts users to consequences of particular actions, such as breaching their overdraft limit”

Initial implementation

“The government’s implementing legislation will come into force on 13 January 2018, including the requirements around access set out in article 66 and 67. However, provisions related to security in articles 65, 66, 67 and 97 will not come into force until 18 months after the EBA RTS on SCA and secure communication are in force. As such, these provisions are not expected to be in force before autumn 2018.”

“During this initial period ASPSPs will be expected to provide access to AISPs and PISPs from January 2018 and, as industry will have had sight of the draft RTS, the government would expect this to be done in line with the draft RTS wherever possible.”

“During this period both ASPSPs and AISPs/PISPs will be undergoing a learning process and will be expected to work closely across industry, and where appropriate with the FCA, to overcome challenges that emerge and ensure that users have the ability to use AIS or PIS.”

No comments:

Post a Comment