In the previous articles we introduced PSD2 and showed how to create accounts and payments APIs using z/OS Connect EE and API Connect. In this article we outline how these APIs can be secured.

Introduction to the security considerations for PSD2

Payment services offered electronically should be carried out in a secure manner, adopting technologies able to guarantee the protection of all parties in the transaction; consumer, merchants and financial services providers alike and to reduce, to the maximum extent possible, the risk of fraud.
PSD2 introduces strict security requirements for the initiation and processing of electronic payments, and for the protection of consumers’ financial data.
The regulatory requirements mandate that payment service providers must do the following:

• Establish common and secure open standards for the communication between the different actors
• Protect the confidentiality and the integrity of the payment service user’s personalized security credentials
• Apply the procedure of strong customer authentication

Common and secure open standards for communication

The payment service providers shall ensure:

• Secure identification when communicating between the payer’s device and the payee’s acceptance devices for electronic payments. The payment service providers shall rely on certificates for such identification.
• That the risks against misdirection of communication to unauthorized parties in mobile applications and other payment services users’ interfaces offering electronic payment services are effectively mitigated. When exchanging data via the internet, secure encryption should be applied between the communicating parties throughout the respective communication session in order to safeguard the confidentiality and the integrity of the data, using strong and widely recognized encryption techniques.

Protecting confidentiality and integrity

The payment service providers shall ensure the confidentiality and integrity of the personalized security credentials of the payment service user, including authentication codes, during all phases of authentication including display, transmission and storage. Payment service providers shall ensure that the creation of personalized security credentials is performed in a secure environment. Payment service providers shall mitigate the risks of unauthorized use of the personalized security credentials.

Strong customer authentication

Where payment service providers apply strong customer authentication, the authentication should be based on 2-factor customer authentication (2FA) using two or more elements out of the following three:

• Knowledge: something only the user knows (e.g. a password or PIN),
• Possession: something only the user holds (e.g. a card or a token), and
• Inherence: something only the issuer is (e.g. a finger print or voice).

The elements must be independent of each other, meaning that a breach of one does not compromise the reliability of the others, and they must be designed in a way to protect the confidentiality of the authentication data.

For electronic remote payment transactions, an additional dynamic element is required, linking the transaction to a specific amount and a specific payee. This additional requirement is based on the regulator’s view that the solid growth of internet payments and mobile payments should be accompanied by a generalized enhancement of security measures.

Designing the Implementation of PSD2 security on the MPLBank showcase

MPLbank is a real-world showcase of the technical challenges facing the banking sector today. More than a simple demo, it was conceived as a replica of one of Europe’s largest banks, with a core accounting and payment system based on CICS and DB2 z/OS technologies on the IBM Z platform (https://developer.ibm.com/mainframe/docs/open-banking/openbanking-psd2-in-practice-apis-and-mplbank/).

With the recent regulatory changes, the MPLbank team set themselves the challenge of adopting an Open Banking solution to meet the deadlines of PSD2. The MPLbank team designed a security model that satisfies the PSD2 security requirements.

The two sections below describe this security model for the two major scenarios involved in PSD2 use cases:

• User account enrollment and consent
• Payment initiation

User account enrollment and consent

Figure 1 shows a high-level flow diagram for the user account enrollment and consent scenario. The scenario is made up of 4 main steps:

• The user requests to enroll his account to the Third Party Provider (TPP).
• The TPP redirect the user request to the bank
• The user provides consent to the bank using a 2 factors authentication method.
• The bank provides OpenID Connect tokens (Access, refresh and ID) to the TPP which is then stored and will be used during the payment initiation.

1. The user requests to enroll his account to the Third Party Provider (TPP).
• The user logs in to the TPP using the security credentials for their TPP account (ID and password)
• A SSO token represented as a JSON Web Token (JWT) is generated by the TPP and returned to the user
• The user sends his IBAN to be enrolled in the TPP application with the JWT.

1. The TPP redirects the user request to the bank
• The TPP sends the subscription of the user to the user’s bank, retrieved from the IBAN.
• The bank verifies whether the TPP is already enrolled with the bank, and if so, verifies the IBAN of the user
• The TPP redirects the User to the bank’s site

1. The user provides consent to the bank using a 2-factor authentication method.
• The user authenticates with his user ID and password (what he knows).
• The bank checks the ID / password and challenges the user with a second authentication
• The user authenticates to the bank with an one time password sent by SMS to his mobile device (what he hold)
• The bank checks the second authentication factor and sends a form back to the user to confirm the enrollment.

1. The bank provides OpenID Connect tokens to the TPP.
• The user confirms to the bank the enrollment of his IBAN with the TPP.
• The bank generates an authorization code and sends it back to the user
• The user sends the authorization code to the TPP
• The TPP requests a token to the bank using the authorization code of the user
• The bank generates the OpenID Connect tokens (Access, Refresh and ID) and sends them back to the TPP
• The TPP stores the tokens and confirms the enrollment to the user.

The MPLBank team decided to rely on a DataPower appliance to act as the OpenID Connect provider. In this scenario, the DataPower appliance is used to generate the OpenID Connect tokens.

Payment initiation

Figure 2 shows a high-level flow diagram for the payment initiation scenario. The scenario is made up of 4 main steps:

• The user logs in to the TPP to initiate a payment
• TPP sends the payment request to the bank
• Step-up authentication
• User’s payment approved

1. The user logs in to the TPP to initiate a payment
• The user logs in to the TPP using the security credentials for their TPP account (ID and password)
• The user sends the payment information (IBAN from creditor, IBAN from debtor, amount). In the meantime, the JWT is sent to the TPP by the client application as the first authentication factor.
• The TPP verifies the access token represented as a JWT (signature, expiration date, authorization) and gets the stored ID token associated with the user’s IBAN

1. TPP sends the payment request to the bank
• The TPP sends the payment information (IBAN from creditor, IBAN from debtor, amount) and the ID token
• The bank verifies the token: the signature as well as the association with the user’s IBAN
• The bank sends a One Time Password to the user. This One Time Password will be used as the second authentication factor to authorize the payment.
• The bank redirects via the TPP the user to the bank’s site (dynamic linking) and sends the user all the information related to the payment (amount, IBANs from debtor and creditor, date/time)

1. Step-up authentication
• The user connects to the bank using the redirect url and provides the One Time Password as the second authentication to authorize the payment.
• The bank verifies the One Time Password provided by the user

1. User’s payment approved
• The bank processes the payment
• Once the payment has been processed (ie immediate payment), the banks sends the confirmation to the TPP
• The TPP sends the payment confirmation back to the user.

In this scenario, the payment initiation transaction is running in Financial Transaction Manager, which is based on IBM MQ (MQ) and IBM Integration Bus (IIB) on z/OS. The payment initiation transaction has been exposed as a RESTful API through z/OS Connect EE. The MPLBank team decided to rely on z/OS Connect EE as the security enforcement point. To authorize in the payment backend system (MQ/IIB in our scenario), it will be necessary to map the credentials used for user authentication to a user in the RACF registry. z/OS Connect EE performs several security functions like the validation of the JWT and the extraction of the distributed identity, the call to RACF to map the distributed ID to a RACF user ID, the call to RACF to check that the user is authorized to invoke the API, and the propagation of the mapped RACF user to MQ/IIB.

Concluding remarks

This article is the last of three articles on Open Banking & PSD2, which concludes with the security design related to the PSD2 scenario implemented in the MPLbank showcase.

The first article “Open Banking and PSD2 in Practice: APIs and MPLbank” introduces PSD2 and Open Banking and gives an overview of the MPLbank banking showcase.

The second article “Open Banking and PSD2 in Practice: Developer-Ready APIs” presents how the PSD2 APIs have been implemented in the MPLbank showcase using two key technology enablers, z/OS Connect EE and API Connect.