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:

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.



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.

Characteristic XS2A interface of the flatex Bank

Please contact Support, should you have any questions .

Test System

As an account-keeping institution, the flatex 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 flatex Bank).
    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:

Please contact Support, should you have any questions.

The test system can be accessed as follows:

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

Please contact Support, should you have any questions.