1. Payment Service Directive 2 (PSD2) - The Good, The Bad and The Ugly
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:
Ref:

4. The Ugly

5. Can’t someone else do it?
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. Stay compliant and still benefit from change
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
Application
Developer Environment
Bank agnostic
TPP
ASPSP
Fraud / Reporting
Consumers and Disputes
PISP /AISP APIs
Beyond compliance value-added APIs ?
Account

9. Major Incident Reporting
The Impact
Security
Regulatory
Technical
Standards
Operational
& Security
Risk Management
Major Incident Reporting
Interfaces
Back-end
Reporting
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. Secure Access and Operation For All Parties
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
Their
App
Request
Your
App
API
Data

12. Regulatory Technical Standards
Strong Customer Authentication
SCA Exemptions
Payment API, Gateway, Instrument and Channel Security
Personalised
Security
Credentials
Access-to-Accounts
Regulatory
Technical
Standards
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
Secure
Communications
Review of
Security Measures
10 Controls Domains – 36 Control Areas
Authentication requirements
Requirements of possession elements
Transaction Monitoring
Authentication code
Review of the security measures
Creation and transmission of credentials
Contactless payments at point of sale
Transaction risk analysis
Security Monitoring
Dynamic linking
Transport and parking fares
Invalidation and optionality of exemptions
Exemptions
Trusted beneficiaries
Requirements for identification
Independence of the elements
Recurring transactions
Destruction, deactivation and revocation
Low-value transactions
Association with the payment service user
Data exchanges
Payment account information
Security Payment Service Credentials
Traceability
Payments to self
User communication channels
Security of communication session
Requirements of inherence for devices and software
Delivery of credentials
Renewal of personalised security credentials
Requirements of knowledge elements
Obligations for dedicated interface
Fraud review requirements
Delivery of authentication devices
Delivery of authentication software
Certificates

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. Platform overview 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
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
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. IAM Capabilities & Technical Requirements
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/DDoS attacks
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. IAM Capabilities & Technical Requirements
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
Governance
Risk Assessment
Business Continuity
Detection
Protection
Testing
Awareness 3 8 4 2 7 5 6
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
Functionality
GL 9. User
Themes & Guideline Areas

23. Reporting

24. Consolidated Reporting
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
Payment
Incident
Management
Notification Process
Consolidated Reporting
Major Incident
Classification
Operational and
Security Policy
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 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 FinTechs should 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, TPP services)
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. Major Incident Reporting
Payment Security - The Approach
PSD2 – Cyber Security Input
Payment API, Gateway, Instrument and Channel Security
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
Personalised
Security
Credentials
Operational
& Security
Risk Management
Regulatory
Technical
Standards
Access-to-Accounts
Regulatory
Technical
Standards Cyber Areas
Payment Systems Security
Cyber
Risk
Transaction Risk Analysis
Monitoring
Governance
Risk Assessment
Business Continuity
Detection
Protection
Testing
Awareness
Major Incident Reporting
Operational
Readiness
API Security
Secure
Communications
Review of
Security Measures
Notification Process
Consolidated Reporting
Major Incident
Classification
Operational and
Security Policy
10 Controls Domains – 36 Control Areas
Payment
Incident
Management
Authentication requirements
Requirements of possession elements
Transaction Monitoring
Authentication code
Review of the security measures
Creation and transmission of credentials
Contactless payments at point of sale
Transaction risk analysis
Security Monitoring
Dynamic linking
Transport and parking fares
Invalidation and optionality of exemptions
Exemptions
Trusted beneficiaries
Requirements for identification
Independence of the elements
Recurring transactions
Destruction, deactivation and revocation
Low-value transactions
Association with the payment service user
Data exchanges
Payment account information
Security Payment Service Credentials
Traceability
Payments to self
User communication channels
Security of communication session
Requirements of inherence for devices and software
Delivery of credentials
Renewal of personalised security credentials
Requirements of knowledge elements
Obligations for dedicated interface
Fraud review requirements
Delivery of authentication devices
Delivery of authentication software
Certificates
User
119 Controls Areas
4 Controls Areas