The conditions imposed by PSD2 on third parties
Under PSD2, all access by third parties to customer personal data, with a view to providing their own services, must not impinge on two key aspects of banking operations: privacy and security. We look at some of the conditions now imposed on TPPs that traditional banking operators were already subject to.
1. Mandatory use of strong authentication, two-factor (2FA) authentication or multi-factor authentication
This security requirement is detailed in paragraph 30, article 4, title 1 of PSD2. The document reads as follows:
"An authentication based on the use of two or more elements categorized as knowledge (something only the user knows), possession (something only the user possesses) and inherence (something the user is). These must be independent from one another, in that the breach of one does not compromise the reliability of the others, and is designed in such a way as to protect the confidentiality of the authentication data."
This security system means introducing double security factors for any remote, online or electronic payment transaction.
Typically, customers will authenticate their identity and confirm financial transactions via a code sent by SMS to a cell phone or device associated with the account holder.
2. Establishing standardized internal security frameworks
Providers that start offering banking services to account holders must establish internal security frameworks to safeguard their customers' privacy and security in terms of their data and personal transactions.
This security requirement is detailed in article 85 of PSD2, setting out how "a payment service provider shall establish a framework with appropriate mitigation measures and control mechanisms to manage the operational and security risks, relating to the payment services that it provides. As part of the framework, a payment service provider shall establish and maintain effective incident management procedures, including for the detection and classification of major operational and security incidents".
3. Reporting security incidents
Any customer privacy or security breach must be reported to the customer, but also made known to European regulators. This requirement is established in article 86 bis of the PSD2:
"In the case of a major operational or security incident, payment service providers shall, without undue delay, notify the competent authority in the home Member State of the payment service provider. Where the incident has or may have an impact on the financial interests of its payment service users, the payment service provider shall, without undue delay, inform its payment service users of the incident and of all measures that they can take to mitigate the adverse effects of the incident".
4. Evaluating and reporting on security frameworks
All systems guaranteeing privacy and security must be evaluated, with regular test results reported to regulators.
These prerequisites are designed to factor in the various new players now operating with customers who previously only interacted with traditional banks. They now make withdrawals, deposits, move money, sell and make purchases using accounts via applications that have no relation whatsoever with their bank, or are able to view their account movements without logging on to their bank accounts.
PSD2 allows such third party businesses to engage in all kinds of services:
- Cash deposits, withdrawals and all kind of transactions with a payment account.
- Implementation of payment operations: from debit and credit card payments, or those using other systems, right through to transfers and direct debits.
- Payment transactions where funds are covered by a credit facility held for a payment service user.
- Money remittance.
- Payment initiation services.
- Account information services.
Other requirements: technical instruments
To ensure that banking institutions, account information service providers, and payment initiation service providers are all able to comply with PSD2 requirements, a series of technical instruments are needed, and these are already well established as a common denominator across the industry.
- PSD2 Architecture
PSD2 is forcing traditional banks to make significant architectural changes, especially if they want to keep up with the industry. Banks are having to become more agile, with architectures based fundamentally on container technology and micro-services, which allow products to be launched far more quickly. While also ensuring that they are ready for emerging financial scenarios, including the use of blockchain technology and cloud computing.
- Development of APIs and business solutions for PSD2
APIs are the most efficient means of driving agile business development, whether internally or via a third-party provider. These APIs must be PSD2-ready and available to third parties, upon payment if so deemed appropriate, while providing all the independence permitted by such API Management structures.
In this regard, an 'API first' approach, in which applications are conceptualized and developed from zero rather than adjusting legacy systems, tend to be far more appropriate for launching new products, discovering new sources of revenues, etc.
- Digital transformation process
APIs can be used by third parties, in this case payment service providers, to offer appealing products to common customers. BBVA stands as a good example of this digital transformation in Spain. The bank has clearly understood the value of APIs, the significance of the new PSD2 environment, and how its relations with fintech and customers will shape its present and future.
- PSD2 Audit
Addressing PSD2 obligations requires internal controls at banks, as well as covering the services provided to third parties and how such companies make use of any customer data provided via such application development interfaces.
Sign up to the BBVAOPEN4U newsletter and receive tips, tools and the most innovative events directly in your inbox.