PSD2 and Open banking: EBA Security and Operational Risk guidelines – Evolution or Revolution?


Notice: Undefined index: file in /nas/content/live/huntsman/wp-includes/media.php on line 1380
Share on Facebook0Share on Google+0Tweet about this on TwitterShare on LinkedIn0Email this to someone

PSD2 – The second EU Payment Services Directive – is set to open up and expand the range of financial services offerings and organisation types way beyond the traditional banks.  As a directive the payment services rules are defined by the EU but must be implemented by member states in either local legislation or regulations.

In the case of the finance sector, which is highly regulated anyway, the European Banking Authority (EBA) has translated PSD2 into defined security management requirements centrally.  The EBA has published sets of regulations that define the requirements around operational and security risk, the management and reporting of incidents and the mechanisms for authentication and connection security.  These can be found at:

Although they don’t exactly make easy bedtime reading they do impose a set of security obligations for businesses that will have access to the banking systems (through open banking APIs) or who are conducting account information or payment initiation services.

For new Fintech start-ups, or existing smaller service businesses, these are most likely to be a useful set of security provisions; although as with any imposed regulatory standard, it might be viewed as somewhat overkill and a cost on doing business.

However for larger, established banks or major retailers, they could be no worse than pre-existing security requirements or expected norms; so they might for instance be viewed as running in parallel to PCI-DSS requirements on credit card information and hence a matter of ensuring compliance to the new sets of standards as an ability to demonstrate existing practices and safeguards; rather than being something that requires new controls or governance processes.

In the section below we will talk briefly about the first of these documents – Guidelines on the Security measures for operational and security risks.

The PSD2 Operational and Security Risk Guidelines

The EBA guidelines don’t pose any particularly new challenges for organisations that have an existing Information Security Management System (ISMS) in place.

The core structure (as seen in our infographic on this page) follows established principles of risk assessments, control frameworks and monitoring and assurance activities around these.  An approach commonly referred to as a PLAN-DO-CHECK-ACT management system.  Specifically the documents present the 9 guidelines as summarised below (If you don’t want to have to read through them, just skip ahead to our views and observations) :

Guideline 1: General Principle

  • The requirement is for all service providers to comply with the EBA guidelines; the level of detail/diligence should be based on the size, nature, risk and complexity of the services

Guideline 2: Governance

  • An operational and security risk management framework
  • Policy, roles, reporting lines, procedures/systems to identify, measure, monitor and manage risks
  • Documented reviews, including as part of change processes
  • Risk management and control models
  • Three lines of defence – oversight, independence, resource
  • Internal or external audit
  • Effective security measure in outsourced services
  • Contracts, service levels, performance targets – with monitoring and assurance

Guideline 3: Risk assessment

  • Identified inventory of business functions, key people, privileged users, dependencies
  • Information asset inventory, system configurations, internal/external links
  • Criticality of systems and information, need to know access rights, access logs, identify and investigate anomalous activities
  • Risk assessments of functions, processes and assets
  • Continuous monitoring of threats – risk assessment as threats change and changes to controls

Guideline 4: Protection

  • Implement preventative security measures
  • Defence-in-depth, multi layers of controls
  • Confidentiality, integrity and availability of assets to protect against abuse or theft
  • Change in response to changing threat and other factors
  • Protect sensitive data in storage and transit – confidentiality and integrity on data and systems
  • Segregation of duties, least privilege, including development/testing/production
  • Minimised data in storage, transit, processing etc.
  • Up to date software (including checks on access)
  • Appropriate physical security measures – access limited to authorised personnel and reviewed
  • Access only for authorised people, restrict access to those with a business requirement (i.e. minimum possible)
  • Strong controls over privileged access – strong authentication monitoring for anomalies
  • Remote admin access highly limited with strong authentication
  • Controls on tools used to configure/apply/enforce access controls

Guideline 5: Detection

  • Continuous monitoring and detection
  • Capability and process to monitor and detect anomalies including IDS systems
  • Coverage of relevant internal and external factors for business, IT admin, transactions for broadest detection of insider misuse or advance threats
  • Detective measure for information leaks, malware, security threats public vulnerabilities/patches
  • Monitoring and reporting of operational or security incidents
  • Define thresholds/events/indicators for security incidents
  • Processes for consistent monitoring, follow-up
  • Reporting and customer security complaints

Guideline 6: Business continuity

  • BCM plan to avoid service losses
  • Exposure to disruptions/and assess impacts – critical functions, dependencies, risk based approach
  • BCM/contingency plans to avoid disruption and recover from failures
  • Assess impacts of various crisis scenarios
  • Develop response recovery plans – focus on impacts of critical functions, be clearly documented and readily available – and updated
  • Test BCM plans at least annually and update based on results
  • Broad range of scenarios, extreme but plausible, challenge assumptions, communications in place, verify availability of staff
  • Monitor effective tests and update plans
  • Have effective incident and crisis management and communication

Guideline 7: Testing of security measures

  • Testing to check robustness and effectiveness of controls to reflect new threats/vulnerabilities
  • Test when changes are made (part of change management) and after major incidents
  • Include payment terminals, authentication devices, user code
  • Testing of service providers independent, based on level of risk
  • Monitoring and update security based on testing outputs

Guideline 8: Situational awareness and continuous learning

  • Processes, structures to monitor security and operational threats (TI) – sharing externally, being in community, learn and share lessons
  • Actively monitor technical developments
  • Security awareness training for staff generally
  • Targeted specific training for privileged/key staff
  • Require personnel to notice/report unusual activity or incidents

Guideline 9: Payment service user relationship management

  • Establish processes to give guidance to payment service user organisations
  • Update in light of changing/new threats/vulnerabilities
  • Detail responsibilities clearly
  • Allow PSUs to disable unwanted functions, set controls on spending limits, set alerts for failures
  • Keep all parties informed about updates in procedures
  • Answer questions, assist, handle complaints and respond to anomalies

Observations on the PSD2 Requirements

At first glance these requirements are fairly standard “security management” good practices.  However, there are some nuances due to the relative newness around things like behaviour anomaly detection and threat intelligence.  These are perhaps, more recent control safeguards or “good practices” that have been added to the cyber security fold since the last cycle of some more established standards.   There is hopefully very little in these requirements that a large/medium/small bank or retailer is not already doing.  To answer our initial question then – most definitely a case of evolution in terms of security and compliance management.

Impact of PSD2 on Small Business

Where this set of guidelines might have more impact is within smaller businesses that are registering as PSD2 service providers – EITHER small FinTech start-ups (where the entirety of their business model relies on the PSD2 and open banking frameworks) OR established businesses that are now able to augment existing services and products with the provision of payment services (perhaps a retailer or service provider that will handle small payments directly rather than using a card scheme).

For businesses in these categories security may not have been as large a factor in the design of their businesses, systems and applications as perhaps it should be. Here, we may see the adoption of EBA guidelines as more of a revolution in the approach to security.

While they might carry liability for a resultant fraud, the size and resources of smaller businesses may simply mean that there isn’t space on the balance sheet to provide redress, refunds or compensation.  A significant exposure in the systems of a smaller AISP or PISP therefore could be highly serious as the security issue rapidly becomes a theft or fraud impact.

Insurance, a requirement of being part of the PSD2 regulated payment community, is also unlikely to pay out to cover losses if security controls were found to be lax or missing.

PSD2 – Outcomes for consumers and providers

While the presence of security guidelines for payment and information providers under PSD2 is a good thing for consumers and banks, it does not mean that smaller businesses, start-ups or non-FS businesses providing financial services will have adequate security to match the risk they could face (or cause).

For the providers themselves the EBA guidelines do give them a useful best practice yardstick against which to define and measure security effectiveness.  So there is hope that this new world of payment processing and open banking will be robust and trustworthy at a systemic level.  As long as security gets the attention it deserves.

As to whether these guidelines represent evolution or revolution… it rather depends on what security maturity and cyber readiness you already have in place when your PSD2 services are launched.

To discover the cyber security implications of PSD2, go to our PSD2 web page.

You can also download our Infographic:

Benchmark your existing security strategy with our 5 Step Cyber Security Tool: