Driving Behavioral Change for Information Management through Data-Driven Gree...
APIdays Singapore 2019 - Global Open Banking Frameworks and Standards: Luca Ferrari, Senior Solution Architect, Red Hat
1. Open Banking and regulation: cause and
effect relationship
Brief navigation across the impact of introducing Open
Banking
Luca Ferrari
EMEA Solution Architect for Red Hat
2. Red Hat2
Agenda
➧ Why we are here today
➧ Origin
➧ Timeline
➧ FinTech influences
➧ Main elements
➧ Reference architecture
➧ Where are we going
4. Red Hat
Why are you here today?
4
People on social
media right now
People reading
this sentence
right now
Crazy
Multitasking!
“Wait, which
room is this?”
People laughing
at the diagram
5. Red Hat
How did we get here?
5
One possible definition:
FINTECH: an industry composed of companies that use new technology
and innovation with available resources to compete in the marketplace
of traditional financial institutions and intermediaries in the delivery of
financial services.
FinTech companies try to replace or enhance the usage of financial
services of incumbent companies
6. Red Hat
How did we get here?
6
1951
Frank McNamara creates
the Diners’ Club Card
1967
John Shepherd Barron
creates the first ATM
1971
NASDAQ introduces all
electronic trading
1973
Society for Worldwide
Interbank Financial
Telecommunication is
born
1983
Homelink, the first online
banking system, is born
1997
The first mobile payment
is realized via text
message
1998
PayPal is founded
8. Red Hat
Payment Services Directive (PSD2):
● Extend transparency rules for payment transactions (OLO transactions)
● New entities: PISP and the AISP (also TPPs)
● Information obligations of PSPs to obtain authorization to operate, register with EBA
● Banks grant access to customers’ accounts to facilitate transactions (“XS2A”) upon customers’
authorization
● PSPs to accounts managed with customer “explicit consent”
● Unauthorized payment through an initiation payment provider: ASPSP liable to user, but ASPSP
remedies against TPP
● Stricter customer authentication: PSPs to ensure stricter customer authentication:
○ access to payment account
○ initiate electronic remote payment
○ perform any other action through remote channels
Regulation
8
10. Red Hat
UK’s implementation on PSD2 obligations
Banks to provide data to third parties in standard API format
UK’s 9 largest banks to provide access to customer’s banking data via secure and
standardised form
AISPs or PISPs are authorised and regulated by Financial Conduct Authority (FCA) and
enrolled on Open Banking Directory
Additional elements:
● CFA Service Metrics API
● OpenID FAPI
Regulation
10
https://openid.net/2018/07/12/the-uk-open-banking-implementation-entity-adopts-the-openid-foundation-financial-
grade-api-fapi-specification-certification-program/
12. Red Hat
Guiding principles
12
No compulsory open banking in Singapore
Initiatives:
● Finance-as-a-Service: API Playbook by Monetary Authority of Singapore (MAS) API Guidelines
● Financial Industry API Register: list of open APIs available in the Singapore financial industry
● FinTech Regulatory Sandbox to experiment with innovative financial products or services
Private initiatives:
● open data initiatives by financial institutions led by DBS, with 155 APIs
Objectives:
❖ shape innovation with non-mandatory regulation and framework
❖ lead by example by opening data for APIs
❖ establish scalable data practices and payments infrastructure to support
14. Red Hat
Guiding principles
14
Any Bank must open up to provide fair access to data, if they want to retain their license
Similar to PSD2 and UK Open Banking in terms of approach
Focus on driving valuable digital engagements with the customer, rather than trying to monetize the base open APIs
(like in PSD2 or UK)
Expecting to lead Open Banking in Latin America
Financial inclusion is central to the Mexican Fintech Law:
● Underbanked
● Unbanked
● No mobile or internet coverage
Socio-economic benefits beyond new, low-cost banking and payments services.
16. Red Hat
Part of national Consumer Data Right (CDR)
Implement the CDR beginning with banking, energy and telecommunications
Scope of Open Banking:
● Upon request, Banks to share with the customer or a TPP information that comes from the customer
● Banks to share all transaction data via dedicated API
● Only accredited data recipients may receive Open Banking data
● Standards will be defined
● Starting point for standards is UK’s Open Banking technical specifications
Regulation
16
18. Red Hat
Regulation
18
Hong Kong Monetary Authority (HKMA) published the compulsory Open Application Programming Interface
Framework. Framework recommends using existing international technical standards.
4 phases process:
1. Third Party Providers (TPPs) can access banks’ product information
2. Banks will deploy core-banking open API functions to accept new account/product applications
3. Account information and other bank products to be allowed to TPPs. Also applicable to investments and
insurance
4. Allowing TPPs to process customer payment requests also related to investments and insurance
Banks will control of customer relationship and data, and choose which TPPs to collaborate with. In contrast to PSD2
and Open Banking in Australia and UK.
20. Red Hat
Guiding principles
20
No compulsory Open Banking requirements in Japan
Target of 80 banks to have open APIs by 2020.
Banking Act to facilitate open API architecture between financial institutions and FinTech.
Includes:
● Registration system for Electronic Payment Intermediate Service (EPIS) Providers
● EPISP to have a contract with a financial institution before providing service
● Publish standards which EPISP to satisfy to contract with financial institution
● Require financial institutions to develop a system for introduction of Open API to communicate with
EPISP
22. Red Hat
Guiding principles
Payments NZ launched a set of standards developed to facilitate Open Banking
While in UK and Australia forced banks to engage in Open Banking, New Zealand
Government asked Payments NZ start the process or being forced under regulation
The standards outline how open banking should be designed to manage risks and be secure
The standards take inspiration from UK Open Banking
The standards don’t include any principles of reciprocity
22
24. Red Hat
In the news
24
India’s Federal Bank launches open banking platform
The Banking Supervision Department is leading the regulation of an Open Banking standard
in Israel
Canada launches open banking consultation
Korean banks ordered to open up payment systems to fintech firms
Brazil could implement open banking model next year
26. Red Hat
How does this relate to FinTech
https://innovation.thomsonreuters.com/en/labs/portfolio/global-fintech-rankings.html#/
https://www.businessinsider.com/these-are-the-25-most-innovative-fintech-startups-in-the-world-2018-10?IR=T#11-oneconnect-financial-
technology-15
26
27. Red Hat
How does this relate to FinTech
[World payments report 2018]
27
28. Red Hat
Common elements ...
29
PRINCIPLES
● REST APIs
● Strong Customer Authentication
● Third party access to payments and account
information on behalf of user
● Unique identification of assets and transactions
● Fine grained entitlements and authorizations
● Prevent screen scraping
● User consent management
● Auditing of every action
● Appropriate developer experience
● Resource discovery and interaction
29. Red Hat
… which translates into
30
PRINCIPLES FUNCTIONALITIES
● REST APIs
● Strong Customer Authentication
● Third party access to payments and account
information on behalf of user
● Unique identification of assets and transactions
● Fine grained entitlements and authorizations
● Prevent screen scraping
● User consent management
● Auditing of every action
● Appropriate developer experience
● Resource discovery and interaction
● APIs standard specification
● OIDC API authentication
● IDP integration
● API policies and access control
● Call tracing and logging
● OIDC authorization and scope
● Web Application Firewall
● Business Process Management of consent
● Full platform logging and analytics
● (Self-service) Developer Portal
● Cloud Native DevOps platform and tooling
● Integration/transformation capabilities with legacy
backends
30. Red Hat
A possible architecture
31
API Registry
API Policies API Contracts
API Authorization
Admin Portal
Developer Portal
API
MANAGEMENT
layerAPI Specs
31. Red Hat
A possible architecture
32
API
MANAGEMENT
layerAPI Registry
API Policies API Contracts
API Authorization
Admin Portal
Developer PortalAPI Specs
IDENTITY
MANAGEMENT
layer
Strong
AuthN
Identity
federation
Identity
brokering
32. Red Hat
A possible architecture
33
API
MANAGEMENT
layerAPI Registry
API Policies API Contracts
API Authorization
Admin Portal
Developer PortalAPI Specs
IDENTITY
MANAGEMENT
layer
Strong
AuthN
Identity
federation
Identity
brokering
OIDC AuthN
OIDC
AuthZ
33. Red Hat
A possible architecture
34
API
MANAGEMENT
layerAPI Registry
API Policies API Contracts
API Authorization
Admin Portal
Developer PortalAPI Specs
IDENTITY
MANAGEMENT
layer
Strong
AuthN
Identity
federation
Identity
brokering
OIDC AuthN
OIDC
AuthZ
INTEGRATION
layer
Data streaming
Event streaming
Polyglot
microservices
34. Red Hat
A possible architecture
35
API
MANAGEMENT
layerAPI Registry
API Policies API Contracts
API Authorization
Admin Portal
Developer PortalAPI Specs
IDENTITY
MANAGEMENT
layer
Strong
AuthN
Identity
federation
Identity
brokering
OIDC AuthN
OIDC
AuthZ
INTEGRATION
layer
Data streaming
Event streaming
Polyglot
microservices
LEGACY CORE
BANKING
Translation
Transformatio
n
Composition
Accounts Transactions
Payments Products
Orchestration
35. Red Hat
A possible architecture
36
API
MANAGEMENT
layerAPI Registry
API Policies API Contracts
API Authorization
Admin Portal
Developer PortalAPI Specs
IDENTITY
MANAGEMENT
layer
Strong
AuthN
Identity
federation
Identity
brokering
OIDC AuthN
OIDC
AuthZ
INTEGRATION
layer
Data streaming
Event streaming
Polyglot
microservices
LEGACY CORE
BANKING
Translation
Transformatio
n
Composition
Accounts Transactions
Payments Products
PAAS layerMonitoring Logging Networking CI/CD
Orchestration
Networking
36. Red Hat37
API
MANAGEMENT
layerAPI Registry
API Policies API Contracts
API Authorization
Admin Portal
Developer PortalAPI Specs
IDENTITY
MANAGEMENT
layer
Strong
AuthN
Identity
federation
Identity
brokering
OIDC AuthN
OIDC
AuthZ
INTEGRATION
layer
Data streaming
Event streaming
Polyglot
microservices
LEGACY CORE
BANKING
Translation
Transformatio
n
Composition
Accounts Transactions
Payments Products
PAAS layerMonitoring Logging Networking CI/CD
Orchestration
Networking
WAF GLB CDN
TPPs Partners Customers
37. Red Hat
❏ Rate of innovation
❏ Security is key
❏ Best of breed approach
❏ Low barriers of entrance
❏ No lock-in factor
❏ Standards adoption
Open Banking and Open Source
Why they go hand-in-hand
38
38. Red Hat
MNP mandate by European Commission
Prices declined on average 7.9% due to the introduction of MNP
Consumer welfare increased by 2.15 euros per person per quarter
Possible futures
Telco parallelism
39 [ https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2265104 ]
39. Red Hat
The open conflict
40
Traditional Retail Banks
Traditional Lenders
Traditional Asset Managers
Traditional currency exchange
Traditional contracts
Online-Only Banks
Peer-to-Peer Marketplaces
Robo/AI Advisors
Cryptocurrency exchange
Smart contracts
40. Red Hat
Trick or treat
41 [The Everyday Bank report - Accenture]
BUT
ALSO
41. Red Hat
What Banks still stand for:
Trick or treat
42
➢ TRUST
➢ SCALE
➢ MAGIC!
42. Red Hat
Where to
43
Screen scraping FinTech APIs FinTech
PAST PRESENT
[ Manifesto-for-the-impact-of-PSD2-on-the-future-of-European-Fintech ]
Banks trying to
fight against
removal of
screen scraping
43. Red Hat
“Banks aren’t being disrupted by Fintech technology, they are being disrupted by customer
expectations”
- McKinsey
Q&Q
Quotes and Questions
44
“Banking is necessary, banks are not”
- Bill Gates
"We want our money safer than our selfies"
- PayPal