!!! Overview[1][2]
[{$pagename}] ([PSD2]) is a new (2015-08-10) [regulation] that will apply across the [European Union] and is likely to result in a huge increase in the number of [Application Programing Interfaces] ([APIs]) for banking products.
%%information
__Revised__ [{$pagename}] [PSD2] is what we refer to as there were previous versions.
%%
Making [Financial Organizations] programmable will significantly change the engagement model for accessing a consumer’s account.
What is less clear is how this may affect the consumer themselves, including their level of access to the [data] (that in theory they own), and their ability to use their data in any way they see fit.
!! In short[3]
In short, [{$pagename}] enables bank [customers], both consumers and businesses, to use [Third-party] providers to manage their finances. In the near future, you may be using [Facebook] or [Google] to pay your bills, making [P2P] [payment Transactions] and analyse your spending, while still having your money safely placed in your current [bank] account. [Bank], however, are obligated to provide these [Third-party] providers access to their customers’ [accounts] through open [APIs]. This will enable third-parties to build financial services on top of banks’ [data] and infrastructure.
Banks will no longer only be competing against banks, but everyone offering financial services]. [PSD2] will fundamentally change the [Payment Transactions] value chain, what business models are profitable, and customer expectations. Through the [{$pagename}], the [European Commission] aims to improve innovation, reinforce consumer protection and improve the security of internet payments and account access within the [European Union] and [European Economic Area].
[{$pagename}] describes the following types of players within [Payment Transaction] landscape:
* [Payment Service User] ([PSU])
* [Account Information Service] ([AIS])
* [Payment Service Provider] ([PSP])
* [Payment Initiation Service] ([PIS])
* [Third Party Payment Service Provider]
* [Payment Initiation Service Provider] ([PISP])
* [Account Information Service Provider] ([AISP])
* [Account Servicing Payment Service Providers] ([ASPSP])
!! [{$pagename}] and [Consent] management.
[Account Servicing Payment Service Providers] ([ASPSP]) [MUST] gather and maintain [consent] at a granular level for [attributes] and specific [use cases] governed by [PSD2] and [General Data Protection Regulation] ([GDPR]) which requires extensive [Auditing].
[PSD2] mandates __explicit__ [consent] in two ways.
First, [third-party] access to customer data must be given only at the explicit consent of the customer. It is the responsibility of the third-party provider to ask for specific scoped access (i.e., read only access to account transactions) on behalf of the customer.
The [Account Servicing Payment Service Providers] [MUST] then request and record [consent] of the customer for the scoped access requested.
Second, [PSD2] mandates that data not be used, accessed or stored for any purpose other than the service the user explicitly requested. These requirements are similar to requirements under the [General Data Protection Regulation] ([GDPR]), but are given an additional [legal] basis by being in [PSD2].
!! [Authentication], [Authorization], and [Consent][1]
The user will have to [authenticate] with the bank using [Two-Factor Authentication], which will then provide the client application with a unique and time-bound [Access Token]. The client app can use this unique [Access Token] to make calls to the bank on the behalf of the user.
Generally, these [Access Token] are specific to a single account of a user and are valid over a longer duration (up to 30 days, for example).
For the payment [API], users need to [authenticate] their accounts __each time a transfer is made__ because these [API] calls need to meet higher security requirements.
The end user [authenticates] the account and provides access to the app to carry out the transaction via a [Two-Factor Authentication] on the bank site. The following steps are done to provide authentication:
* The user is shown a [consent] page from the bank where the user logs in with a customer ID and password
* The bank then requests the user to verify this with an [OTP], which is sent to the user’s registered [mobile number|mobile Device]
Once the user enters the [OTP], the user is shown the accounts; this generates an [Access Token] specific to that account, which the app can then use to make calls on behalf of the user.
!! [Access to Account] ([XS2A])
[Access to Account] (XS2A) opens up for bypassing [actors] in the existing e-commerce ecosystem. [The Berlin Group] has defined [NextGenPSD2] which describes [Access to Account] [Framework] documents under [{$pagename}].
!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [DIRECTIVE 2007/64/EC|http://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32007L0064&from=EN2007/64/EC|target='_blank'] - based on information obtained 2018-05-27-
* [#2] - [http://ec.europa.eu/finance/payments/framework/index_en.htm|http://ec.europa.eu/finance/payments/framework/index_en.htm/|target='_blank'] - based on information obtained 2016-07-12-
* [#3] - [PSD2 - the directive that will change banking as we know it|https://www.evry.com/en/news/articles/psd2-the-directive-that-will-change-banking-as-we-know-it/|target='_blank'] - based on information obtained 2017-04-03