Payment Service Directive 2 (PSD2) - The Good , The Bad and The Ugly

1. ISACA Ireland Chapter Conference 2018 Payment Service Directive 2 (PSD2) - The Good, The Bad and The Ugly Security & Technical Track Payment Services Technical Changes Ross Spelman

2. Financial services providers warned they face extinction in next decade “Digital transformation is largely a myth as institutional mindsets, processes and structures stand firm,” said David Furlonger, an analyst at Gartner. According to forecasts from Gartner as many as 80 per cent of what it calls “heritage financial firms” will either have gone out of business or be considered irrelevant within 12 years. Many banks and insurers are underestimating the degree of change that digital technology will bring to the industry in the coming years. Ref: https://www.irishtimes.com/business/technology/financial-services-providers-warned-they-face-extinction-in-next-decade-1.3680525 Ref: https://www.gartner.com/en/newsroom/press-releases/2018-10-29-gartner-says-digitalization-will-make-most-heritage-financial-firms-irrelevant-by-2030

4. The Ugly

5. The Ugly Can’t someone else do it? Middle men Payment Service providers do already exist but currently rely of questionable methods, typically requiring that consumers give over their login credentials to third parties, which in turn through “screen-scraping”, effectively impersonate their clients to their on-line banks. Sounds dodgy….It is ! • Screen Scraping • Credential Sharing • No standards • No liability • Potentially Insecure

6. The Idea Current Future

7. The Idea • Banks have to allow a secure way for a customer to authorise a third party provider to have direct access to account and transactions data, and make and authorise payments via APIs (Application Programming Interface). • These third parties can offer payment services but they will not have to be banks. • Merchants (like Amazon) will be able to take payments from your bank account without using an intermediary like Visa or PayPal. They will access your bank account directly from your bank using an API • Customers privacy and the security of their information must be assured through multi-factor authentication, granular authorisation controls (“entitlements”) and enhanced security for back-end payment systems. EU Directive, administered by the European Commission (Directorate General Internal Market) to regulate payment services and payment service providers throughout the European Union (EU) 

8. The Impact • Challenges • Stay compliant and still benefit from change • Remain liable and open bank system to third parties • Avoid being further distance from customers • Protect current revenue streams • Benefit from new services • Access, trust and confidence with account holder • Opportunities • Offer new commercial services (paid / free) • Become a third party provider (cross-sell / consolidate customer) • Encourage FinTech innovative services on your behalf (bind / attract customers) • Direct dialogue between user and its account servicing bank (reduce intermediaries) User Developer Environment Application Bank agnostic TPP ASPSP Fraud / Reporting Consumers and Disputes PISP /AISP APIs Beyond compliance value-added APIs ? Account

9. The Impact Security Operational & Security Risk Management Regulatory Technical Standards Major Incident Reporting Back-end Reporting Interfaces • The Regulatory Technical Standards for strong customer authentication and common and secure open standards of communication, • The Guidelines on security measures for operational and security risks of payments services, and • The Guidelines on major incident reporting

10. Interfaces

11. Regulatory Technical Standards The regulatory technical standards define how, in practice, access to accounts for Third Party Providers (TPPs) and enhanced security and authentication requirements will be implemented. PISPs and AISPs have the right to rely on the authentication procedure provided by the ASPSPs. Under the SCA procedure, a valid combination of the authentication elements will generate an authentication code to the payer’s PSP, specific to the amount and payee agreed by the payer when initiating the transaction. This is also known as “dynamic linking”. The RTS requires PSPs to ensure the independence of all the elements used in the SCA procedure and the channel, device or mobile app through which the authentication code is generated and received to be “independent or segregated” from the channel, device or mobile app used for initiating the electronic payment transaction. Secure Access and Operation For All Parties Request Their App Your App API Data

12. Regulatory Technical Standards Strong Customer Authentication SCA Exemptions Payment API, Gateway, Instrument and Channel Security Personalised Security Credentials Regulatory Technical Standards Access-to-Accounts • EBA RTS objectives • Ensure security for Payment Services Users (PSUs) and Payment Service Providers (PSPs) • Ensure safety of PSUs funds and personal data • Securing and maintaining fair competition • Ensuring technology and business model neutrality • Allowing the development of user-friendly and innovative means of payment • RTS technical scope • Strong Customer Authentication • Common and Secure Open Standards of Communication Transaction Risk Analysis Monitoring Operational Readiness API Security Review of Security Measures Secure Communications 10 Controls Domains – 36 Control Areas

13. Regulatory Technical Standards Strong Customer Authentication Strong customer authentication should be implemented where the payer has access to a payment account online; initiates an electronic payment transaction or carries out any action through a remote channel potentially exposed to fraud or other abuses. SCA should leverage at least two of three types of authentication "knowledge", "possession", "inherence“: • Password • Passphrase • Pin Number • Sequence • Secret Facts • Mobile phone • Wearable device • Smart card • Token • Badge • Fingerprint • Facial features • Voice patterns • Iris Format • DNA signature Something you know Something you own Something you are When will strong customer authentication become mandatory? SCA will become mandatory 18 months after the entry into force of the RTS:September, 2019.

14. Regulatory Technical Standards Common & Secure Communication • Common and Secure Communication (CSC) introduces: • Customer Consent – customers must give explicit consent to the AISP or PISP • Secure Communication – ASPSP must provide AISP’s / PISP’s a secure communication channel in order for them to access the payment account: • APIs – Application Programming Interfaces which must allow TPPs to provide payment initiation or account information without difficulty • Banks must grant access to TPPs using a dedicated interface with: • Additional TPP security authentication allowing the ASPSP to know the TPP is accessing the account • Formal agreement from the customer on the access and use of their account • Compliance with the GDPR (General Data Protection Regulation) Platform overview

15. Regulatory Technical Standards Certification and Authentication Requirements Since PSD2 APIs provide access to sensitive data in arbitrary banks there is an assurance requirement, i.e. certification requirement. This also implies specific CAs (Certification Authorities) as well as centralised registries holding data about PSD2 service providers. Mandatory use of certificates (RTS) • payment initiation services • account information services Highly recommended use of certificates • account servicing (banks) eIDAS is an EU regulation on / a set of standards for electronic identification and trust services for electronic transactions in the European Single Market. 

16. Regulatory Technical Standards • Regulatory Technical Standards • End user interaction and background process Eidas Qualified Trust Provider • End user requests TPPs to access data from Bank • Bank carries out Secure Customer Authentication to confirm identity and consents • Bank checks on NCA databases that the TPP is registered and approved • Bank issues access token to TPP • TPP uses access token each time they access Bank • Bank checks with QTSP the eIDAS Seal and Certificate • Bank checks on NCA database that TPP is still registered and approved on each access attempt Banks/Financial Institutions ASPSPs Competent Authority Database API Aggregation Services AISPs PSPs PISPs

17. Regulatory Technical Standards • Regulatory Technical Standards • Current and future state compliance Existing Payment Instrument and Channel compliance Future Payment Instrument and Channel compliance The key considerations • Authentication of authorised third parties, ASPSP, PISP, CISP, AISP, PSP. • Interface requirements for ASPSPs to provide access to accounts to authorised AISP, PISP and CISPs • Increased security standards for secure communications for online accessible accounts. • Minimum standards for protecting customers personalised security credentials during creation, association, delivery, destruction. • Monitoring remote transactions for online accessible payment accounts. • Standardisation of measures for customer authentication when accessing accounts, initiating payments or activities which may be high risk • Frequent assessment and audit of security measures for the competent authority

18. Regulatory Technical Standards IAM Capabilities & Technical Requirements • Current and future state considerations API threat Protection Threat protection provides security for APIs from various malicious attacks that may occur. It protects the APIs from adaptive threats like bad bots and automates threat protection at the API layer for OWASP Top 10 threats. • Secure the APIs from OWASP Top 10 threats like SQL injection and JSON threat • Threat protection against XML, JSON, and DoS/DDoSattacks Risk Based Authentication • For risk scoring, it provides device and application context, including device type, operating system version, geographic location, and advanced detection of rooting, jailbreaking, or similar mobile operating system security bypass hacks • Provides multi-factor authentication that can detect and block fraud in real-time, without any interaction with the user. It integrates with any online application and analyses the risk of online access attempts and transactions. Utilising contextual factors such as device ID, geolocation, IP address and user activity information, it can calculate a risk score and recommend the appropriate action API security & Secured Communication Self-contained, standard based cryptographic stack and communications layer enables an isolated, end-to-end encrypted communications channel between the service provider and its customer’s secured mobile app. No third party can access these communications. All cryptographic material is securely stored, ensuring that neither the user nor the application developer can access it. Knowledge or inherence factors like PINs or biometrics are similarly protected.

19. Regulatory Technical Standards IAM Capabilities & Technical Requirements • Current and future state considerations Session Management Define the Policies in the session like: maximum login attempts, lockout duration, and session expiry period PKI infrastructure to digitally sign each transaction Digitally sign each transaction and/or authentication request, which results in a unique signature every time. This ensures that the request cannot be reused or used to create a signature that is valid for any future transactions and/or authentications Business Integration with Consent management • Capture, store and manage the consent, for example: TPP will request explicit consent from the PSU in order to initiate payments or access information from the PSU’s account • The consent capture and management should be integrated into the API access control and authentication process Policies engine and integration • Manage the authentication policies • Management policy lifecycle, execution, and reporting • A policy includes assertions that determine the authentication method, identity credentials, transport method, and routing method for the web service or XML application

20. Back-end

21. Operational & Security Risk Management The Guidelines on security measures for operational and security risks of payments services aim to ensure that payment service providers have in place appropriate security measures to mitigate operational and security risks. These should include the establishment of an effective operational and security risk management framework; processes that detect, prevent and monitor potential security breaches and threats; risk assessment procedures; regular testing; and processes to raise awareness to Payment Service Users on security risks and risk-mitigating actions. Payment Systems Security Risk Assessment 3 Awareness Protection 8 4 Governance 2 7 5 Testing Detection 6 Business Continuity User 9 119 Controls Areas GL 1 defines a general principle on proportionality. This is then followed by GL 2 to GL 9, which cover governance, including the operational and security risk management framework, the risk management and control models, and outsourcing; risk assessment, including the identification and classification of functions, processes and assets; and the protection of the integrity and confidentiality of data and systems, physical security and access control.

22. Operational & Security Risk Management GL 3. Risk Assessment Inventory GL 4. Protection Data Use GL 2. Governance GL 3. Risk Assessment Risk GL 2. Governance GL 4. Protection GL 5 Detection GL 7. Testing Security GL 8. Awareness GL 9. User Functionality Themes & Guideline Areas

23. Reporting

24. Major Incident Reporting • Assess and notify operational and security incidents based on: • Transactions affected • Service Downtime • Payment Service Users Affected • Economic Impact • Other payment services affected Major Incident Classification Payment Incident Management Operational and Security Policy Notification Process Consolidated Reporting 4 Controls Areas

25. Major Incident Reporting • Regulation 119 states where a major operational or security incident occurs, a payment service provider is required to notify the Central Bank without undue delay. • The EBA Guidelines on major incident reporting under PSD2, define an operational or security incident as, “a singular event or a series of linked events unplanned by the payment service provider which has or will probably have an adverse impact on the integrity, availability, confidentiality, authenticity and/or continuity of payment-related services.” • The EBA Guidelines set out specific criteria for the classification of an operational or security incident as being a major incident. • Payment service providers are expected to submit major incident reports to the Central Bank within four hours of detection, regardless of whether that incident is detected during out-of-office hours. • The Central Bank requires payment service providers to use a defined template when reporting a major incident.

26. PSD2 – Additional Reporting Requirements Operational and Security Risk Reporting Regulation 118 of the Payment Services Regulations 2018 requires PSPs to provide to the Central Bank, on an annual basis, an updated and comprehensive assessment of: The operational and security risks relating to the payment services provided by the PSP and The adequacy of the mitigation measures and control mechanisms implemented in response to those risks Payment Fraud Statistics Reporting The EBA has published Guidelines on reporting of Payment Fraud Statistics by PSPs to national competent authorities (NCAs) such as the Central Bank. These guidelines are effective from January 2019. In advance of the publication of these guidelines, as an interim measure that NCAs should proceed to organise the reporting of payment fraud data for 2018 at a national level. The extent of this data collection by NCAs for 2018 was left to those authorities’ own discretion.The Central Bank has decided to seek a limited amount of payment fraud data for 2018 from PSPs. Denial of Service Reporting Regulation 44(3) of the Payment Services Regulations 2018 provides that credit institutions are required to inform the Central Bank without delay when an application for access to their payment account services by a Payment Institution is rejected.

27. Summary

28. The Approach Banks, TPPs and FinTechsshould be interconnected to introduce innovations. • Approach • Open up towards development community • Provide API, tools, community support • Promote initiative by embedding developer apps directly on website • Provide tools to allow design of apps across platforms: Android, iPhone etc. • Create new services (compliance, validation, TPPservices) • Focus on trust and expertise • Consumers have established relationships with Banks but not with third parties • Provide trusted value added services • Be innovative and look to the future • Use your specific advantages • Partner to win • Try new things and take the risk to fail • Benefits • Cost effective compliance • Put account at the centre of innovation • Higher level of security • Access to new functions and business opportunities • Single standardised access to many banks • Simple enrolment and integration process • Access to development portal and APIs • Standardised procedures • The Cyber Approach… • Programme Definition • Simultaneous Delivery • Highly involved and interdependent • Test, test and test again.

29. Payment Security - The Approach Payment API, Gateway, Instrument and Channel Security PSD2 – Cyber Security Input Payment Service Directive 2 aims to regulate payment services and payment service providers throughout the European Union. Cyber security plays a key role across three core components of the directive. Strong Customer Authentication SCA Exemptions Risk Assessment Personalised Security Credentials Operational • & Security Risk Management Regulatory Technical Standards Regulatory Technical Standards Cyber Areas Access-to-Accounts Major Incident Classification Payment Systems Security Awareness Protection Cyber Risk Transaction Risk Analysis Monitoring Governance Major Incident Reporting Operational Readiness API Security Operational and Security Policy Notification Process Consolidated Reporting Testing Detection Review of Security Measures Secure Communications 10 Controls Domains – 36 Control Areas Business Continuity Payment Incident Management User 119 Controls Areas 4 Controls Areas