PSD2

Payment transactions under the PSD2

General Introduction to PSD2
PSD is short for PaymentServicesDirective. As an EU Directive for the European Economic Area (EEA), PSD establishes the framework for regulation of payment services and payment service providers. The revision of the Payment Services Directive resulted in the so-called PSD2 directive, which went into effect on 13 January 2018. In it, the EU Commission is pursuing the goals of

• increasing payment transaction security,
• strengthening consumer protection,
• promoting innovation, and
• increasing competition in the market.

With the launch date in January 2018, regulations went into effect that deal with changes in payment processing, complaint management, transparency, and liability. The scope of the Directive was specifically expanded to include foreign currencies and so-called one-leg-out transactions where at least one of the participating payment service providers is registered/located within the EEA.

Moreover, PSD2 regulates the authorisation of online orders and defines new roles of payment service providers, which are summarised under the term third-party providers (TPP). Account-keeping institutions must enable third-party providers to electronically access account content and trigger payments. Standards for the technical implementation have been adopted and will go into effect on 14 September 2019. PSD2 refers in these sections to payment-enabled accounts (hereafter payment accounts) that are not listed in the reference account model. The reference account model keeps accounts that only allow transfer to a previously stored reference account.

Strong Customer Authentication (SCA) was introduced to authorise online orders including payment initiation and account inquiries. SCA requires two independent attributes pertaining to ownership (e.g. mobile phone), knowledge (e.g. PIN) and property/inheritance (e.g. fingerprint).During order placement, the specific authorisation is linked dynamically with the order data, so that only the requested order can be authorised by the generated authorisation code (e.g. TAN).

Third-party providers gain access to the payment accounts of payment service users via an online interface, the so-called third-party provider interface. Services for querying and evaluating account data and initiating transfers can thus be operated directly by third-party providers under the regulations of PSD2. PSD2 regulates the access of third-party providers to payment accounts. Payment service users must explicitly agree to access by third-party provide

Further links:
PSD2
RTS on SCA and CSC (Strong customer authentication and third-party interface)
Deutsche Bundesbank
Bundesanstalt für Finanzdienstleistungsaufsicht (BaFin)

Third-Party Providers
PSD2 defines new categories of payment service providers who will be able to access accountinformation and initiate fund transfers. This is collectively described under the term third-party provider:

• Account Information Service (AIS)
  Account information services access the account information of payment accounts. In doing so, they receive the same information that is also visible to the payment service user via his or her online banking platform or bank statements.
  Service providers who offer account information services are registered with the respective national supervisory authority (in Germany, this is the Federal Financial Supervisory Authority, or BaFin for short). The English abbreviation for Account Information Service Provider is AISP.

• Payment Initiating Service (PIS)
  Payment initiating services enable the transfer of funds without requiring the payment service user having to use the online banking of his or her account-keeping institution. For example, an online retailer can use a payment initiating service to directly allow their customers to pay for their order through the sales process on the merchant's website. The feedback provided to the payment initiating service by triggering a funds transfer corresponds to the confirmation message that the payment service user receives through his or her online banking platform.
  Service providers who offer payment initiation services are registered with the respectivenational supervisory authority (in Germany, this is the BaFin). The English abbreviationfor Payment Initiating Service Provider is PISP.

• Payment Instrument Issuing Service (PIIS)
  A payment instrument issuing service provides a payment service user with a payment tool whose billing is tied to a payment account that the user maintains at an account-keeping institutions. In the context of PSD2, such a service makes it possible to send an availability query to the referenced payment account, stating the specific amount of available funds. The answer is hereby limited to ‘Yes’ or ‘No’, applies to the specificpoint in time of the query and does not lead to a reservation of the requested amount of money.
  Service providers offering payment instrument issuing services are authorised by the respective national supervisory authority (in Germany, this is the BaFin). The English abbreviation for Payment Instrument Issuing Service Provider is PIISP.
  Third-party providers have their own access interface, which meets the requirements of PSD2 and is implemented according to the standardised NextGenPSD2 framework of the Berlin Group.

All actions by third-party providers aimed at account-keeping institutions are subject to authorisation by the payment service user. The authorisation is granted by the payment service user via the authentication tool issued by the account-keeping institution, which must comply with the Strong Customer Authentication (SCA) regulations. Validation and acceptance of an authorisation is the responsibility of the account-keeping institution in the same way as in online banking.

Statistical informations
Statistical information on payment transaction processing with a view to availability and throughput of the various interfaces. The evaluation takes place once a quarter and covers a period of 90 days.

Statistical information (PDF / 2MB)

PSD2 TPP

Information for Third Party Service Providers

XS2A Documentation
The implementation of the third-party provider interface uses the standard of the NextGenPSD2 framework of the Berlin Group for XS2A (Access to Account). Below is a link to the specification documents of the Berlin Group, and in a separate document you will find our presentation as an account-keeping institution, which depicts the scope of the standard in accordance with our offer for payment accounts.

Berlin Group www.berlin-group.org
Characteristic XS2A interface of the flatexDEGIRO Bank (Link)

Please contact Support, should you have any questions .

Productive system
For productive operation, flatex-Bank, as the account servicing payment service provider (ASPSP), provides third-party payment service providers (TPP) with the XS2A interfaces for accessing account data and initiating transfers.

The following framework conditions exist for the productive system:

• TPP identify themselves to the productive system with valid certificates according to the requirements of PSD2
  electronic qualified certificate according to eIDAS regulation with the certificate attributesfor the role of TPP, competent supervisory authority and authorization number
• The XS2A interface requires connection certificate (QWAC - Qualified certificate for website authentication) and seal certificate (QCert for ESeal - Qualified certificate for electronic seals).
• SCA is executed using the redirect approach.
  Payment service users are directed to a separate browser-based Consent app.

The productive system is accessible as follows:
https://eb1.flatex-bank.com/tristan/xs2a-prod/

Alternative model
In the event of a failure of the primary productive system, the secondary system is available to the TPP as an alternative model. As a stand-by system, this system covers the same scope of the XS2A interface as the primary productive system, that is, the secondary system is addressed with the same methods as the primary productive system for other URLs (see below).

The use of the secondary system is expressly indicated by a corresponding message on this WebSite. You then reach the XS2A interface under the URL:
https://eb2.flatex-bank.com/tristan/xs2a-prod/

Test System
As an account-keeping institution, the flatexDEGIRO Bank provides third-party providers (TPPs) with a test system for the XS2A interface. This system makes it possible to test the technical connection and functional communication before using the system in a real environment.

The following framework conditions exist for the test system:

• TPPs must identify themselves to the test system with a valid certificate as required by PSD2:
  Qualified electronic certificate according to the eIDAS regulation (electronic IDentification, Authentication and trust Services) with the certificate attributes for the role of the TPP, the relevant supervisory authority and the authorisation number
• The XS2A interface requires Qualified certificate for website authentication (QWAC) and Qualified certificate for electronic seals (QCert for ESeal).
• Currently, test certificates from Bundesdruckerei or the trusted service provider(TSP) D-Trust GmbH are accepted. Further TSP on request.
• The test system is not connected to a core banking system (backend).
• Life-cycle tests, payment submission and subsequent account verification are not possible.
• The response is managed according to the test specifications by using specific data in accordance with the test specifications.
• SCA is not a test item. The behaviour of SCA is based on the respective test case.
• The full scope of XS2A services, implemented by the account-keeping institutions, can be tested.
  (see also: Characteristic XS2A interface of the flatexDEGIRO Bank (Link). The test system does not take into account any restrictions that may exist in the services of a connected contracting party.)

The test system can be accessed as follows:
https://eb1.dev.fintechgroup.com/tristan/xs2a-test/

Please contact Support, should you have any questions.

Test Specifications
The following test specifications are provided for third-party providers (TPP) to perform the connection tests to the XS2A interface. The test specifications consider specific services of the XS2A interface in good/bad case scenarios. Not all possible variants are listed in detail. The goal is to provide sample coverage that allows TPPs to test their implementation of the XS2A interface for the technical port.

The test specifications consist of the following elements:

• Test case description for the relevant services
• Test data for triggering of test cases according to the specified behaviour (good/badcases)
• Reference information to the answers according to the triggered test cases

Please pay attention to the general conditions listed in the section.

Data and specifications for XS2A interface connectivity tests (PDF)

Please contact Support, should you have any questions.

PSD2 PSU

Information for customers
Payment Service Users (PSUs) within the meaning of PSD2 are customers who have accounts that are eligible for payment transactions, i.e. payment accounts. Payment accounts are characterised by the fact that payment transactions can be carried out by the account holder in full via these accounts, in particular in the form of credit transfers. Accounts that are managed partly or wholly in the reference account model do not fall under this category of accounts.

The PSU requires a PSD2-compliant authentication tool to authenticate online access to account information (account balance, account statements) and order credit transfers. Such an authentication instrument is provided by flatexDEGIRO Bank in the form of the pTAN procedure. The pTAN procedure (or pushTAN procedure) is an app-based procedure in which the relevant data of a transaction with the generated TAN is transferred to an app ("pushed") and can subsequently be used to release a transaction. Further information can be found on the information pages in the Corporate Clients Web branch.

If a release is required when using a third-party app that communicates with us as the account servicing payment service provider via XS2A, this does not happen as usual in online banking or within the third-party app. To record the TAN, the PSU is directed to the Consent app, which opens in the browser.

Authentication or release via TAN is required every 90 days when accessing account information. Within this period of 90 days, access can take place without further TAN input. To authorize bank transfers, a TAN release is always required.