1. PSD2 and Open APIs – Advapay 2017
Martin Hawes - CISSP

2. Agenda PSD2 is driving Open API – what is an Open API?
What problems can be solved
What does a modern bank look like?
What are the risks?
Example implementation
How security can be hardened
What is required?
Keep secure to keep customer trust

3. PSD2 is driving Open APIs for banking – what is an Open API?
API = Application Programming Interface
A user interface for software, rather than a user interface for people
Like an electrical power socket, API supply a complex service through a simple network connection to be consumed by the customer
Complexity is abstracted by the API- No need to run a power station.
There is an economy of competing Open APIs with different offerings and prices- like choosing from many electricity suppliers.
It is possible to supply an API as well as consume – like selling power from house solar panels
Api university

4. Why use an Open API? Benefits
Inventors can combine Open APIs in complex solutions
Available over networkable APIs – Postcode details, Mapping from Google Maps, Taxi Hailing…think Pokemon Go
Even Credit card processing from Stripe and banking from Monzo
Innovation can be in hours or days, not months.
Example:
Type in your browser
api.postcodes.io/postcodes/PE192TR
Api university

5. Problems it can solve – payment aggregation
What’s my current status? Should I buy this TV?
I need statements from many organisations
An aggregator :
Can read statements from all and combine
Make prediction based on past needs 
Could be my current account bank
Bank A
Current Acc
Aggregator
Combined
View &
Analysis
Bank B
Credit card
Bank C
Savings Acct
Api university
Current debit account, credit card accounts, savings accounts…
Most transactions are on my credit card , so my bank account is not interesting

6. Problems it can solve – reducing transaction costs
Connecting to Automatic Clearing Houses for direct payments
Avoids card scheme interchange charges
Large merchants can initiate payments
Small merchants use PSP
Source
Bank
ASPSP
‘Issuing Bank’
ACH
Large Merchant
Recip.
Bank
Api university

7. A vision of modern banking with APIs
Bank used APIs to build customer experience
Consume from:
Fintech
API converted legacy
Other PSD2 banks
Supply:
Open API for PSD2
Browser
Mobile
Graphic Source :-
Api university

8. PSD2 Forces banks, with customer permission, to give access to:-
Aggregators
Payment Initiators
Other banks
Technical solution
Not defined by PSD2 (unlike card payments)
National and international APIs developing – Open Bank project, BNP Paribas Open Bank Project

9. But.. How can your customer be sure his money transfer is secure?
Is open banking as secure as traditional banking payments?
Is it the same protection as enterprise security, with firewall, IPS ..?
Or do I need something more?
Graphic source- teiss.co.uk

10. Overview of PSD2 – possible schematic.
TPP Registration
TPP
Large Merchant
or Aggregator
EBA
Certificate
Registration / validation
Revocation
Trust SP
Approved
Provider
FSP Registration
Certificate
Registration / validation
Revocation
Mutual TLS, eIDAS certs
TLS
Oauth2.0 via browser
FSP
Issuing Bank
2 Factor authentication
Entities registered with the EBA – when approved a Trust SP issues a signs a certificate for the approved entity. Revocation to removal of entities would need to be supported (or use a whitelist)
Then entities such as TPP and FSP can establish mutual authentication and secure TLS connections using these certificates.
eIDAS, the new European signature framework may be used as the standard – Thales provides HSMs certified for eIDAS.
Oauth2.0 is the protocol often used to enable a third party to be given rights to access a user’s data based on an established relationship that the user has with another entity which already has a method of authentication established. For example authenication by Facebook
In Oauth 2.0 TPP:
TPP first requires ‘Client Secret’ which is likely to involve registration with the EBA and the Trust SP.
Then for initially for each customer request, the TPP requests from the FSP a token for access for the user.
The FSP requests 2FA with the customer and provides an ‘access token’
[Access Token contains JSON Web Token (JWT), JWT is secured HMAC256]
This token is stored by the TPP for later use over a defined lifetime.
For aggregation (read only) a token would be used multiple times so that the TPP can login to multiple FSP with only a login to the TPP
For most payment intitiation tokens, 2FA is required each time.
Special cases like tokens that give permission to pay monthly are possible.
Tokens are sensitive so should be encrypted when at motion and at rest.

11. The fundamental security requirements linked to PSD2
Strong authentication
Between customer and bank
Between TPP and ASPSP (Issuing Bank) (token based)
2 or more independent elements for 2FA, binding of payment amount.
Secure data storage and communications
Privacy of connections (data in motion)
Compliance with data protection laws such as GDPR (covers data at all times – at rest, in use or in motion)
Storage of access tokens
Certificate issuance by competent authority in each country
eIDAS certificates are only intended for identification between servers of PSPs – they are not for payment system users (PSUs)
eIDAS is only a recommendation
Mutual Authentication of entities
Secrecy of access tokens
Proof of membership of the scheme
Secrecy of customer data (including for GDPR)
Authentication of messages (particularly payments)

12. PSD2 – Solutions shopping list
Technologies
Oauth2.0 (like login by Facebook) then maybe enhance to OpenID Connect 1.0
SAML? (uses digital signature)
Entities
*Issuing Bank – TLS, Random Number, HMAC, Data encryption at rest, 2FA for payments
*Aggregator / Merchant – TLS, Data encryption at rest, 2FA
*All - PKI for certification and Signature, TLS, eIDAS
Note * = HSMs and Vormetric from Thales can be used to harden the security
Ebics, scraping, national apis 
OpenBankProject 
F2 Framework 
Plaid -  a tool that enables applications to connect with user’s bank accounts. Should get a big boost from PSD2.
3rd party providers Kontomatik Banking API437 Coverage: UK, Poland, Czech Republic, Slovakia, Spain, Portugal, Mexico, Brazil, Russia.
Banks (listing by HO location, most operate in multiple countries France: BNP Paribas Open Bank Project152 Coverage (BNP Paribas Group Banks only): UK, US, Poland, France, France, Turkey, Italy
Background
Legal/regulation – not technical specifications
We cannot just implement HSM functions against an ‘industry specification’ – this is not a traditional HSM box sale
The EBA RTS is high level and not very technical and not a specification!
The EC/EBA expects industry collaboration to deliver against its requirements – we are not involved in any of the working groups
Multiple implementations possible (and expected)
RTS is technology neutral to promote future proofing – the EBA was forced to remove some technology specific requirements recently
The UK via the CMA (and hence the OBWG) is trying to promote a standard API – not sure if this approach will be adopted across the EU
The need to differentiate implies that multiple bank API models will emerge – a third party industry will likely emerge to provide a mapping to multiple APIs
Requirements still not finalised
150+ detailed responses to draft RTS has delayed everything
Many players are adopting a wait and see response

13. Use HSMs – as in traditional payments. Why ?
HSM enables:
People - enables enforcement of security policy for key management
Process - facilitates audits and procedures
Technology- Cryptography processor for encryption. Hardened, tamper resistant. Protects Keys and algorithms

14. Any Questions?
PSD2 through Open APIs will enable banking opportunities and innovation of new solutions
Strong security will be needed to maintain customer trust in fintech
Existing protocols and trusted hardware security can provide the answer
My contact is: