PSD2 Security Obligations
PSD2 has added many additional compliance obligations on the firms that fall within its scope – perhaps the most controversial are those known as the PSD2 Security Obligations set out in Chapter 5 of the Directive under the heading: “Operational and security risks and authentication”.
(Note: the below is a high level review of certain potential issues and is not to be relied upon in any definitive manner nor as legal and/or regulatory advice).
These new PSD2 security obligations can be parsed into 3 main topics, namely:
- Management of operational and security risks
- Authentication, and
- Incident reporting.
EmoneyAdvice.com is following their development as each topic will have either EBA guidance or regulatory technical standards applied to them.
PSD2 Security Obligations – Management of Operational and Security Risks (EBA Guidance Applies)
While many regulated payment service providers will have policies, systems and controls to manage their operational and security risks, PSD2 solidifies the requirements backed with guidance from the EBA.
The key requirement of these provisions is the establishment and maintenance of a Risk Management Framework document. An updated version of the framework document will be required to be submitted to the PSPs competent authority at least on an annual basis. In doing so, the PSP must also comment on the adequacy of the mitigation measures and control mechanisms implemented in response to those risks. This will involve a form of auditing function.
In complying with these requirements, the EBA will issue guidelines, subject to the principle of “proportionality”. This means that all PSPs will be required to be compliant with each guideline:
“but the precise steps that they are required to take to be compliant may differ between PSPs, depending on their size, business model and complexity of their activities”.
What are the EBA Guidelines on Security Measures for Operational and Security Risks under PSD2?
Guideline 1: Governance
- Operational and security risk management framework
- Risk management and control models
- Outsourcing
Guideline 2: Risk Assessment
- Identification of functions, processes and assets
- Classification of functions, processes and assets
- Risk assessments of functions, processes and assets
Guideline 3: Protection
- Data and Systems Integrity and Confidentiality
- Physical Security
- Access Control
Guideline 4: Detection
- Continuous monitoring and detection
Guideline 5: Business Continuity
- Business continuity management
- Scenario based business continuity planning
- Testing of Business Continuity Plans
- Incident Management and Crisis Communication
Guideline 6: Testing of Security Measures
Guideline 7: Situational awareness and continuous learning
- Threat landscape and situational awareness
- Training and security awareness programs
Guideline 8: PSU Relationship Management
- Payment service user awareness on security risks
- PSU secure communication and reporting procedures
PSD2 Security Obligations – Strong Customer Authentication (EBA Regulatory Technical Standards Apply).
Perhaps one of the hottest topics related to the new security obligations under PSD2 relates to the use of “Strong Customer Authentication” (referred to hereafter as “SCA”) or as it is sometimes referred to as: “2 Factor Authentication”.
What is SCA?
Under the Directive definition, SCA means: an authentication based on the use of two or more elements categorised as:
- knowledge (something only the user knows) – eg
- possession (something only the user possesses) – eg mobile device, and
- inherence (something the user is) – eg biometrics,
that are independent, in that the breach of one does not compromise the reliability of the others, and is designed in such a way as to protect the confidentiality of the authentication data.
The above are referred to as the “SCA Elements“.
Requirements under the EBA Regulatory Technical Standards
- One Time Authentication Code / OTP: Authentication based on the SCA Elements shall generate an authentication code – which can only be accepted once.
- Rules on the authentication code:
- The auth code can’t be derived from any of the above SCA Elements
- A new auth code can’t be generated based on the knowledge of a previous auth code
- The auth code can’t be forged
- When a customer fails to correctly generate an auth code:
- None of the SCA elements can be identified as incorrect
- Only 5 attempts allowed before a temporary or permanent block
- Reauth required when inactivity occurs for up to 5 minutes.
Electronic remote payment transactions either made directly (or via a payment initiation service provider) must apply SCA that includes elements that dynamically link the transaction to a specific:
- amount; and
- payee
The payer is also to be made aware of the amount of the payment transaction and of the payee – any change to these factors must result in a new authentication code being generated.
When is it required?
While there are some exemptions available, SCA is required to be applied in a general sense when a payment service user either directly (or indirectly via an account information service provider):
- accesses its payment account online
- initiates an electronic payment transaction, or
- carries out any action through a remote channel which may imply a risk of payment fraud or other abuses.
Rights of TPPs
Account servicing payment service providers must allow TPPs (ie payment initiation service providers and account information service providers) the ability to rely on the authentication procedures provided by account servicing payment service providers.
Exemptions
SCA will not be required, under certain strict conditions related to the following scenarios:
- Only accessing payment account information
- Contactless payments at point of sale for low value amounts (eg €150)
- Unattended payment terminals for the purpose of paying a transport or parking fare
- Trusted beneficiaries and recurring transactions
- Payments to self
- Low value transactions (eg €30)
- Transaction Risk Analysis – monitoring required and only available for capped amounts.
- Secure corporate payments
PSD2 Security Obligations – Major Incident Reporting (EBA Guidelines Apply).
PSD2 implements 2 key security incident reporting requirements, namely for the PSP to inform:
- Its Supervising Authority: on becoming aware of a major operational or security incident; and
- Its Customers if the event impacts their financial interests – this notice must be issued “without undue delay” and inform the customer of the incident and of all measures that they can take to mitigate the adverse effects of the incident.
EBA Guidelines Apply
Guidance for the PSP is provided to cover the following areas:
-
Incident classification
-
Notification Process
-
Delegated and consolidated reporting
-
Operational and Security Policy
-
Supervisory Authority Reporting Template