NextGenPSD2 Conference 2017

Transcription

1 THE Berlin GROUP A EUROPEAN STANDARDS INITIATIVE NextGenPSD2 Conference 2017 General Approach of the Berlin Group PSD2 API Detlef Hillen, SRC

2 Content 1 Services supported by the XS2A interface Core services and extended services Variants of the XS2A interface 2 Scope of the Berlin Group specification 3 Key concepts Messages Transactions Sessions Identification of the TPP at the XS2A interface Strong Customer Authentication Confirmation of the consent of the PSU 2

3 XS2A interface and supported services Focus of the work of the Berlin Group 3

4 Services supported by the XS2A interface Core Services are supported by each implementation of the XS2A interface n Payment initiation service As defined by PSD2 article 66 n Account information service As defined by PSD2 article 67 n Confirmation of funds service As defined by PSD2 article 65 Extended Services may be supported by an implementation of the XS2A interface n To be decided by the ASPSP n May be specified in future By the Berlin Group as part of a new release of the specifications By a group of interested ASPSP By a single ASPSP n No contract between ASPSP and TPP n A contract between ASPSP and TPP might be necessary Deutsche Bank 4

5 Variants of XS2A interfaces Different variants of XS2A interfaces are possible n ASPSP decides which variants are supported n ASPSP informs about its variants as part of its interface documentation For a single service variants can distinguish between n Requirements for the identification of the TPP n Approach for executing strong customer authentication (if needed for the service) n Products to be supported for a service Example of products for PIS: SCT, SCT inst, domestic payments n Data elements needed as part of a service Example for PIS: structured/unstructured remittance information n Etc. 5

6 Scope of the Berlin Group specifications 6

7 Excursion: eidas compliant qualified certificates n eidas regulation Regulation (EU) No 910/2014 on electronic identification and trust services for electronic transactions in the internal market n Qualified certificates have to be issued by a qualified trust service provider (QTSP) QTSP do exist in different countries of the EU After registration by the national authority a TPP has to apply for a qualified certificate by one of the existing QTSP n Qualified certificates compliant with EBA RTS are not available today But standardisation has started by corresponding ETSI working group n It is expected that compliant certificates will be provided in time by some QTSP 7

8 Key concepts: Layers of the XS2A interface Application layer n Set of all messages and data elements specified by the Berlin Group and which are exchanged between TPP and ASPSP at the XS2A interface. Transport layer n Technical exchange of the messages between ASPSP and TPP using the internet n TLS-connection with client authentication n https as protocol Deutsche Bank 8

9 Key concepts: Message Transaction Session at XS2A interface n Messages at the XS2A interface Basic building blocks for executing processes at the XS2A interface Message = Set of data elements to be exchanged at the XS2A interface n Current version: pure client/server model of the XS2A interface Request messages sent by TPP to the ASPSP Response message sent by the ASPSP to the TPP n The implementation of the messages is based on a Rest API approach POST, GET, DELETE or PUT https methods REST API stateless API No concept of a "LOGIN" n More details in the coming sessions 9

10 Key concepts: Message Transaction Session at XS2A interface n Transactions at the XS2A interface Set of messages to be exchanged for executing a "business transaction" which is supported at the XS2A interface of an ASPSP Currently defined transactions for core services Payment initiation of a single payment Establish account information consent Get list of reachable accounts Get balances of a dedicated account Get account transaction information of a dedicated account Confirmation of funds 10

11 Key concepts: Message Transaction Session at XS2A interface n Session at the XS2A interface Set of transactions executed consecutively at the XS2A API n Support of sessions at the XS2A interface is optional for the ASPSP n Important: For a single transaction a TPP has to use only one of its roles Within a session a TPP can use different of its roles Deutsche Bank 11

12 Key concepts: Identification of a TPP at the XS2A interface Requirement of the PSD2 n The TPP has to identify itself for each access to the XS2A interface Requirement of EBA RTS n The identification has to be based on qualified certificates n Qualified certificates shall be compliant with the eidas regulation n Qualified certificates shall contain PSD2-specific attributes Reference number of the registration of the TPP by the national authority Name of the national authority One or more roles the TPP is authorised to use 12

13 Key concepts: Identification of a TPP at the XS2A interface TPP ASPSP n Certificate shall contain the role of the TPP which is necessary for the corresponding transaction n Always identification at transport layer n Identification at the application layer only if requested by the ASPSP n ASPSP will reject any request If the identification of the TPP cannot be verified correctly If the certificate does not contain the correct role Deutsche Bank 13

14 Key concepts: Identification of a TPP at the XS2A interface Important n It is the TPP who has the contact to the PSU, who has to identify itself at the XS2A interface of an ASPSP n This is also true, if further (technical) service providers are used by the TPP to access the XS2A interface of an ASPSP 14

15 Key concepts: Strong customer authentication (SCA) Strong customer authentication n Requirement of PSD2 and EBA RTS For access to account information For payment initiation n Exemptions compliant with EBA RTS are possible Exemptions are optional Decision about an exemption is always in the responsibility of the ASPSP n Strong customer authentication has to be used also if accounts are accessed by TPP using the XS2A interface Same exemptions have to be applied 15

16 Key concepts: Strong customer authentication (SCA) Strong customer authentication n Different methods and procedures exist for executing a strong customer authentication of the PSU as part of a transaction ASPSP decides (together with PSU) which methods/procedures have to be used for SCA Specification of the Berlin Group does support all methods/procedures in a generic way ASPSP informs as part of its documentation about methods/procedures to be used and (if necessary) how to implement these as part of the TPP interface 16

17 Key concepts: Strong customer authentication (SCA) Different approaches for implementing SCA n Redirect approach PSU is redirected to web interface provided by the ASPSP n Decoupled approach SCA out-of-band using a special APP Same behaviour as for Online Banking n Embedded approach PSU enters credentials on the interface of the TPP Deutsche Bank 17

18 Key concepts: Authorisation of the PSU consent Each transaction at the XS2A interface is subject to the consent of the PSU n How to proof that a PSU has given its consent to a transaction? n Easy if SCA has to be used for this transaction By executing SCA as part of a transaction the PSU gives its commitment to this transaction n But how to do this if no SCA has to be used for the transaction? if the PSU is not directly involved in the transaction? reading account information by an AISP according to article 31 EBA RTS 18

19 Key concepts: Authorisation of the PSU consent Using the special "Establish account information consent" transaction at the XS2A interface Using OAuth2 protocol for asking the PSU for a confirmation n Includes SCA of the PSU n Result is an access token given to the TPP n TPP can use this for following accesses of account information of that PSU n Result is an access token given to the TPP n TPP can use this for following accesses of account information of that PSU Deutsche Bank 19

20 Key concepts: Optional usage of OAuth2 protocol OAuth2 protocol and XS2A interface can be combined if requested by an ASPSP n OAuth2 protocol can be used to generate and verify access rights of a TPP to resources owned by the PSU n No full integration, but loosely coupled n OAuth2 protocol can be used as a prestep before accessing the XS2A interface Result of the OAuth2 protocol can be reused in the execution of transactions at the XS2A interface Deutsche Bank 20

21 THE Berlin GROUP A EUROPEAN STANDARDS INITIATIVE Thank you for your attention