Law / European Union

Payment Services Technical Standards on Strong Customer Authentication, Personalized Security Credentials and Common and Secure Open Standards of Communication

Commission Delegated Regulation (EU) 2018/389, Arts. 2-9 and 22-36

In force since 14 Sep 2019.

A sector security regimes rule binding private bodies.

Obligation class

Security

As of 10 October 2026.

What it requires

• This Regulation sets the requirements for the security measures behind Article 97 of Directive (EU) 2015/2366, so it reaches you if you are a payment service provider: an account servicing payment service provider, a payment initiation service provider, an account information service provider or a payment service provider issuing card-based payment instruments. The exemptions from strong customer authentication in Chapter III (Articles 10 to 21) lift the authentication duty in the cases and on the conditions they state, subject to compliance with Article 2.
• Have transaction monitoring mechanisms that detect unauthorized or fraudulent payment transactions by analyzing payment transactions against what is typical of the payment service user in the circumstances of a normal use of the personalized security credentials, and take into account at a minimum lists of compromised or stolen authentication elements, the amount of each payment transaction, known fraud scenarios, signs of malware infection in any session of the authentication procedure and, where you provide the access device or software, a log of its use and its abnormal use (Article 2).
• Document, periodically test, evaluate and audit the implementation of the security measures, through auditors with expertise in IT security and payments who are operationally independent, and make the entire audit report available to competent authorities on request. If you use the transaction risk analysis exemption of Article 18, have the methodology, the model and the reported fraud rates audited at least yearly, by an independent and qualified external auditor in the first year and at least every 3 years after that (Article 3).
• When you apply strong customer authentication, base it on two or more elements categorized as knowledge, possession and inherence and generate an authentication code that you accept only once, from which no information on the elements can be derived, that cannot be generated from another code and that cannot be forged. Do not reveal which element was incorrect when authentication fails, do not allow more than five consecutive failed attempts within a given period of time before the action is blocked, protect communication sessions against the capture of authentication data, and do not allow more than 5 minutes without activity by the payer after authentication for online access to a payment account (Article 4).
• For an electronic remote payment transaction, make the payer aware of the amount and the payee, generate an authentication code that is specific to the amount and the payee the payer agreed to, accept only a code that corresponds to that amount and payee, invalidate the code if the amount or the payee changes, and protect the confidentiality, authenticity and integrity of the amount, the payee and the information displayed throughout all phases of the authentication (Article 5).
• Adopt measures that mitigate the risk that authentication elements categorized as knowledge are uncovered by or disclosed to unauthorized parties, that elements categorized as possession are used by or replicated for unauthorized parties, and that elements categorized as inherence and read by access devices and software are uncovered by unauthorized parties, with a very low probability of an unauthorized party being authenticated as the payer. Ensure that the breach of one element does not compromise the reliability of the others, and where an element is used through a multi-purpose device, use separated secure execution environments and mechanisms to ensure the software or device has not been altered (Articles 6 to 9).
• Ensure the confidentiality and integrity of the personalized security credentials of the payment service user, including authentication codes, during all phases of the authentication: mask them when displayed, do not store them or the related cryptographic material in plain text, protect secret cryptographic material from unauthorized disclosure, document the management of the cryptographic material, and process and route credentials and codes in secure environments in accordance with strong and widely recognized industry standards (Article 22).
• Create personalized security credentials in a secure environment and mitigate the risks of their unauthorized use following loss, theft or copying before delivery to the payer. Associate only the payment service user, in a secure manner, with the credentials, authentication devices and software, in secure environments under your responsibility, and use strong customer authentication when the association is made through a remote channel. Deliver them in a secure manner, with delivery mechanisms that ensure they reach the legitimate user, a means to verify the authenticity of authentication software delivered by means of the internet, and activation before first use. Apply the same procedures to renewal and re-activation, and have effective processes for the secure destruction, deactivation or revocation of credentials, devices and software and for the secure re-use of reusable devices and software (Articles 23 to 27).
• Ensure secure identification when communicating between the payer's device and the payee's acceptance devices for electronic payments, and effectively mitigate the risks of misdirection of communication to unauthorized parties in mobile applications and other interfaces offering electronic payment services. Have processes that make all payment transactions and other interactions traceable, with a unique identifier of each communication session, detailed logging of the transaction and timestamps synchronized according to an official time signal (Articles 28 and 29).
• If you are an account servicing payment service provider that offers a payment account accessible online, have in place at least one interface that lets account information service providers, payment initiation service providers and card-based payment instrument issuers identify themselves and communicate securely and lets them rely on the authentication procedures you provide to your users. Make the interface follow standards of communication issued by international or European standardization organizations, document its technical specification and make the documentation available free of charge on request to authorized providers and publish a summary on your website, make changes to the specification available not less than 3 months before they are implemented except in emergency situations, which you document, make the changes made to comply with Article 10a available not less than 2 months before they are implemented, and make a testing facility with support available for connection and functional testing (Articles 30 and 31).
• If you have a dedicated interface, ensure that it offers at all times the same level of availability and performance, including support, as the interfaces made available to your users, define transparent key performance indicators and service level targets at least as stringent, do not create obstacles to the provision of payment initiation and account information services, monitor the availability and performance of the interface and publish quarterly statistics on your website, and include in its design a strategy and plans for contingency measures with communication plans for payment service providers using the interface (Articles 32 and 33(1) and (2)).
• Report problems with a dedicated interface to your national competent authority without delay, whether you are the account servicing payment service provider or a provider referred to in Article 30(1) (Article 33(3)).
• For identification, rely on qualified certificates for electronic seals or for website authentication under Regulation (EU) No 910/2014 that include the additional attributes in Article 34(3) (Article 34). When exchanging data over the internet, apply secure encryption with strong and widely recognized encryption techniques throughout the communication session. If you issue card-based payment instruments or are an account information service provider or a payment initiation service provider, keep the access sessions offered by account servicing payment service providers as short as possible and terminate them as soon as the requested action is completed. Keep personalized security credentials and authentication codes unreadable, directly or indirectly, by any staff at any time, and inform the payment services user and the issuer of the credentials without undue delay of any loss of their confidentiality under your sphere of competence (Article 35).
• If you are an account servicing payment service provider, give account information service providers the same information from designated payment accounts and associated payment transactions that you make available to the user when the user requests it directly, excluding sensitive payment data, give payment initiation service providers immediately after receipt of the payment order the same information on the initiation and execution of the transaction, confirm immediately upon request in a simple yes or no format whether the amount necessary for a payment transaction is available, and notify the other provider of the reason for an unexpected event or error (Article 36(1) and (2)). If you are an account information service provider, prevent access to information other than from designated payment accounts and associated payment transactions in accordance with the user's explicit consent, and access the information only when the user is actively requesting it or otherwise no more than four times in a 24-hour period unless the account servicing payment service provider agrees a higher frequency with you, with the user's consent (Article 36(3) and (5)). If you are a payment initiation service provider, give the account servicing payment service provider the same information as requested from the user when initiating the payment transaction directly (Article 36(4)).

Who enforces it

When LexLint raises it

When your app profile says your app provides financial services.

Back to the example  ·  Lint your app