„The SCA launch: a 5-minute instant soup?“
On 14.09.2019 the martyrdom of European payment diversity in electronic payments began
What has happened so far …
When the European Commissioners were considering an amendment to the PSD1, which came into force on 1 November 2009, the desire for greater security in electronic payment transactions was one of the driving factors, along with the idea of a level playing field in the payments market. Very noble and also challenging goals, which were certainly owed to the market events in the electronic payment industry.
Strong Customer Authentication (SCA), as one of the driving factors in the PSD2, should reduce the problem of uncontrolled misuse in electronic payments by allowing electronic payments to be doubly secured through independent authentication procedures. So far, a really commendable approach, which should help to get the fraud problem under control.
For the implementation, however, a definition of a catalogue of requirements was required, which had to describe exactly this so-called two-factor authentication (2FA) in the payment systems of the EEA payment service providers. In accordance with the motto “many chefs spoil the broth”, the star chefs of the European Banking Supervision Authority (EBA) were put in front of the stove in Europe, supposed to cook exactly this soup with the ingredients of the Strong Customer Authentication (SCA). The EBA soon found out that the ingredients for preparing the soup were not clear to them and asked his assistant chefs – the payment service providers – how the composition of the soup should be made. By the time this survey and information gathering was complete, our star chefs had written down their recipe in the Regulatory Technical Standards (RTS).
And now the great cooking began…
From water pot to finished soup …
On 27 November 2017, BaFin adopted the “Delegated Regulation (EU) 2018/389 of the Commission of 27 November 2017 supplementing Directive (EU) 2015/2366”, the German implementation of RTS. So the RTS now manifested the basic technical rules in the German text of the law that were supposed to make the SCA soup boil – and preferably with a pleasant taste for everyone. At the same time, 14 September 2019 was mentioned as the target date by which all EEA payment service providers must authenticate their electronic transactions according to a “new reading”.
However, card-based payment transactions are based on the networks of the large credit and debit card organisations (VISA, MasterCard, American Express, JCB, Diners, DK, etc.). Exactly these scheme operators have now been ordered to draft a set of rules which integrates the information on the adaptation measures required in the RTS into the processes of the individual parties. This implementation in the individual companies was implemented centrally with the introduction of the new 3D Secure 2.0 (3DS2) protocol. Unfortunately, however, there was a whole cookbook of rules per entity that had to be taken into account with the use of 3DS2. And as is usual with cookbooks, these are never congruent across the board – at best similar – which naturally led to a significant increase in the requirement criteria for technical implementation.
Now the big guessing began. The payment market is a very heterogeneous system in which many service providers have different tasks and responsibilities. The EBA, as the initiator of the amendment, only spoke and talks to the regulated payment institutions and service providers and prescribes the newly adopted procedures for them. Other service providers involved in the service chain (e.g. MPI/3DS2 operators, GDS (Global Distribution Systems) such as Amadeus or Sabre, etc.) are not or were not directly affected by the SCA requirement, but sometimes play a major role in technical/operational processing for the execution of authentication. The pure authentication process is therefore a regulated process, which should, however, sometimes be implemented by unregulated service providers – a contradiction in itself.
Many cooks spoil the broth…
The payment processing empire consists of many parties. There are the
- Merchants whose bad experience from 3DS1 could repeat or even increase their skepticism about negatively influencing the conversion rate with a new authentication process (Strong Customer Authentication).
- PSPs who are interested in a constant or increased number of transactions with the broadest possible use of their payment type portfolio
- The acquirers who do not want to lose any sales in the credit/debit card business with SCA either
- Schemes that see securing revenue as a top priority in the new authentication process, but at the same time must comply with regulatory requirements
- The issuers, who want to ensure the implementation of regulations in the field of payment. In addition to reducing the number of fraud incidents, this also implies securing the portfolio volume of their card portfolio.
All these parties and stakeholders are involved in the implementation of the SCA requirements, but sometimes pursue very different objectives and interests.
As a result, certain use cases are not considered at all or only peripherally by one or the other party. However, it is at least as irritating for the payment ecosystem that different stakeholders interpret and implement supposedly identical facts in different ways – and this in the absence of clear regulatory or defined specifications of the schemes.
A very prominent example of this is the very hotly discussed handling of key entry transactions in the travel and tourism industry in recent weeks. With this transaction type, card data is entered manually into the payment terminal at the point of sale or an online input screen (sometimes without the cardholder being present). Since neither the regulator describes these transactions as “electronic payments”, nor the card organisations themselves present an alternative to the SCA obligation, this increases the creativity of merchants (and thus the service providers serving the merchant, PSPs and acquirers) to circumvent the SCA obligation.
Unfortunately, there is no homogeneous procedure or guideline for implementing SCA logic that has been agreed with all parties.
The oversalted soup: not only a bitter aftertaste
Since 14.09.2019 the PSD2 and with it the strong customer authentication has officially entered into force and many open questions are still unanswered. The business transactions in the aforementioned travel and tourism industry are particularly affected by this.
The ignorance of the regulators – be it the EBA or the respective national regulator (BaFin) – have fueled the uncertainty in the market in recent weeks through its reluctance to make decisions rather than to rebute it.
Unfortunately, the result is not quite unexpected. Large and well-known players in the payment ecosystem such as Amadeus and Galileo have already informed their customers that their systems will not be able to fully meet SCA requirements by 14 September 2019. Although this is only a restrictive statement, it nevertheless shows that the time period for implementing the outstanding questions was not sufficient. And this is exactly what BaFin has not yet wanted to take into account, despite the ever louder signals from the market and also from the companies regulated by BaFin.
The previously mentioned 3DS2 protocol has a decisive advantage compared to 3DS1, which raises the justified hope that a drop in the conversion rate can at least be avoided: the so-called “frictionless authentication”.
In this process, the merchant provides the issuer with a complete set of additional, risk-relevant information that the issuer can evaluate itself and then approve the transaction or payments without interacting with the cardholder. On the one hand, this procedure removes the liability of the merchant for the loss event and transfers it to the issuer, and on the other hand does not require any further interaction with the cardholder, which could possibly lead to a termination of the transaction.
But since – as things stand today – neither the issuers know exactly which parameters for evaluation in their fraud prevention systems will really have a positive effect on smooth transaction processing, nor the merchants are able to transmit the optional fields required for the issuers in the authentication message across the board, the market runs the risk of not using this powerful instrument at all. The PSD2 guidelines should avoid exactly this.
And it is precisely at this point that it would once again be necessary to have a regulative specification through the corresponding schemes, which would put the issuers in a uniformly defined state.
Seasoning of the soup and its improvement
Ultimately, however, the BaFin gave in on August 21 – at least for the e-commerce sector – and announced in its statement that it would tolerate e-commerce transactions that had not (yet) been SCA-authenticated for an indefinite period of time. However, the SCA obligation was by no means lifted as of 14 September 2019. According to our star chef, the BaFin will never give up its SCA soup, but rather try to make it “bearable” for the consumer by skillfully tasting it.
However, BaFin must not forget when “tasting” that it is only one of the assistant cooks of the SCA soup. An inhomogeneous handling in the EEA of the toleration regulation described above generates an even greater sense of uncertainty than is already the case. Nationally differing regulations would confuse both the merchant and the cardholder to the maximum. To avoid precisely this situation, a much clearer EBA specification would be much more helpful.
Therefore, it remains to be seen to what extent this will be achieved or implemented.
Summary of the cooking course
As already mentioned, the uncertainty on the market in dealing with the use of SCA has clearly stimulated the creativity of the merchants due to the acute urgency before the implementation on 14.09.2019. This sometimes goes so far that in the absence of suitable SCA alternatives, so-called “alternative payment methods” (such as PayPal, Paydirekt, Wallet systems, etc.) are given preference over SCA-liable card transactions. The operators of these alternative payment methods observe this extremely favourable effect with a broad smile for them, as without extensive marketing expenditure they do profit from the lack of coordination and the weaknesses of the regulatory system without own effort from the competitors. And this was – and cannot have been – in the spirit of the regulator when the SCA obligation was developed (we remember the goal of increasing competition).
Even if the SCA obligation has now entered into force on 14 September 2019 – albeit in a weakened or delayed form – the toleration period with regard to the PSD2 guidelines should be used sensibly. Above all, one should learn from the mistakes since the release of the RTS. And this learning effect must start with all parties involved, so that after the end of the toleration period there is no D-Day again and nobody knows how and when to prepare for it. The alarm signals for such a situation are already red, as merchants have already announced that they will only activate the SCA obligation at the end of the toleration period, in order not to suffer a competitive disadvantage against the competition themselves prematurely.
Coming back to the initial concern of the SCA obligation – namely the reduction of fraud and thus the safeguarding of cardholder integrity – it can only be stated at this point that the EBA, with its chef assistants, the national regulators, has led the “SCA project” up the garden path for lack of clearly defined specifications. Let us hope that the regulators have learned from the past months.
Only a common approach involving all stakeholders in the payment ecosystem can guarantee the desired success with regard to rule-compliant SCA use. It would be a pity if the opportunities opened up by SCA for clear security and also for a customer and cardholder-friendly authentication procedure could not be exploited due to exceptions and the ignorance or decision-failure of the competent authorities.
[pissc number=20 cat=”Articles” the_more=”Read the full post →”]