×
apim
2017/05/30
30 May, 2017

[Article] Frictionless Adoption of Security Recommendations for the Payment Services Directive 2 (PSD2) with WSO2

  • Pushpalanka Jayawardhana
  • Senior Software Engineer - WSO2

Introduction

The Payment Services Directive 2 (PSD2) is the revised version of its predecessor PSD, brought about with the intentions of making electronic payments more secure and establishing an effective and integrated payment services platform. It enforces enhanced security measures that need to be implemented by all payment service providers by 2018. PSD2 mandates the use of at least two factors for customer authentication to enhance security of transactions while enforcing payment service providers to open consumer data via secure open APIs.

WSO2’s identity and access management (IAM) and API management platforms cater to all the above-mentioned requirements. WSO2 Identity Server provides comprehensive support for multi-factor authentication including Time-Based One-Time Password (TOTP), SMS OTP, Fast IDentity Online (FIDO) and Duo along with extendability to support any other mechanism to authenticate users. WSO2 API Manager provides comprehensive support for API management, including API security, monitoring, and throttling.

In this article, we will discuss and demonstrate how WSO2 products can be leveraged to adhere to the requirements of PSD2 by considering the guidelines provided by the Regulatory Technical Standard (RTS) from European Banking Authority (EBA).


Background of PSD2

According to a survey done at the request of the European Commission, 54% of Internet users in the European Union (EU) do online banking. When using the Internet for online banking or shopping, the two most common concerns have been the misuse of personal data (mentioned by 43%) and security of online payments (mentioned by 42%). 63% of participants are concerned about being the victim of bank card or online banking fraud [13]. These statistics make it clear that a majority of people have concerns in relation to online payments. In order to let consumers use online payment services with confidence, regulations and laws have been passed to enhance the security of transactions and shared personal details. PSD2 is the latest of these that is soon going to be a law affecting the European region. Since online payment is a global market, the effects of PSD2 will be felt internationality without being limited to EU.

PSD2 mentions several mandates that improve payment services security and leads to enhanced consumer protection. With it being enforced on open APIs from financial service providers, competitiveness in the domain can be expected to become tense, leading to more innovation. Credit card payments through the Internet and wire transfers between bank accounts or e-money accounts are addressed in the directive while payments via phone, post or SMS are set out of scope.

Let’s follow the below diagram to better understand the major effects of PSD2:

Figure 1: Payment procedure before and after PSD2

The traditional card scheme based payment flow is shown by the grayed components. In this flow, the customer provides their card details to the presented payment input page. The payment request then goes to the merchant’s acquiring bank and then to the relevant card scheme (e.g. VISA, MasterCard) for authorization. Once the validation is successful, a request for the payment is sent to the customer’s card issuing bank where verification is done and the payment is issued.

PSD2 introduces a payment flow that has fewer steps in the value chain. It allows merchants to accept payments directly from the consumer’s issuing bank account. In this flow, the merchant will directly communicate with the Payment Initiation Service Provider (PISP) who will contact the issuing bank. The merchant themselves can also act as a PISP given the infrastructure that is set up.

With the introduction of PSD2, two new entities can be identified:

  • PISP (Payment Initiation Service Provider)
    This reduces the number of steps in a transaction, which will in turn lower the fee per transactions. Customers can directly interact with the PISP to initiate a payment to a merchant from the issuer bank rather than going through the card network and the processing bank of the merchant. Banks should provide open and secure APIs for PISPs to initiate a transaction on behalf of the consumer, while merchants should also be able to integrate with PISPs in order to get this flow to work.
  • AISP (Account Information Service Provider)
    This will provide customers a single view on the overall financial status of accounts kept across different banks. The bank should be able to expose customer information via secure APIs under the customer’s consent in order for this flow to work. Credit cards, savings accounts, mortgages, etc. can be in different banks. AISPs can offer direct insight into all products and transactions across banks. Since customers trust their existing banks, these banks can play this role by giving their apps the freedom to aggregate with other banks and provide an overall view. We will later look at how to enable this.

The above requirements raised by PSD2 highlights the fact that information technology is no longer a supporting factor but a driving force in the arena of payment services. Apart from providing the expected functionality and security, convenience aspects also need to be satisfied by the financial system for smooth operation. The next section will go into detail about the security implications and other technology requirements that are needed to cater for PSD2.


Technology requirements of PSD2

With PSD2, the most focused and challenging technology requirements have been raised in the security aspects of the system and involves flows such a customer authentication, authorization and making payments. When considering open APIs, designing and managing APIs, securing them and throttling the requests can be identified as key points to focus on. There can also be mediation requirements if legacy systems are maintained at financial institutes. If we look beyond PSD2, analytics also plays a key role in fraud detection and will provide resources for decision-making such as information on cash flow trends that create a competitive advantage for the enterprise. In this article we will in detail discuss the requirements in security aspects.


Security

Articles 95, 96, 97 and 98 of PSD2 addresses security concerns. It highlights the management of operational and security risks in the system that need to be addressed at an administration level. In order to facilitate this, data analytics and monitoring functionality need to provide the required resources. Incident reporting is another key area where Payment Service Providers (PSP) are obligated to report incidents to the European Banking Authority (EBA) and European Central Bank (ECB).

Strong customer authentication (SCA) is a widely discussed aspect of PSD2 and RTS. SCA is mandated during the initiation of the payment, when viewing or altering sensitive payment data or when any action, which may imply a risk of payment fraud or other abuse, is taken through a remote channel (exceptions are allowed for trusted beneficiaries, low-valued transactions, payments within PSP). The mandated approach achieves this by combining two or more independent factors related to the customer. Strong transaction authentication (STA) additionally mandates the ability to detect the person who initiates a payment with proof. If the customer denies payment, PSP is obliged to provide proof or refund. Dynamic linking is also a responsibility of PSP, where they must include elements linking the authentication to a specific amount and payee (authentication code). Any change to the payee or amount should invalidate the authentication code. Protecting the consumer’s security credentials (confidentiality and integrity) is also another aspect to be considered.

We will now in discuss in the detail the requirements in security aspects.


Multi-factor authentication

As mentioned in PSD2, SCA is required with at least two of the factors mentioned below:

  • Knowledge factors (username and password, pin)
  • Possession factors (mobile, security device, token generator)
  • Inherence factors (fingerprint, voice, iris pattern)

WSO2 Identity Server has comprehensive support for multi-factor authentication, with authenticators available for SMSOTP, FIDO, MEPin and more (for a complete list of the readily available authenticators refer here [1]). We are facilitating this functionality by utilizing the capabilities of WSO2's identity authentication framework [4]. Apart from multi-factor authentication, this framework supports features such as claim mapping, user provisioning, federated authentication and multi-options along with multi-step authentication among others.

Multi-option (the more generic version of multi-factor) and multi-step login give customers the flexibility to choose which challenges to take at each step. Administration can decide whether to provide a concrete set of steps satisfying the multi-factor authentication requirement or to provide an option at each step. For example, you can configure the system to authenticate the user with their username and password first, then use either SMSOTP or FIDO authentication as a second step.

In very rare cases, if none of the available authenticators satisfy your requirement or there is proprietary logic to authenticate users, we can write a custom authenticator and plug it into the flow via the framework. If the user attributes are understood by different keys among the different stakeholders involved in the authentication flow, claim mappings can do the claim conversion according to an agreement between these parties. WSO2 Identity Server’s user provisioning capability allows you to provision user attributes locally or to an outside party during user authentication if the user attributes are shared.


Access delegation

PSD2 specifies occasions where a customer would let a third-party application retrieve their account information on behalf of themselves. Here, the user delegates their access rights to this third-party application. PSD2 and RTS emphasises on the fact that the customer should be aware of and provide consent on what is being shared. WSO2 Identity Server and WSO2 API Manager comprehensively supports the OAuth 2.0 protocol, which is widely used for access delegation requirements in API invocations. Is also has extensive support for OpenID Connect, which is an authentication protocol built on top of OAuth 2.0. In that flow, we can satisfy user consent requirements and user/account information sharing requirements during the user authentication step while receiving an OAuth 2.0 token for access delegation. You can watch a demonstration of this towards the end of this webinar [3].

PSD2 mentions an ‘authentication code’ that needs to be dynamically linked to the payee and the payment amount. As the OAuth 2.0 token can be used multiple times until it expires, we will need to add something else. While an OAuth 2.0 token with short expiration time might be able to cater to this requirement, the code can also be something we implement separately as a One Time Password (OTP) or an additional parameter to be sent within the IDToken in the OpenID Connect protocol, which can be signed and encrypted as preferred.


Fine-grained authorization

Even though OAuth 2.0 can provide a certain level of authorization using scopes based on roles and permissions when authorization decisions are made based on more granular information and authorization policies change frequently, it becomes an inefficient solution with a lot of complexities.

XACML 2.0 or 3.0 is the de facto standard currently used for fine-grained authorization. In addition to checking user roles, this protocol allows you to look at other attributes of the user such as environmental attributes like the current time. WSO2 Identity Server supports XACML 2.0 and 3.0 protocols while providing flexibility to dynamically change the policies according to the business or administrative requirements. WSO2 Identity Server can act as the Policy Information Point (PIP), Policy Decision Point (PDP) and Policy Administration Point (PAP). It also has inbuilt Policy Enforcement Points (PEP) that can engage fine-grained authorization in the authentication flow [5]. A demonstration of how this is done with WSO2 Identity Server and WSO2 API Manager can be seen in this webinar [3].


Identity governance

PSD2 states that the number of failed authentication attempts that can take place consecutively, within a given period of time, shall in no event exceed five times. Hence identity governance should be a part of the solution we propose. Further details on how WSO2 Identity Server supports this can be found here [6].


Federated authentication with protocol mediation

This is an implicit requirement when adopting PSD2 since different banks and stakeholders will need to use each other’s authentication mechanisms and depend on them. Various banks will have different protocols that have already been utilized and evolved internally. These may use standard protocols such as Security Assertion Markup Language (SAML) single sign-on, OpenID Connect or a proprietary protocol. With AISPs, these disparate protocols need to be understood by other parties if they are to utilize the information. In addition to supporting multi-step and multi-option authentication, WSO2 Identity Server’s application authentication can act as an identity bus which does this protocol mediation.


Analytics and fraud detection

Both WSO2 Identity Server and WSO2 API Manager products have separate runnable analytics servers. The following screenshots show a few samples of WSO2 Identity Server’s analytic dashboard where login analytics and session analytics are visualized. WSO2 also has a comprehensive fraud detection solution. For further details please refer here [2].

Figure 2: WSO2 Identity Server analytics in action


API management

Since PSD2 mandates open APIs for PSPs, they will have to open APIs even for their competitors, which can be challenging and force you to look for new differentiators. Before PSD2, banks would have their own internal APIs that they expose to their customers via multiple applications to provide convenience to and build loyalty among their customers.

Figure 3: Effects of PSD2 on the API landscape

With PSD2, these APIs will no longer be internal, but public, so multiple third-parties can build disparate applications using and combining these public APIs. This will raise the need for APIs to rise above the competition, be governed and take security aspects into serious consideration. Developing of APIs, the best practices to be followed when doing so and API documentation will also be topics of consideration since there will be external developers who need to consume the APIs. Being developer-friendly in consuming APIs will be a plus point for PSPs to encourage third-party application developers to use their APIs and create a presence. If at some occasion monetization is possible for APIs, WSO2 API Manager has the capability to support billing as described in this white paper [7]. In the section below we will look at requirements raised with PSD2 and WSO2 product capabilities that meet them.


Securing APIs

WSO2 API Manager has embedded within it most of the sought-after security features of WSO2 Identity Server. This includes comprehensive OAuth 2.0 protocol support with scope validations, where token-based security is applied during the API invocation. Basic auth-based authentication is also allowed but it has the freedom to engage with more authentication handling mechanisms. This white paper [7] discusses these in detail. It is also possible to apply fine-grained authorization when securing APIs using XACML, as discussed earlier.


API versioning and management

WSO2 API Manager allows you to manage the API’s lifecycle from its design to retirement [8]. With API versioning you can evolve your APIs without affecting any current applications consuming them.


Developer tools

There are five major components that are shipped with WSO2 API Manager, namely the API Gateway, API Publisher, API Store, Key Manager and Traffic Manager [9]. From these components, the API Publisher portal allows developers to design and implement APIs, as well as document (supports importing APIs with Swagger 2.0) and manage (throttling policies) them. Even without a backend, developers can prototype the APIs here and perform tests or let the other stakeholders continue using these prototyped APIs. This portal provides tooling for API developers. The API Store is available for application developers to subscribe and consume published APIs. This quick start guide [10] will take you through these features without any other prerequisites apart from Java and the WSO2 API Manager pack.


AISP flow

Figure 4: A possible flow with AISP

Figure 4 illustrates a possible AISP flow and how to implement an overall flow with the technologies we have discussed so far. Here, the AISP acts as a federation hub since the users will still be authenticated at the PSPs their accounts are kept with. Two separate banks are using SAML and OpenID Connect respectively, in order to authenticate the users. Therefore, in order to let the users log into the AISP application, it can utilize one of these banks as a federated identity provider. Then, in order to retrieve the customer’s account information, this application needs to call the APIs, which might be secured with OAuth 2.0. In order to achieve this, we will rely on SAML bearer grant and JWT grant flows (two grant types later introduced to OAuth 2.0 grant types). To adhere with the user consent mandated by PSD2, we will have to introduce a few more parameters and minor changes in the default flows of these, while taking this as an abstract flow.


PISP flow

In addition to the solutions discussed for the AISP flow, here we have to address the PSD2 requirement to have a single user authentication code that is dynamically linked to the payee and the amount while having proof of the payment initiator. This flow also involves secured API calls, where the challenge needs to be addressed, similar to an OAuth 2.0 token flow. To support dynamic linking we will have to inject minor modifications when sending requests. Enough flexibility and extendability is present in both WSO2 API Manager and WSO2 Identity Server to adapt to these refinements. Multi-factor authentication needs to be applied and the decision to providing multi-options will be based on your requirement.


Reference architecture for PSD2 with WSO2 platform

The following diagram is a reference architecture with the WSO2 product stack that will play a key role in adhering to PSD2.

Figure 5: Reference architecture for PSD2 with WSO2 products

Looking at the diagram from the bottom up, the PSPs will already have services and APIs from the pre-PSD2 era. These may be legacy systems, the APIs may not have been designed to be exposed to the public and the data formats may not be very API-friendly. While WSO2 API Manager has the capability to perform mediations on these services and APIs to expose them in the desired manner, it is recommended to have a separate WSO2 Enterprise Service Bus to do the heavy-lifting of mediation. This is a logically clear separation and would have a positive effect on both the mediation functionality as well as WSO2 API Manager performance. The API management layer lies on top of this for API security, monitoring and throttling. The WSO2 analytics components will consume the data published by WSO2 API Manager to generate analytical details on API calls and their context. Here, WSO2 Identity Server either act as the key manager component for WSO2 API Manager or acts as the identity and access manager for the applications. This can act as a federation hub or as the primary identity solution within a PSP. WSO2 Identity Server itself will publish relevant data to the analytics server in order to provide login and session analytics.


Conclusion

PSD2 has put forward regulations that would help in minimizing payment fraud, customer confidence when making online payments, facilitating the flow and increasing the openness of the market to encourage competition and innovation. It is soon going to be a law and in order to get the full advantage of this opportunity, you need to look at options that adhere to the requirements, while having differentiators and values that earn your bank a competitive advantage. What additional features you can offer and how fast you can adapt to the moving markets will define how you place yourselves among your competition. With this open market, existing system silos need to be broken up to provide agile customer experiences. The adoption of these new changes will mainly affect the applications layer where customer apps, partner apps, employee apps and the Internet of Things exist. These will be enabled by financial technology players that are powered by a middleware layer based mostly on service-oriented architecture (SOA).

WSO2 can comprehensively cover this layer in the journey of PSPs to be compliant with PSD2 by using WSO2 Identity Server, WSO2 API Manager and WSO2 Enterprise Service Bus abstracting the user stores, backends and legacy systems underneath. These 100% free and open source products that are built on industry standards offer you the flexibility and extendability to cater to all your business requirements.


References
 

About Author

  • Pushpalanka Jayawardhana
  • Senior Software Engineer
  • WSO2

API Management
Integration
IAM
Internal Developer Platform
Solutions
Resources
Support
Company
Sign Up For Our Newsletter

Follow us

Learn About Security At WSO2 →