Payment Services Directive II (PSD2)
Important and potentially impactful changes have been taking place in the area of international payments. If your business relies on international commerce, and certainly if you are helping to facilitate it, this is a topic that you need to be on top of. As usual, Softjourn can help. All the excitement is around the geeky-sounding PSD2, short for the equally geeky-sounding Payment Services Directive II. And it’s all centered around Europe. Europe knows a thing or two about how to get countries to work together (and how not to!). The first Payment Services Directive applied this knowledge to finance, standardizing rules for payments within Europe so that they are regular and predictable, and open to new players. Now, with PSD2, the Payment Services Directive is breaking out of Europe—so if you’re making payments to or from Europe, or within Europe in any currency, you’re covered. More than that, it’s doing so in a way that takes on a greater scope and aims to keep up with the innovations we’ve all been busy creating and rolling out around payments—so if you’ve been working in the “gray areas” of financial services, you may well now be covered. PSD2 promises to strengthen payment security and consumer protection through its support and regulation of new classes of market participants, which will be empowered to take an intermediating role between users of financial services and their financial institutions.
With the proliferation of financial innovations, it can be difficult for financial institutions to know who is authorized to initiate a transaction on behalf of a user, and who isn’t. This is a recipe for fraud. An unfortunate result would be for the market to contract and exclude higher-risk service providers. But when there is transparency around who the providers are and how they must operate, the market can instead be opened up to many more participants. Transparency can also help consumers to understand the way in which their payment is to be processed, including what fees they will be responsible for.
Europe extends beyond the E.U., and the U.K. government’s Competition and Markets Authority (CMA) is taking a prime role in putting PSD2 into effect by establishing, via the Open Banking Implementation Entity (OBIE), application programming interfaces (APIs) by which payments can be initiated. In explaining how Open Banking realizes PSD2, it may be helpful to take a step back and cover some basic concepts.
Authentication involves getting an assurance that a visitor is who they say they are, recognizable in terms of their prior visits. It is standard fare of authentication that users may be identified on the basis of knowledge, ownership, or inheritance, i.e., “something you know, something you have, and something you are,” and the more of those categories used, the better. Passwords, the staple of online accounts, are an example of a knowledge factor; your phone is an ownership factor, so you can authenticate by providing a code sent to it; and you can, of course, authenticate based on biometric attributes of yourself, such as patterns in your fingerprints, voice, or retina. Two-factor authentication (2FA), which has become popular due to its success in holding off malicious hackers, is a requirement that independent factors in two of those three categories be used (generally the first two). Multi-factor authentication (MFA) simply allows for factors from two or more of the categories. PSD2 define strong customer authentication (SCA) as going beyond MFA as follows: “At least one of the elements should be non-reusable and non-replicable (except for inherence), and not capable of being surreptitiously stolen via the Internet.” The authentication codes sent to you by text message or email fit this constraint; the fact that biometric data can be replicated is one of its limitations. PSD2 also requires that the strong authentication procedure protect the confidentiality of the authentication data. PSD2 requires SCA in situations including payment initiation, except in particularly low-risk, low-value, or high-security situations. Since our apps operate via the internet, the third exception generally doesn’t apply. The first, however, may be relevant when the payment is predictable based on past experience or when it is to a beneficiary trusted by the PSU. Due to these exceptions, and to the fact that even 2FA can be foiled, however, PSD2 requires a multi-layered approach that mitigates the damage of security breaches by detecting, triaging, and exposing them.
Authorization is a parallel concept to authentication. It doesn’t do much good to know who a visitor is if you don’t know what they’re allowed to see or do. To make sense of the numerous possible operations that a visitor could try to perform, and thus the numerous necessary authorization decisions, applications often use role-based authorization. Here, a bounded number of real-world roles are defined and each associated with a collection of system operations. We only have to worry about each operation in terms of the various roles, rather than for each user. It is a nice added benefit that a user can have multiple roles, and in any visit may choose to activate one or more of them, but not others. While roles are defined to make it easy to classify users, scopes provide a second level of access control that is defined based on what system resources need protection (resources here, however, are not defined or specified, so as we will see, scopes can be used for pretty much anything).
Tokens are the entry keys that pull everything together by serving as proof that a user has been authenticated, and thus that they have access to APIs in a given scope. They can also, we shall see, implicitly record any other information, such as that they have approved a payment. Beyond scopes, tokens have access based on the type of grant through which they were created. The grant type also defines the protocols by which an access token is created and by which it operates.
We’ve been talking about application-level security, and that will mostly be our concern in this article. For completeness, though, we should mention that security is also imposed at the transport level. All of our work in application security is for nought if an attacker can tap the communications line and read, modify, or generate payment requests. So Open Banking addresses this issue as well, by requiring that messages be encrypted and decrypted using keys encased in certificates and held in keystores.
We will be concerned here with the activities of payment initiation service providers (PISPs). (The other new class of market participants is account information service providers (AISPs).) These organizations, as the name implies, initiate a payment on behalf of their users, known as payment service users (PSUs), likely as part of a larger service they provide via some app. That payment is processed by a payment service provider (PSP), and in particular the PSU’s account servicing PSP (ASPSP). PSD2, as implemented in Open Banking, choreographs the interaction among these three entities to protect all the parties involved. See the figure below.
Open Banking Payment Sequence Diagram
Since the first step in the sequence diagram involves interaction between the PSU and the PISP in which the PSU initiates a payment, authentication of the PSU may well be performed by the PISP. With federated authentication, the PISP may not need to authenticate the PSU directly, instead relying on a central identity manager (such as Facebook), often using OAuth. Regardless, the PSU’s ASPSP need not rely on the PISP for authentication of the PSU nor for their claim that the payment has been approved. In step 2, with the user authenticated and the PISP directed to initiate a payment, the PISP directs the ASPSP, via a client credentials grant and access token, to create a record of the payment, accessible via a payment identifier. In step 3, the PISP redirects the PSU, payment identifier in hand, to the ASPSP, who independently authenticates the PSU and asks for approval of the payment details (beneficiary, amount, and account to be debited), before redirecting the PSU back to the PISP. At this point, the PSU has approved the transaction with the ASPSP, but the PISP doesn’t know that (nor can the ASPSP move forward without the PISP’s confirmation that it is recording the payment). The ASPSP doesn’t want to rely on the PISP, but the PISP can’t be left out of the interaction, so the PSU (via PISP code in its app) passes an authorization grant that it receives from the ASPSP to the PISP, which the PISP trades back to the ASPSP in exchange for an access token. Then in step 4, the PISP uses the access token to direct the ASPSP to create a record of the payment submission. A payment submission identifier is passed back to the PISP, which it can use in step 5 to query the ASPSP for the status of the payment. Once it has been approved, this information can be passed back to the PSU and the PISP and PSU can continue with other business on the PISP’s app.
payment at hand. We’ve seen that the use of access tokens enables coordination between the various parties. It has an additional benefit of preventing distributed denial of service (DDoS) attacks. In such attacks, a server is flooded with messages causing it to waste processing power. It should be difficult for an attacker to obtain even a single valid access token, let alone a large number of them. Open banking supports a notion of application access tokens, which allow access to multiple APIs at once. Just how many access tokens are needed? For both of the payment initiation case above, we appear to need one per group of APIs (application) and end user, and so call these ‘user access tokens’. In other cases, the access might not be particular to a user at all, so that one per application is sufficient—these are referred to as ‘application access tokens.’ But what if a user logs in through multiple devices at once? We now want one token per application/user/device. This can be made to happen by subverting the more primitive authorization method of scopes.
We’ve seen how Payment Services Directive II has created a path for the various kinds of participants in the payments ecosystem to come together, leading to a more dynamic and secure marketplace. We’ve also seen how Open Banking is making that vision a reality. However your firm relates to international payments, Softjourn can help you to comply with, and leverage the opportunities provided by, PSD2.
Additional information and references:
- “Payment Services Directive 2: Directive on Payment Services in the Internal Market ‘(EU) 2015/2366’”. Deutsche Bank Global Transaction Banking. http://cib.db.com/docs_new/White_Paper_Payments_Services_Directive_2.pdf
- “The impact of Payment Services Directive II (PSD2) on Authentication & Security” Goode Intelligence White Paper. http://www.goodeintelligence.com/wp-content/uploads/2016/07/Goode-Intelligence-White-Paper-The-impact-of-PSD2I-on-authentication-and-security.pdf
- WSO2 Open Banking Documentation. https://docs.wso2.com/display/OpenBanking/WSO2+Open+Banking
- Open Banking Payment Initiation API Specification – v1.0.0. https://www.openbanking.org.uk/open-data-apis/
- “PSD2 – OAuth 2.0 / OpenID Connect Grant Types” Zia’s Musings. https://zsviews.wordpress.com/2017/04/24/psd2-oauth-2-0-grant-types/