Security in open banking, new authentication methods
Security in open banking is an aspect that is not always explored in depth nor given the necessary attention because people look more at the revolutionary side of this phenomenon and much less at the equally disruptive but perhaps, in appearance, less exciting, security side. However, if you work in the fintech sector and want to learn about all the opportunities that have arisen as a result of the introduction of PSD2, you cannot ignore all that security in open banking entails.
Open Banking and the new rules
Before delving into what has happened from a security perspective, it is worth reiterating what lies behind the term open banking and what new players are coming to play with this innovation. Open banking refers to a new, more open, data-driven financial model that encourages competition benefitting the end user. The objective with which it was introduced through PSD2 was to make online payments simpler but also, as we shall see, more secure.
However, this phenomenon does not only concern banks, it has an inclusive character and allows previously excluded actors to participate in the financial services market in an innovative and open way. This is because the new legislation obliges banks to share both their customers’ data, subject to their consent, and their APIs, and this allows third parties to compete with banks in some respects. But who are the third parties?
Third parties in open banking
There are three types:
● AISPs provide services that have access to customers’ banking information, can analyse their spending behaviour, aggregate periodic spending information and aggregate banking data from different financial institutions into a single platform.
● PISPs provide services to access customers’ banking information and can also withdraw money from the account and send a payment.
● And then there are CISPs that provide payment services based on debit cards associated with a current account that is accessible online and linked to a credit institution other than the one that issued the card.
New security features in open banking
Now that we have introduced the new players on the financial scene, alongside the traditional players, we can discover the new security features in open banking that obliges them to strengthen the minimum standards for digital payments.
It is PSD2 itself that very explicitly introduces new authentication systems for these operations that have now become part of everyday life, even if we are not always aware of it as users. These are the 3D Secure 2 protocol and Strong Customer Authentication (SCA).
Security in open banking: 3D Secure 2 protocol
Based on XML, this protocol increases the level of security by inserting an intermediate step between the payment request and the actual debiting of the card. With the 3D Secure 2.0 system, merchants securely send more than 100 pieces of information per transaction to the acquirer’s bank, which can assess the risk level of the transaction and approve it or, if there is insufficient data to do so, request further information. If this is the case, the 3D Secure 2.0 system carries out further checks, which can be done by SMS but also by biometric authentication, for example. All this does not burden the end user experience at all thanks to this very protocol, which ensures dynamism and security and allows new authentication methods based on the use of Strong Customer Authentication to be used
Security in open banking: Strong Customer Authentication
The new security procedures in open banking include this new way of authentication which, before making a payment, verifies the identity of the customer using two different security parameters. This is why it is ‘strong’. These parameters can be:
● Something the holder knows (pin or password);
● Something the holder possesses (smartphone or token);
● A unique and specific physical characteristic of the holder (for now the fingerprint but tomorrow also the voice? Or face?);
If we take a closer look at the new security rules for open banking, we discover that this type of verification is not always necessary, but only in certain situations, in customer-initiated payments (CIT Cardholder Initiated Transactions) such as those on e-commerce sites.
However, there are many situations in which the security of open banking does not include the SCA, starting from when MITs (Merchant Initiated Transactions) are carried out. That is, transactions initiated by the merchant without the active participation of the cardholder, or transactions carried out remotely by the merchant by manually entering the card data on a virtual terminal.
In addition to these two types of transactions free of the ACA, there are other exceptions provided for which concern amounts less than EUR 30, low-risk transactions or those directed to reliable beneficiaries indicated by the customer himself and for which the ACA is only required for the first transaction.
