Menu Close Back

Mobile apps and PSD2 compliance: How Guardsquare can help

Mobile apps and PSD2 compliance: How Guardsquare can help

The digitization of financial services and the advent of open banking pose a series of game-changing implications for service providers and consumers alike. Correct compliance with the EU's revised regulatory framework, PSD2, is key for the successful transition of online payment service providers (i.e. banks and financial services firms) to API-led connectivity and a more competitive and innovative market. Guardsquare provides security solutions that fit within the Zero Trust security model and safeguard mobile apps against reverse engineering and hacking, as well as protect the RTS implementation requirements for PSD2 compliance. Our solutions also enable a Trusted Execution Environment for processing electronic payments on mobile devices. 

The following article sums up what PSD2 means for your apps and business, and how Guardsquare can help with compliance before the directive comes into full effect in all 28 EU member states on September 14th, 2019.

PSD2 

PSD2 revolutionizes online payments by giving banks and non-banking third party players (TPPs) access to consumer bank account information, while (1) enforcing higher security measures for consumer payments, (2) fostering innovation and (3) encouraging competition among all service providers. Complying with PSD2 regulations enables for the optimization and democratization of e-payment services, enhancement of customer experience and retention. As PSD2 grants new access rights to TPPs and banks, it also enforces stricter security measures to consumer account information.

In short, PSD2 is responsible for two key changes for which implementation requirements are defined by the Regulatory Technical Standards (RTS)

  1. Provisions on Strong Customer Authentication (SCA) for online payments to provide an increased level of security of electronic payments. For mobile and remote payments, SCA must additionally be ensured by using a unique authentication code to dynamically link the transaction to a specific amount and specific payee.
  2. Common and secure open standards of communication (CSC) to safely share payment account data or initiate payment transactions, by (1) providing an API for secure information exchange and (2) adapting the customer online banking interface to provide access to TPPs.

How can Guardsquare help? 

Protecting your financial transactions at the app level is the most effective way to prevent unauthorized access to your application’s services. As the global reference in mobile application security, Guardsquare provides software that protect SCA implementation and enable a Trusted Execution Environment for processing electronic payments on mobile devices.

Our solutions fulfill PSD2/RTS implementation requirements by correctly applying hardening techniques at critical code locations through:  

  • Application and code integrity, to ensure the overall integrity of banking apps and SDKs.
  • Environment integrity of the device(s) on which apps are run, via root/jailbreak, hook and debugging detection.  
  • Code obfuscation techniques, in order to protect against reverse engineering and tampering during electronic/online payments.
  • Asset/resource encryption, to ensure the protection of app assets/resources including certificates, configuration files, etc.
  • Device fingerprinting, to safely and uniquely identify mobile devices.
  • Hardened SSL pinning, to ensure apps communicate with the intended servers.

Each technique enables for PSD2 compliance specifically through their fulfillment of RTS Article 4/3(c)678921/2(a) and  22/1(b), as shown below:

PSD2 compliance with Guardsquare

Conclusion 

As mobile applications become a critical part of financial infrastructures, app security and compliance become imperative for any successful IT security model today, such as Zero Trust. Our software (DexGuard, iXGuard) help ensure the overall effectiveness of your IT security architecture by safeguarding your mobile endpoint. Ensuring app and platform integrity, through preventing reverse engineering and hacking, is also vital in protecting multiple points discussed in PSD2. 

Our technical solutions fulfill specific PSD2/RTS requirements, such as obfuscation of critical code and resources used for unique identification, to prevent replication of the information used to uniquely identify the device; Software and platform integrity testing, to ensure a trusted/secure execution environment; Device fingerprinting, to prevent that the device hosting the app is used by an unauthorised person; SSL pinning, to protect communications to the backend from eavesdropping or interception. 

Contact us to learn more about how Guardsquare can help your business comply with PSD2 regulations and reap all the benefits of the digital transformation within the online banking sector.

 

 

 

Article 4/3(c): Authentication code
 
3.  Payment service providers shall ensure that the authentication by means of generating an authentication code includes each of the following measures: 
(c) the communication sessions are protected against the capture of authentication data transmitted during the authentication and against manipulation by unauthorised parties in accordance with the requirements in Chapter 5;  

Article 6 : Requirements of the elements categorised as knowledge
1. Payment service providers shall adopt measures to mitigate measures to mitigate the risk that the elements of strong customer authentication categorised as knowledge are uncovered by, or disclosed to, unauthorised parties.
2. The use by the payer of those elements shall be subject to mitigation measures in order to prevent their disclosure to unauthorised parties.

Article 7 : Requirements of the elements categorised as possession
1. Payment service providers shall adopt measures to mitigate the risk that the elements of strong customer authentication categorised as possession are used by unauthorised parties.
2. The use by the payer of those elements shall subject to measures designed to prevent replication of the elements.

Article 8 : Article Requirements of devices and software linked to elements categorised as inherence 
1. Payment service providers shall adopt measures to mitigate the risk that the authentication elements categorised as inherence and read by access devices and software provided to the payer are uncovered by unauthorised parties. At a minimum, the payment service providers shall ensure that those access devices and software have a very low probability of an unauthorised party being authenticated as the payer.   
2. The use by the payer of those elements shall be subject to measures ensuring that those devices and the software guarantee resistance against unauthorised use of the elements through access to the devices and the software.

Article 9: Independence of the elements
1. Payments service providers shall ensure that the elements of strong customer authentication referred to in Articles 6, 7 and 8 is subject to measures which ensure that, in terms of technology, algorithms and parameters, the breach of one of the elements does not compromise the reliability of the other elements.
2. Payments service providers shall adopt security measures, where any of the elements of strong customer authentication or the authentication code itself is used through a multi-purpose device, to mitigate the risk which would result from that multi-purpose device being comprised.
3. For the purposes of paragraph 2, the mitigating measures shall include each of the following:
the use of separated secure execution environments through the software installed inside the multi-purpose device;
mechanisms to ensure that the software or device has not been altered by the payer or by a third party;
where alterations have taken place, mechanisms to mitigate the consequences thereof.

Article 21/2(a) : Monitoring 
2.  For the purpose of paragraph 1, payment service providers shall ensure that each of the following requirements is met:
(a) the association of the payment service user’s identity with personalized security credentials, authentication devices and software is carried out in secure environments. In particular, the association shall be carried out in environments under the payment service provider’s responsibility and taking into account risks associated with devices and underlying components used during the association process that are not under the responsibility of the payment service provider. The environments under the payment service provider’s responsibility include, but are not limited to, the payment service provider’s premises, the internet environment provided by the payment service provider or in other similar secure websites and its automated teller machine services;

Article 22/1(b) : Delivery of credentials, authentication devices and software
1. Payment service providers shall ensure that the delivery of personalised security credentials, authentication devices and software to the payment service user is carried out in a secure manner designed to address the risks related to their unauthorised use due to their loss, theft or copying.
(b) mechanisms that allow the payment service provider to verify the authenticity of the authentication software delivered to the payment service user via the internet;