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.”

Monday, 6 March 2017

Main highlights of the EBA final draft on the RTS on Strong Customer Authentication and Common and Secure Communication

Below the main highlights of the EBA final draft on the Regulatory Technical Standards on Strong Customer Authentication and Common and Secure Communication published on February 23th, 2017.

1) Screen scrapping is no longer allowed

The EBA interprets the security requirements under PSD2 as meaning that the TPPs will no longer be able to screen scrape. The EBA understands screen scraping as a way for the PISP to access the customer’s online account by pretending to be that customer, often using advanced robot technology. The EBA disagrees with the suggestion of some of the respondents that not allowing screen scraping would be against the principle of non-discrimination. 

2) Cards on file is out of scope of PSD2

It is the EBA’s understanding that card-on-file solutions and their providers are not within the scope of PSD2 and therefore not within the scope of these RTS. Providers of card-on-file solutions are not PSPs in the sense of PSD2 unless of course the PSP conducts other activities that are within the scope of PSD2 and would therefore be regulated for that purpose.

3) Transactional risk-based exemption from SCA is now allowed (up to a maximum value of EUR 500)

The EBA agrees with the view expressed by the respondents that a risk-based approach, including the ability to conduct detailed TRA and fraud monitoring, is essential to achieve the objective under PSD2 of reducing overall fraud. Consequently, the EBA arrived at the view that, in accordance with Article 98(2)(a) PSD2, an exemption based on such an analysis should be added in a new Article 16 of the RTS. The RTS also reiterate the importance of risk and fraud monitoring in general as a necessary complement to the principle of SCA laid out in PSD2 as stated in a new Article 2 RTS

4) Merchants cannot apply transactional risk-base exemption from SCA

The EBA also explains in rationale 24 that its interpretation of PSD2 suggests that the transaction-risk analysis (TRA) exemption from SCA can be applied by the payee’s and payer’s PSPs, but not by the payer or the payee themselves. The liability rules also suggest that the payer’s PSP should have the last say on whether or not the TRA exemption is used for a specific transaction.

5) PSPs that want to apply TRA exemption from SCA will have to track fraud rates and being audited 

RTS now require PSPs to monitor all of their fraud rates as well as the performance of the TRA method used, which must additionally be independently assessed by qualified auditors. Furthermore, the PSP must report any change related to the use of this exemption to the national authorities



Wednesday, 1 March 2017

Bye, bye, tarjetas

Hace casi un año compartí con algunos miembros del comité de dirección de mi anterior empresa, un extracto de una publicación de Brett King (CEO y Fundador de Moven y uno de las voces en Fintech más escuchadas) titulado Bye, bye, credit cards. Al final de este post os he dejado el enlace al texto completo (en inglés) para que lo leáis. Merece la pena.

El objetivo de mi mensaje era hacerles reflexionar sobre los grandes desafíos a los que se enfrenta el negocio de tarjetas con la llegada del tiempo real y la apertura del acceso a las cuentas corrientes, lo que posibilita hacer y recibir pagos en ellas en tiempo real, haciendo innecesario el uso de una tarjeta.

Uno de los pronósticos de Brett King es que para 2022 no existirán en los bancos ni un Head of Cards ni una unidad de tarjetas. Personalmente, comparto lo que hay detrás de la reflexión de King, no habrá jefes ni áreas de Tarjetas, sino de Pagos.

Y creo que en el mercado empezamos a apreciar movimientos desde lo aparentemente estético: CaixaCards pasó a llamarse Caixa Payments el año pasado, a movimientos organizativos y de negocio importantes:

- Este mes Barclays ha anunciado que Barclaycard UK se integra completamente dentro de la estructura de Barclays UK (el banco retail del grupo Barclays en UK), dejando de ser una unidad independiente.

- También este mes, Barclaycard (a través de Barclaycard Payment Solutions) ha firmado un acuerdo con Vocalink para permitir que los comercios que actualmente utilizan su payment gateway, puedan integrar la nueva modalidad de pago Pay by Bank App. Lo que significa que una unidad históricamente de tarjetas, empieza a facilitar a sus comercios clientes el pago de cuenta a cuenta en tiempo real, lo que hace innecesario las tarjetas.

Y tú, ¿crees que en unos años dejarán de existir las unidades de tarjetas de los bancos?