Strong Customer Authentication in Practice

Transcription

1 Strong Customer Authentication in Practice A Signicat whitepaper June

2 This white paper has been produced on behalf of Signicat by Norfico ( and Consult Hyperion (

3 Table of content Foreword 4 From PSD1 to PSD2 5 PSD2 5 Definitions of roles in PSD2 6 PSD2 timeline 7 Strong Customer Authentication 8 what and why? Strong Customer Authentication 14 in practice How Signicat can assist 16 Conclusion 19 Get in touch 20 About Signicat 20

4 Foreword The clear majority of reports and white papers written about PSD2 up until now have been focused on how Article 66 and 67 (relating to Access to Account) will potentially cause new challenges for the banks, but will also represent exciting opportunities, providing the banks embrace PSD2 proactively. The regulation will also enable the fintechs of the world to tap into one of the bank s most sacred areas the customer accounts and to start competing with the banks in a whole new way. These topics are important and exciting, but for the opportunities presented by PSD2 to be realised, some important questions must be answered and some basic problems must be solved. Especially within the area of identity and authentication, and this white paper discusses those questions and problems. This white paper tackles a number of questions relating to another very important part of PSD2, which is the directive s requirements for Strong Customer Authentication (SCA). Why is the directive putting so much emphasis on SCA? How are the new SCA requirements going to work in practice? Who will perform SCA? And who has the competencies to assist them and ensure the best possible user experience? Since the SCA requirements are not going to go away, it is necessary to discuss how to handle this new situation going forward. In this whitepaper, Signicat puts forward its view on this and as well as some tangible suggestions on adoption of this new regulation. Before going into the discussion about identity and authentication in connection with PSD2 in depth, we would like to give a quick introduction to the new directive and an overview of the major news, the most important roles and their definitions, and the basic timeline for the enforcement of the directive. 4 A Signicat whitepaper June 2017

5 From PSD1 to PSD2 PSD1 The first Payment Service Directive - Directive 2007/64/EC - from the European Commission became effective in 2007 and was transposed to the national laws throughout the European Union two years later in November The primary aims of the PSD were to start opening the European payment market and increase competition. Furthermore, PSD created the legal platform for SEPA 1. An European Commission press release in December 2007 said this about the aims of the directive: The aim of the PSD is to ensure that electronic payments within the EU in particular, credit transfer, direct debit and card payments become as easy, efficient, and secure as domestic payments within a Member State, by providing the legal foundation to make the Single Euro Payments Area (SEPA) possible. The PSD will reinforce the rights and protection of all users of payment services (consumers, retailers, large and small companies and public authorities). 2 PSD2 1. The overall gains expected from SEPA for all stakeholders has been evaluated at 21.9 billion per year by PWC in 2014 confirming a Cap Gemini study of 2008 evaluating these benefits at 123 billion cumulated over 6 years. payments/sepa/index_en.htm 2. press-release_ip _ en.htm?locale=en Recognising that significant market changes and rapid new technological developments had made the first PSD insufficient, in 2013 the EU Commission proposed a Revised Directive on Payment Services - now known as PSD2 (Directive (EU) 2015/2366). PSD2 was adopted by the European Parliament in October 2015 and by the Council of The European Union one month later, and in January 2016 it was published in the Official Journal of the EU (OJEU). PSD2 should be implemented as national law in all European Union member states by 13 January While the first payment service directive had its focus on harmonising the operational side of payments, PSD2 is set out to radically change the foundation of financial services, as it is set to drive innovation and competition by enforcing open access to the core part of the banking and payments infrastructure. 5

6 The introductory recitals 4 and 5 of PSD2 explain the reasons and background of the revised directory by saying that: (4) Significant areas of the payments market, in particular card, internet and mobile payments, remain fragmented along national borders. Many innovative payment products or services do not fall, entirely or in large part, within the scope of Directive 2007/64/EC. (5) The continued development of an integrated internal market for safe electronic payments is crucial in order to support the growth of the Union economy and to ensure that consumers, merchants and companies enjoy choice and transparency of payment services to benefit fully from the internal market. 3 Definitions of roles in PSD eu/legal-content/en/ TXT/PDF/?uri=CE- LEX:32015L2366&from=- DA, p eu/legal-content/en/ TXT/PDF/?uri=CE- LEX:32015L2366&from =en, p eu/legal-content/en/ TXT/PDF/?uri=CE- LEX:32015L2366&from =DA, Definitions, (14), s. 57 AISP Account Information Service Provider An AISP is a Third-Party Provider (TPP) who, with access via a standardised interface (e.g. an API), can draw information from a customer s bank account in a bank. This could be for instance Personal Finance Management (PFM) tools or lending companies who will use the access to create a precise credit scoring of a customer. ASPSP Account Servicing Payment Service Provider An ASPSP is a payment service provider providing and maintaining a payment account for a payer. 4 In most cases this will be a bank, but in the PSD2 there is a consistent division of roles and players. PII Payment Instrument Issuer Not only ASPSPs issue payment instruments. There is an increasing number of merchant issued payment instruments like the Amazon credit card. PII can utilise AISP or PISP (see below) to conduct fund check and/ or transactions. PI - Payment Instrument The directive defines the PI as a personalised device(s) and/or set of procedures agreed between the payment service user and the payment service provider and used in order to initiate a payment order. 5 PISP Payment Initiation Service Provider A PISP is a Third-Party Provider (TPP) with access via a standardised interface (e.g. an API) can carry out payments directly from a customer s account through the banks own Account to Account (A2A) infrastructure. Examples of this kind of services are Sofort (owned by Klarna) and Trustly, who already today offer this type of payment directly from consumers accounts. However, these services are currently not regulated and in their current form, bank cannot tell the difference between a consumer initiated payment and one initiated by a third party. 6 A Signicat whitepaper June 2017

7 PSP Payment Service Provider The Directive explains that a payment service provider means a body referred to in Article 1(1) or a natural or legal person benefiting from an exemption pursuant to Article 32 or 33; Article 32 under Section 4 about exemption explains that the body or natural or legal person do not have to be a Payment Service Provider if: the monthly average of the preceding 12 months total value of payment transactions executed by the person concerned, including any agent for which it assumes full responsibility, does not exceed a limit set by the Member State but that, in any event, amounts to no more than EUR 3 million eu/legal-content/en/ TXT/PDF/?uri=CE- LEX:32015L2366&from=- DA, Section 4, Exemption, Article 32, p eu/legal-content/en/ TXT/HTML/?uri=CE- LEX:32015L2366&from=- DA, Article 4, Definitions, (10) PSU Payment Service User A PSU is a legal entity e.g. an individual or a corporation with an ASPSP account making use of a payment service in the capacity of payer, payee, or both. 7 Again an example of a role based definition as this in most cases will mean a consumer. TPP Third Party Provider A TPP is a third party, who is granted access to a bank account either as an AISP or a PISP. This is not to be confused with the role of Trusted Third Party (TTP) used in cryptography. PSD2 timeline PSD2 enters into force in the EU Deadline for responses to EBA s consultation paper on RTSs for SCA Final draft on RTSs for SCA from EBA Deadline for all EU member states to adopt PSD2 on a national level Appliance of PSD Deadline for responses to EBA s discussion paper on RTSs for SCA Q (expected) Publication of the EBA Guideline for SCA and XS2A Q (expected) Application of the RTSs for SCA and XS2A 8. eu/legal-content/en/ TXT/?uri=uriserv%3AOJ.L_ ENG 9. Still possible to surcharge: Three-party schemes like American Express and Diners Visa and MC in case the underlying account is a corporate account. The most important news PSD2 along with the Interchange Fee Regulation (IFR) 8 introduces a long list of changes and news within areas such as liability (Article 74), capping of interchange rates and a general ban of surcharge (Article 62 paragraph 4). But the most important and talked about news relates to two other areas, Access to Account and Strong Customer Authentication: 1) The so-called Access To Account (XS2A) including a couple of new roles Payment Initiation Services Providers (PISP) and Account 7

8 10. eu/legal-content/en/ TXT/PDF/?uri=CE- LEX:32015L2366&from=- DA, p. 92 and p. 93 Information Service Providers (AISP) introduces a new requirement for banks to allow these new service providers access to customers bank accounts as described in the directive s Articles Article 66. Rules on access to payment account in the case of payment initiation services. 1. Member States shall ensure that a payer has the right to make use of a payment initiation service provider to obtain payment services as referred to in point (7) of Annex I. The right to make use of a payment initiation service provider shall not apply where the payment account is not accessible online. And: Article 67: Rules on access to and use of payment account information in the case of account information services. 1. Member States shall ensure that a payment service user has the right to make use of services enabling access to account information as referred to in point (8) of Annex I. That right shall not apply where the payment account is not accessible online. 10 This demand for the banks to open up their accounts has been described and analysed many times already and is not the main subject for this whitepaper. But tightly attached to the Access To Account requirement is obviously a deep concern about security, which leads us to the heart of the matter of the following chapters: 2) The new requirements for Strong Customer Authentication or SCA (article 97, article 98, and article 74 paragraph 2), In the following, we are going to analyse the Strong Customer Authentication requirement further and discuss how this is going to play out in practice going forward. Strong Customer Authentication what and why? The basic reason for the European Union s requirement of Strong Customer Authentication - Two Factor Authentication - in PSD2 is to protect consumers against fraud. The PSD2 aims to ensure that all payment services offered electronically are carried out in a secure manner, adopting technologies able to guarantee the safe authentication of the user and to reduce, as much as possible, the risk of fraud. That is why the need for Strong Customer Authentication in payments is central to PSD2 as defined in Article 97 (see next page). 8 A Signicat whitepaper June 2017

9 Article 97 in PSD2 Authentication 1. Member States shall ensure that a payment service provider applies strong customer authentication where the payer: (a) accesses its payment account online; (b) initiates an electronic payment transaction; (c) carries out any action through a remote channel which may imply a risk of payment fraud or other abuses. 2. With regard to the initiation of electronic payment transactions as referred to in point (b) of paragraph 1, Member States shall ensure that, for electronic remote payment transactions, payment service providers apply strong customer authentication that includes elements which dynamically link the transaction to a specific amount and a specific payee. 3. With regard to paragraph 1, Member States shall ensure that payment service providers have in place adequate security measures to protect the confidentiality and integrity of payment service users personalised security credentials. 4. Paragraphs 2 and 3 shall also apply where payments are initiated through a payment initiation service provider. Paragraphs 1 and 3 shall also apply when the information is requested through an account information service provider. 5. Member States shall ensure that the account servicing payment service provider allows the payment initiation service provider and the account information service provider to rely on the authentication procedures provided by the account servicing payment service provider to the payment service user in accordance with paragraphs 1 and 3 and, where the payment initiation service provider is involved, in accordance with paragraphs 1, 2 and 3. Article 4 of PSD2 lists all definitions applicable for the directive. Definition number 30 concerns Strong Customer Authentication: (30) strong customer authentication means an authentication based on the use of two or more elements categorised as knowledge (something only the user knows), possession (something only the user possesses) and inherence (something the user is) that are independent, in that the breach of one does not compromise the reliability of the others, and is designed in such a way as to protect the confidentiality of the authentication data; Knowledge can be a PIN or static password. Possession can be a payment card, a key fob, or a phone as a receiver for a one-time password (OTP). And Inherence can be a biometric element like iris scan or fingerprint used in a solution like Apple s Touch ID. Two of these elements in combination constitutes a strong customer authentication. Main Authentication Methods are: Passwords and PINs (Knowledge) Mobile banking login (Knowledge and Possession) One Time Passwords via SMS or Mobile Banking or Telephone Call back (Possession) Fingerprint, e.g. Apple Touch ID (Inherence) Voice Recognition (Inherence) Time-based One Time Password hardware devices e.g. Key fob (Possession) 9

10 11. documents/10180/ / Final draft+rts+on+ SCA+and+CSC+under +PSD2+%28EBA-RTS %29.pdf, p. 3 And SCA must be performed for all relevant remote access requests: PSD2 Push Payments Card Payments Electronic Funds Transfer (EFT) Remote Direct Debit Initiation Internet/Mobile Payments 3rd Party Account Queries Changing Account Details Anything else that creates risk Final SCA RTS Article 98 of the directive requires the development of a set of Regulatory Technical Standards (RTS): EBA shall develop, in close cooperation with the ECB, draft Regulatory Technical Standards specifying the requirements of the strong customer authentication (SCA). Since EBA received 226 comments to its SCA Consultation Paper published in August 2016 and were obliged to take all of them into consideration and give back written replies to everyone, it comes as no surprise that the final Draft Regulatory Technical Standards on Strong Customer Authentication and common and secure communication under Article 98 of Directive 2015/2366 (PSD2) was released with some delay when it arrived on 23 February And in the Executive Summary of the RTS, EBA explains how they have had to make difficult trade-offs between the various, at times competing, objectives of PSD2, including enhancing security, promoting competition, ensuring technology and business-model neutrality, contributing to the integration of payments in the EU, protecting consumers, facilitating innovation and enhancing customer convenience. 11 Original exemptions from SCA The August 2016 EBA Consultation Paper on the draft SCA RTS lists four exemptions for the use of SCA. The exemptions are in cases where: 1. the payer accesses exclusively the information of its payment account online, or the consolidated information on other payment accounts held, without disclosure of sensitive payment data. [e.g. accessing an aggregated spending overview in a PFM tool]. 2. The payer initiates a contactless electronic payment transaction at a point of sale within the limits of both the following conditions: i. the individual amount of contactless electronic payment transaction does not exceed the maximum amount of 50 EUR; ii. the cumulative amount of previous non-remote electronic payment transactions initiated via the payment instrument offering a contactless functionality without application of strong customer authentication does not exceed 150 EUR 10 A Signicat whitepaper June 2017

11 3. the payer initiates online a credit transfer where the payer and the payee is the same natural or legal person and the payee s payment account is held by the payer s account servicing payment services provider; 4. the payer initiates a remote electronic payment transaction where all the following conditions are met: i. the individual amount of the remote electronic payment transaction does not exceed the maximum amount of 10 EUR; and ii. the cumulative amount of previous remote electronic payment transactions initiated by the payer without application of strong customer authentication does not exceed 100 EUR. 12 The intention behind Article 97 is to battle fraud in e-commerce which is certainly a noble cause since the European level of fraud has increased rapidly in recent years. The problem with introducing Strong Customer Authentication as default for all online payment transactions is that it takes away the flexibility of a risk-based fraud security that allows the entity performing SCA to judge by themselves and differentiate in security level between different purchase scenarios. For instance, the organisation Ecommerce Europe explained the problem in this way: documents/10180/ / Consultation+Paper+on+ draft+rts+on+sca+and+ CSC+(EBA-CP ).pdf, p com/hubfs/white_papers/ Web%20Fraud%20Prevention%20and%20Online%20 Authentication%20Mar- ket%20guide% pdf, p There were also a large number of responses on other existing exemptions, seeking clarification, pointing out technical unfeasibility, and requesting further exemptions to accommodate existing situations. The EBA has reflected on these, concurs with the views expressed in relation to a number of the comments and has made some amendments accordingly in some areas. documents/10180/ / Final+draft+RTS+ on+sca+and+csc+un- der+psd2+%28e- BA-RTS %29.pdf, p. 10. Ecommerce Europe believes that this too strict and burdensome rigid focus on strong customer authentication would have a damaging impact on the future competitiveness of the European e-commerce sector, as it fails to strike a balance between ensuring customers security and checkout convenience. 13 Additional exemptions in the final RTS In the final draft RTS, EBA has taken into consideration some of the concerns expressed in the many responses to the SCA Consultation Paper 14 and made some adjustments and amendments to the list of exemptions. One of the adjustments is that EBA has raised the SCA limit for payment transactions from EUR 10 to EUR 30, which corresponds to what we know from contactless POS payments today. Furthermore, the cumulative amount has been raised from 100 to 150 EUR. This means that for transactions of 30 EUR or less, risk-based authentication is acceptable under certain restrictions. In the former edition of the RTS, risk-based authentication was not an option at all. Another update or amendment to the list of exemptions concerns payment transactions via unattended transport and parking terminals, which were not mentioned in the previous draft version of the RTS: 11

12 The EBA has added a new exemption for unattended terminals for fares related to transport and parking services, since it may not be proportionate and may also not be in the general public interest for operational (e.g. to avoid queues and potential accidents at toll gates) or security reasons (e.g. the risk of shoulder surfing) Rationale 25: Final+draft+RTS+on +SCA+and+CSC+un- der+psd2+%28e- BA-RTS %29. pdf, p. 10 Obviously, these new exemptions reduce the total number of future SCA transactions to some extent, but compared to the number of SCA transactions performed today the increase will be significant nonetheless. And the entities handling the SCAs could very well be facing some serious challenges when it comes to performing a smooth, efficient and userfriendly SCA execution towards the consumers (or PSUs to stay in PDS2 terminology). We will come back to that later in this white paper when we discuss the complex questions that the SCA requirements trigger, but before that, we will look at another important part of SCA liability. A new option for SCA liability shift As described earlier, PSD2 creates four new business entities known as Payment Service Providers: ASPSP (Account Servicing PSP accountholding institution i.e. a bank), PISP (Payment Initiating Services Provider - can initiate push payment from a bank customer account to 3rd-party account), AISP (Account Information Services Provider - can query bank customer account details), and card issuing PSPs (who can issue cards and use a bank customer account as the funding source). In the first edition of the PSD2 SCA RTS, the SCA liability was entirely with the banks. But the final RTS seems to allow for a possible liability shift from the banks to the TPPs and allows both payer PSP (ASPSP or a card issuing PSP) and payee PSP (an acquirer, PISP or AISP) to perform SCA (or risk based authentication if the TPP or PSP assume full liability). Even though the RTS text does not state this in a very precise and clear way this is our interpretation based on hints and indications throughout the text. We and others are seeking clarification on this point. For instance, in comment 55 and comment 295 it says that the payee PSP can trigger the risk-based exemption, which would not be possible if the liability were not with the payee PSP that is an acquirer, a PISP or an AISP. Comment 295 says: 12 A Signicat whitepaper June 2017

13 The EBA also explains in rationale 24 that its interpretation of PSD2 suggests that the transaction-risk analysis (TRA) exemption from SCA can be applied by the payee s and payer s PSPs, but not by the payer or the payee themselves. The liability rules also suggest that the payer s PSP should have the last say on whether or not the TRA exemption is used for a specific transaction documents/10180/ / Final+draft+RTS+on +SCA+and+CSC+un- der+psd2+%28e- BA-RTS %29.pdf, p documents/10180/ / Final+draft+RTS+on +SCA+and+CSC+un- der+psd2+%28e- BA-RTS %29pdf, p ecommerce-checkout-abandonment-rate/ The reasoning in this interpretation is also supported by other passages in the RTS for instance, in Rationale 14, which states that the ASPSP must provide SCA, but by inference implies that it could be done by another PSP: In relation to how Article 97(1)(b) should be applied by PSPs for the provision of payment initiation services (PIS), the EBA understands, as stated in the CP, that PIS Providers have the right to rely on the authentication procedures provided by the ASPSP to the user. In such cases, the authentication procedure will remain fully in the sphere of competence of the ASPSP. 17 The underlined phrase implies a right to rely on ASPSP authentication, but not an obligation. This possible shift of SCA liability is important for several reasons. Allowing the TPPs provided that they meet the security demands from the banks to take on the liability triggers new dynamics in the market. While performing SCA might be a potentially interesting opportunity for some categories of TPPs, seen from the banks perspective this may introduce new risks both in terms of data security and the ability to keep and develop trust based relationships with the end customers. But who would want to take over the SCA liability and why? A typical example would be a large web shop that wants to make sure it gives its customers the best possible user experience. The highest possible conversion rate is what all web shops aim for, and one of the most costly problems in today s e- and m-commerce is high checkout abandonment rates perhaps because of lack of trust or too complicated a checkout process. A 2016 analysis by American Compass found that the average checkout abandonment rate in e-commerce was as high as 25%: Stores operating in the Food and Drinks segment have the lowest abandonment rates, with an average of 19%. Top Food and Drinks performers have an abandonment rate of 7% or less. In contrast, Electronics stores experience a much higher abandonment rate (28% on average), while top performers have an 18% average. 18 Taking full control of the SCA part of the checkout process would enable international e-commerce businesses to design their own SCA solutions 13

14 and deliver the same smooth or as smooth as possible - SCA user experience to all customers across Europe. And as the option for the shift of liability shows, PSD2 SCA is not just a compliance issue, and it could and probably will - have significant business impact. Strong Customer Authentication in practice Despite the RTS s exemptions from SCA - as described above - PSD2 will most likely result in an explosion of transactions requiring SCA as soon as the APIs enabling Access to Account are fully implemented in the banks and the TPPs have had some time to promote their new services (AIS and PIS) in the markets across Europe. But have the banks in Europe started preparing for this? Will they be ready meaning SCA compliant in time? And will they be able to handle possibly millions of new SCA-based transactions from AISPs and PISPs? And how about the TPPs who might want to take on the SCA liability, are they capable of doing so, do they have the necessary technical abilities to develop SCA solutions themselves and handle the transactions? Banks will also have to assess their customer care processes, services and systems to support the more frequent use of the bank s SCA solution and the likely increase in need for identity reassurance and credentials resetting. Banks under time pressure If we start with the banks, they have some tough deadlines ahead of them. PSD2 must be implemented in national law in all European Union member states by January of next year (2018). And no later than eighteen months after the approval of the RTSs from EBA, all European banks must comply with these. The compliance task for the banks focuses on two parts; SCA, and the much-discussed Access to Account (XS2A). The largest European banks are already preparing for PSD2 and have been doing so for a while. They know that PSD2 is one of the most disrupting, almost revolutionary, pieces of regulation in recent years and they have dedicated teams working PSD2. But the large banks represent only the very tip of the iceberg, and below we will find the majority of European banks have either done nothing at all so far, or have only just started sketching a PSD2 strategy. This large group of several thousand small and medium European banks lack both resources and knowledge about how to comply with the PSD2 requirements. They have too much on their plate already just taking care of business and what their capabalities in terms of PSD2 will be limited. For most of these banks to be PSD2 compliant in time both in terms of 14 A Signicat whitepaper June 2017

15 Access to Account for TPPs and regarding SCA, they will need assistance from their solution providers, which will be data centres or PSPs. They will not be able to cope with the requirements and the deadlines and the necessary technical setups on their own. Regional differences That being said, we do see significant regional differences within the Europe Union regarding digital readiness and as part of that ability to handle the SCA challenge. In general, the Eastern and Southern part of Europe lack behind the Northern part of Europe, and in particular the Nordic countries take the European lead on digitisation including digital infrastructure and SCA solutions like the national e-id schemes NemID in Denmark and BankID in Norway and Sweden. But even in the Nordic countries, PSD2 represents a considerable challenge for small and medium banks. Even though they are familiar with SCA through their national eids, they are not necessarily prepared for the huge increase of SCA required transactions that PSD2 is expected to trigger. Flexible timeline for the TPPs For the TPPs who would like to take on the SCA liability because it might enable them to offer a smoother user experience at the SCA part of the checkout process, there are no deadlines as such. They do not have to be ready at any particular date like the banks, but we believe that a group of the largest and most ambitious TPPs, who want to take on the SCA liability might decide to move fast, because they have the resources and know the importance of steadily optimizing the online user experience and decreasing the checkout abandonment rates as much as possible. Some of these will probably be large e-commerce merchants who want to be PISPs themselves. For a merchant like Amazon, becoming a PISP would be an obvious choice and securing the best possible checkout user experience by taking on the SCA liability would most likely also be a highly tempting option. The largest TPPs might want to develop their own SCA solution and SCA process, but the vast majority of the TPPs who decide to take on the SCA liability will need and want a trusted service provider to handle the practical part of the SCA on their behalf. They lack skills and experience in the authentication field, but they still see a purpose in taking control rather than leaving it up to the banks to decide the SCA process and solution. This control over the flow is important to ensure the smoothest possible onboarding and authorisation process. 15

16 How Signicat can assist As underlined several times already in this whitepaper, the number of transactions requiring strong customer authentication is expected to grow significantly going forward as a direct consequence of PSD2. This will be a challenge for a very large section of the approximately 4,000 European banks, and for an unknown number of TPPs, who want to make use of opportunity in the final RTS on SCA to take over the SCA liability. TPPs could probably have a number of reasons for doing so, but one obvious reason for a large e-commerce merchant acting as a TPP could be to create a better user experience than the merchant s bank would be able to offer. All these parties within the PSD2 ecosystem share the same challenge, which is to handle SCA in the most efficient, flexible, user-friendly and inexpensive way - and none of them has SCA as a core competency. This scenario obviously creates an opportunity for a specialist to step in and offer a cross-european Authentication as a Service solution, which will effectively ease the banks and the TPPs PSD2 SCA pains and enable them to focus on their core businesses. And this is exactly what Signicat intends to do. Based on ten years of experience working with two-factor national eid schemes, Signicat has developed a new platform for ID-service - an online identity hub - called a Digital Identity Service Provider (DISP), and through the DISP Signicat offers Identity On Demand services for customers, regardless of geography or e-id. Signicat today has more than 200 European customers among banks, financial companies, insurance companies and government agencies connected to its identity hub or DISP, customers trust Signicat with the responsibility of authenticating users, providing electronic signing, identity proofing and document preservation. And since strong customer authentication is an integrated part of the DISP-platform services, Signicat already has the ideal base for scaling its services to European banks and TPPs in need for SCA assistance. Basic DISP services to banks In the future, Europe s 4,000 banks are mandated by PSD2 to offer SCA services to all authorised TPPs, which requires the banks themselves, or their current platform or service providers, to implement and maintain these SCA services. Or they can choose to outsource the SCA task to Signicat, make use of Signicat s DISP platform and Authentication as a Service solution, and free up time and resources to focus on their core business instead. 16 A Signicat whitepaper June 2017

17 PSD2 ARCHITECTURE (PAYMENT) Request purchase (value, payee) Token for payment Request purchase (value, payee, token) PISP ASPSP (Bank) Request purchase (value, payee, ASPSP) e-tailer Identification DISP Request purchase (value, payee, ASPSP) Authentication Confirmation (payee + value) (*) Identification (*) Confirmation can happen on other channels: but the payer must confirm thepayment value and payee on a channel that is different from the one they initiated on The DISP platform will be providing identification and authentication of individual customers and even allow siloed information to be accessed by other banking areas. The DISP also opens the possibility of banks offering identity services to third parties e.g. to AISPs and PISPs. Furthermore, the penalties for ASPSPs who fail to meet fraud levels for transactions are heavy, and if a DISP helps reduce this threat, then it will be hugely valuable. Finally, since the banks by default will hold the key to SCA under PSD2, the banking customers will be highly dependent on the bank s ability to offer a satisfying user experience whenever SCA is necessary which could easily be several times a week or more for each customer. Being able to deliver a smooth SCA user experience could easily become an important competitive parameter for banks in the near future, and a reason for a customer to choose one bank over another. Basic DISP services to TPPs As described earlier in this white paper the new PSD2 SCA RTS allows the TPPs to perform SCA both payer PSP (ASPSP or a card issuing PSP) and payee PSP (an acquirer, PISP or AISP). PSD2 ARCHITECTURE Request purchase (value, payee) Token for payment Request purchase (value, payee, token) PISP ASPSP (Bank) Authentication Confirmation (payee + value) (*) Request purchase (value, payee, ASPSP) Identification DISP Request purchase (value, payee, ASPSP) Identification e-tailer (*) Confirmation can happen on other channels: but the payer must confirm thepayment value and payee on a channel that is different from the one they initiated on The most obvious reason for a TPP to choose to take on the SCA responsibility and liability would probably be to optimise the user 17

18 experience for the end customers. The challenge, though, for the intermediaries, especially new TPPs, will be that they have limited capability and reach in this area of digital identity, and therefore the DISP platform will support their needs and help them scale. Furthermore, the fraud level restriction applies to any TPP providing customer authentication, so once again enhanced identity services will be extremely valuable if they reduce or help manage fraud levels. Aggregated DISP services The Signicat DISP platform provides easy access for banks and third parties to identity services. The DISP platform will significantly increase both banks and TPPs ability and flexibility in terms of using digital identity in their business applications and processes. This is an extension of the existing identity services that Signicat offers already e.g. a private sector equivalent of using e-id solutions like the national solutions BankID or NemID from the Nordics. And it will allow merchants or PSPs to use Signicat s solutions to authorise PSD2 push payments even where they are not directly connected to a bank. 18 A Signicat whitepaper June 2017

19 Conclusion The requirement for Strong Customer Authentication in the PSD2 is made with the best intention from the Commission s side to improve security and reduce fraud in digital transactions to the benefit of the European consumers. The requirements in the directive will make it necessary for all European banks to initiate a process to assess the impact and possibilities in the realm of PSD2 in general, and SCA in particular. There is no option of doing nothing. The fact that authentication will play a much more central role in the banks services with the implementation of PSD2 changes the choice of solution from a purely technical choice to a strategic choice. A flexible platform for identification, authentication and authorisation will be essential to realise the intentions and possibilities within PSD2. 9 STRATEGIC PSD2 ISSUES TO CONSIDER Banks (ASPSPs) should: Analyse their current SCA and eid solutions in light of PSD2 Are the solutions PSD2 compliant? Do they have the capacity needed in case of a future massive scale of SCA transactions following PSD2? Do the designs of the solutions offer a smooth user experience? Analyse and assess SCA requirements and options Analyse their security setup related to API access Third Party Providers (TPPs) should: Assess the integration options towards ASPSPs Ensure authentication processes towards ASPSPs Asses how different ASPSPs SCA solutions fit into the flow of the service the TPPs want to provide All players should: Map the requirements of PSD2 to their existing and future business Conduct thorough risk analysis Assess potential suppliers and partners 19

20 Get in touch Lars Møller Kristensen Mobile: Web: About Signicat Signicat is one of the leading providers of electronic identity and electronic signature solutions in Europe. The company, founded in 2007, delivers online trust based services to the public and private sector globally. The solutions fulfill operational capabilities in line with international standards and requirements, such as Privacy, Anti-Money Laundering (AML) and Anti-Terrorist legislation and regulations, as well as Know Your Customer (KYC) requirements for onboarding of new users.