The main aims of PSD2 are:
- Stricter security requirements for electronic payments
- Protection of consumers’ financial data
- Opening the market for payment service providers, particularly in the case of services for consumers and companies
- Strengthening of consumer rights, e.g. with regard to liability for unauthorised payments and refunds in the case of direct debits in euros
- Prohibition on charging surcharges, regardless of the payment instrument
The three basic pillars of strong authentication are known to be possession, inherence and knowledge. At least two of these criteria are to be offered to users when providing access to the EBICS authorisation. For example, a smartcard (possession) could allow authorisation as an EBICS key medium via a smartcard reader and PIN entry (knowledge). This must therefore be implemented on the client side of the interface.
In addition to the EBICS means of providing clear identification and authentication of the person, the bank can also include additional strengthening tests (inherence), e.g. whether the previously agreed IP addresses must be used for communication. An IP address that does not match will then prevent access even if the rest of the authentication does match.
The required dynamism in the authentication is formed by EBICS by means of the electronic signature procedure, as the signature is always formed using the hash value of the original file and a timestamp.
Furthermore, the EBICS function of the distributed electronic signature (VEU) allows the infrastructures for payment submissions and authorisations to be separated by the payment service user. For example, submission via an automatic device by EBICS may take place without authorisation and the required authorisations can be submitted separately via mobile app, an EBICS portal or other EBICS clients, i.e. separated in terms of both space and time. Furthermore, the authorisation conditions may require several people to be involved. Today’s EBICS solutions such as EBICS portals, EBICS browser solutions, EBICS mobile clients and other EBICS clients already offer this. This technology must be offered and used consistently for the PSD2.
Opening the payment market for payment service providers means that banks must provide the applications of third parties with access to customer data – if the customer agrees. In order to implement this requirement, interfaces are required. The EBICS standard offers its own usable interface. If the third-party supplier cannot obtain the information directly via the standard EBICS access, fast and flexible APIs are required that exchange the data as and when it is required. Uniformity and multiple usability are desirable.
In practice, user activities and, in particular, authorisations are already recorded in e-banking and payment applications. The strengthening of consumer rights pursued by PSD2 does, however, also require that service providers and banks make the payment processes and authorisations transparent and verifiable as well as log and store them as fully as possible in the user context. Within the context of EBICS, this applies to banks, but also to service providers that operate e.g. EBICS client applications.
In summary, PSD2 will not immediately have a direct effect on the EBICS specification itself. However, EBICS users must take the PSD2 into account within the usage context. The requirements of PSD2 must therefore be defined and implemented in good time for the operation and use of EBICS solutions. Time is ticking away.
Michael Lembcke
