The Commission Delegated Regulation (EU) 2018/389, which is often referred to as the RTS on Strong Customer Authentication (SCA) and Common and Secure Communication (CSC), is one of the most practical and influential instruments under PSD II. For compliance and legal professionals, it provides the technical backbone of how secure digital payments and data sharing must work in the EU.
This Delegated Regulation goes beyond broad policy goals and sets out concrete, operational standards: how payment service providers (PSPs) authenticate users, how they protect data, and how they interact with third-party providers through open and secure channels. In short, it turns PSD II’s vision of open banking into everyday compliance reality.
Understanding the structure and intent of this Delegated Regulation is essential for anyone mapping obligations, interpreting supervisory expectations, or assessing how institutions can meet both security and innovation requirements under PSD II.
Below, you will find a mapping of the Delegated Regulation’s provisions. I have found this format to be very helpful in related gap analysis exercises, when assessing the compliance of a PSP with the corresponding provisions.
| Article | Provision summary |
| 1. Subject Matter | Establishes that the Delegated Regulation lays down regulatory technical standards for strong customer authentication (SCA) and common and secure communication (CSC) under PSD II |
| 2. General authentication requirements | PSPs must implement risk-based transaction monitoring to detect unauthorized or fraudulent activity, using factors such as compromised credentials, transaction amounts, known fraud patterns, malware indicators, and abnormal device or software usage. |
| 3. Review of the security measures | Requires documentation, periodical testing, evaluation and auditing of the relevant security measures |
| 4. Authentication code | When SCA is used (Article 97 para. 1 PSD II), the authentication shall be based on at least two elements categorised as knowledge, possession and inherence. Authentication by means of generating codes is subject to specific requirements |
| 5. Dynamic linking | Security measures should be applied for the better validation of the transaction specifics (e.g., payment amount), while also ensuring confidentiality, authenticity and integrity |
| 6. Requirements of the elements categorised as knowledge | Requires PSPs to adopt measures to mitigate the risk of knowledge elements being uncovered or disclosed to unauthorised parties |
| 7. Requirements of the elements categorised as possession | Same as above, for possession elements |
| 8. Requirements of devices and software linked to elements categorised as inherence | Same as above, for inherence elements |
| 9. Independence of the elements | The use SCA elements (knowledge, possession or inherence) should be subject to measures which ensure that the breach of one element does not compromise the reliability of the other elements |
| 10. Payment account information | Subject to certain conditions, SCA may not be applied where a user is limited to accessing the balance of an account, or transactions executed in the last 90 days |
| 11. Contactless payments at point of sale | Subject to certain conditions, SCA may not be applied for contactless transactions of up to EUR 50 |
| 12. Unattended terminals for transport fares and parking fees | Subject to certain conditions, SCA may not be applied at an unattended payment terminal for the purpose of paying a transport fare or a parking fee |
| 13. Trusted beneficiaries | Subject to certain conditions, SCA may not be applied when a payee is included in the list of trusted beneficiaries |
| 14. Recurring transactions | Subject to certain conditions, SCA may not be applied for the initiation of a recurring transaction |
| 15. Credit transfers between accounts held by the same natural or legal person | Subject to certain conditions, SCA may not be applied for certain credit transfers |
| 16. Low-value transactions | Subject to certain conditions, SCA may not be applied for electronic payment transactions of up to EUR 30 |
| 17. Secure corporate payment processes and protocols | Subject to certain conditions, SCA may not be applied in respect of legal persons initiating electronic payment transactions through the use of dedicated payment processes or protocols that are only made available to payers who are not consumers |
| 18. Transaction risk analysis | Subject to certain conditions, SCA may not be applied in cases where the electronic payment transaction has been assessed by the PSP as low risk |
| 19. Calculation of fraud rates | PSPs shall ensure that overall fraud rates are equivalent to, or lower than, the reference fraud rate indicated in the Annex of the Delegated Regulation |
| 20. Cessation of exemptions based on transaction risk analysis | PSPs using Article 18 exemption (transaction risk analysis) must report to authorities if their fraud rates exceed reference levels, suspend Art. 18 exemption after two consecutive quarters of excess, and may only reinstate it (after notifying authorities) once fraud rates return to compliant levels |
| 21. Monitoring | To make use of Articles 10 – 18 exemptions, PSPs must record and monitor certain payment transaction data |
| 22. General requirements | General requirements for confidentiality & integrity of the user’s personalised security credentials |
| 23. Creation and transmission of credentials | PSPs must ensure that the creation of credentials is performed in a secured environment, and mitigate relevant risks |
| 24. Association with the payment service user | PSPs must ensure that only the use is associated with their personalised securit credentials |
| 25. Delivery of credentials, authentication devices and software | Requires PSPs to ensure that delivery of personalised security credentials etc. is carried out in a secure manner designed to address relevant risks |
| 26. Renewal of personalised security credentials | Renewal or re-activation of personalised security credentials must adhere to the procedures for the creation, association and delivery of the credentials and of the authentication devices in accordance with Articles 23, 24 and 25 |
| 27. Destruction, deactivation and revocation | PSPs are required to have effective procedures in place for the destruction, deactivation and revocation of personalised security credentials |
| 28. Requirements for identification | Secure identification must be ensured for the communication between the payer’s device and the payee’s acceptance devices for electronic payments |
| 29. Traceability | PSPs must ensure all payment transactions and interactions are fully traceable, using uniquely identified, securely logged, and time-synchronized communication sessions to enable complete post-event verification |
| 30. General obligations for access interfaces | Account servicing PSPs offering online accounts must provide at least one secure, standardised interface that enables authorised third-party providers to identify themselves, access account data, and initiate payments using the bank’s authentication procedures; maintain confidentiality and integrity of credentials; follow recognised communication standards with transparent documentation and testing facilities; and ensure ongoing regulatory compliance under supervisory oversight |
| 31. Access interface options | Account servicing PSPs must provide access for third-party providers either through a dedicated interface or by allowing them to use the same interfaces offered to their own payment service users for authentication and communication |
| 32. Obligations for a dedicated interface | Account servicing PSPs using dedicated interfaces must ensure they perform as reliably as user-facing interfaces, define transparent performance indicators monitored by authorities, avoid creating obstacles for third-party providers (such as unnecessary redirections or extra authorisations), and publish quarterly statistics on the interfaces’ availability and performance |
| 33. Contingency measures for a dedicated interface | Account servicing PSPs must have contingency plans for interface failures, notify affected third parties and authorities, and allow temporary use of customer-facing interfaces during outages; regulators may exempt providers from this requirement if their dedicated interfaces consistently meet reliability and performance standards |
| 34. Certificates | PSPs must identify themselves using qualified electronic certificates under the eIDAS Regulation, which include their PSD II authorisation number, service role (e.g., account servicing, payment initiation, or information services), and competent authority details, ensuring secure and interoperable electronic identification across the EU |
| 35. Security of communication session | All PSPs must use strong encryption to secure data exchanges, keep sessions short and properly linked, include clear references to users and transactions, and protect authentication credentials from disclosure, promptly notifying users if confidentiality is compromised |
| 36. Data exchanges | Account servicing PSPs must securely share account and transaction data with authorized third parties, notify them of errors, and ensure access is limited to user-approved accounts, with usage frequency controlled |
Leave a Reply