Open Banking is being driven by regulation in Europe, however, it is ultimately about expanding consumer choice in financial services. Open Banking provides opportunities for financial services and FinTech companies as well as consumers. In this webinar, we’ll examine the influence of Open Banking across the globe and the key differences between regulation-led and market-led initiatives. We’ll also explore essential security standards in Open Banking and how they contribute to a secure Open Banking API interface.
The Global Influence of Open Banking, API Security, and an Open Data Perspective
1. The Global Influence of Open Banking, API
Security, and an Open Data Perspective
BILL DOERRFELD AND OLAF VAN GORP
2. 2 | Open Banking akana.com
Presenters
Olaf van Gorp
Senior Product Specialist
Akana
Bill Doerrfeld
Editor in Chief
Nordic APIs Blog
3. 3 | Open Banking akana.com
Agenda
1
2
3
4
5
What is Open Banking (and what is it not)?
Global Developments and case studies
Open Banking and the API mindset
Open Banking and the benefits of API management
Conclusion
4. @DoerrfeldBill
Introduction
● Bill Doerrfeld
● Tech Journalist, API economy
● Following Open Banking since 2015
● Editor in Chief of Nordic APIs
● Twitter: @DoerrfeldBIll
● Portfolio: doerrfeld.io
5. @DoerrfeldBill
An API Community
API Tooling Specialists
API Consumers
Thought Leaders, Bloggers
API Owners, Practitioners
Blog, Digest
Events
6. @DoerrfeldBill
What Is Open Banking?
● Programmable: Read/write bank data
programmatically
● FinTech Ecosystem: Enabling others
access
● Consumer Rights: Democratizing data
● Consumer Convenience: Let banks
specialize on core, allow innovators increase
UX
● EU Origin: Regulation influences, ripples
worldwide
● Regulation: PSD2
7. @DoerrfeldBill
Open Banking is NOT:
● Less Secure: Arguably more secure than
screen scraping
● Less Private: Consumers own data,
Integrations are not opaque
● Damaging for Bank Business: Instead, a
Change. Vertical → Horizontal. Opening
new business channels, services, drive
growth
8. @DoerrfeldBill
The Old, Monolithic Bank
● Siloed: Data is highly inaccessible
● Poor Visibility: PDF downloads :(
● Bad UX: Banks traditionally not tech
companies, difficult transition to mobile.
● No Interoperability: No easy access for
partner integration
● Screen Scraping: Prevalent, and
insecure
● Sluggish: Infrequent updates
9. @DoerrfeldBill
The Open Data Bank
● De-Siloed: Data integrations
● Composable: Microservices
architecture
● Transparent: API-enabled access
● Partner UX: Partners innovate and
increase end UX
● Interoperable: Read and write
capabilities
● Secure: Connections are secured
● Agile: Advanced functionality
12. @DoerrfeldBill
Open Banking Company Benefits
1. Partner Programs: Niche FinTech services
can optimize front-end user interfaces.
2. Integrations: A bank API allows seamless
integration financial-oriented products
3. Stickiness: Increase consumer options and
confidence in service
4. Revenue Model: Banking-as-a-Services can
be productized
13. @DoerrfeldBill
Open Banking Consumer Benefits
1. Own Data: Open Banking is progressive, granting user data rights
2. Visualize: Standardized integrations allow better visibility
3. Flexibility: Mobile, voice, platform agnostic
4. Experience: More-informed, confident users
5. Security: Lost credentials, re-entering logins
15. @DoerrfeldBill
PSD2: More Details
1. EU-based initiative
2. 9 largest: HSBC, Barclays, RBS, Santander, Bank of
Ireland, Allied Irish Bank, Danske Bank, Lloyds and
Nationwide
3. Startups / FinTechs
4. Standards: Debate, but APIs most
obvious choice
5. Tooling: JSON web tokens,
OAuth/OpenID Connect for authentication
16. @DoerrfeldBill
PSD2: An Overview
(Payment Services Directive)
"PSD2 will force banks to allow third parties to access
a given customer’s data, where that third-party is
acting as a data consumer or a delegated authority: The
EU describes these as “third party providers (TPPs)
[who] offer specific payment solutions or services to
customers”
- CHRIS WOOD
Nordic APIs blogger,
Open Banking standards
author in the UK
FROM: How Does Open Banking Apply to US Banks? On the Nordic APIs blog
17. @DoerrfeldBill
Other Open Banking Legislative Bodies
● UK: CMA (Competition
and Markets Authority)
● US: The Senate Banking
Committee discussed in
2018. No regulation yet.
● "the US has a lot of
catching up to do" -
American Banker
18. @DoerrfeldBill
Q: Why Is This Change Happening Now?
Answer #2: Market Pressure
"87% of individuals preferred to adopt a fintech
application rather than use a product or service
offered by a traditional financial services provider."
FROM: https://www.americanbanker.com/opinion/us-way-behind-the-curve-on-open-banking
19. @DoerrfeldBill
Banks Respond to Market Pressure
"Citigroup, BBVA Compass, Bank of America and
Capital One are among the large U.S. banks that have
been making pieces of their internally developed
software code available to outsiders. Other banks are
likely to follow."
- PENNY CROSSMAN,
AMERICAN BANKER
FROM: https://www.americanbanker.com/news/fintech-glasnost-why-us-banks-are-opening-up-apis-to-outsiders
20. @DoerrfeldBill
How Does Open Banking Apply to US
Banks?
"The future of Open Banking in the US market,
therefore, looks more likely to be driven by the
market than regulation. However, there is still an
opportunity to introduce standardization through open
APIs behind the scenes."
- CHRIS WOOD
Nordic APIs blogger,
Open Banking standards
author in the UK
FROM: How Does Open Banking Apply to US Banks? On the Nordic APIs blog
21. @DoerrfeldBill
Case Study: Canadian Imperial
Bank of Commerce (CIBC)
● The API Foundation is used
across the bank
● Container environment with
development network
● Developer training program to
promote internal community
● Self-service API marketplace
available (cost savings of 50–
70% per integration)
FROM: https://nordicapis.com/how-banks-are-becoming-uberized/
22. @DoerrfeldBill
Banks Are Becoming Uberized
“The critical skill here; treat your assets more like
products...[Acting like a tech company is] a shift for
banks to survive.”
- Eyal Sivan, CIBC
24. @DoerrfeldBill
The Amazon Mantra on Externalization
"All service interfaces, without exception, must be
designed from the ground up to be externalizable.
That is to say, the team must plan and design to be
able to expose the interface to developers in the
outside world. No exceptions."
- Jeff Bezos internal
mandate, 2002
25. @DoerrfeldBill
Banks Must Consider:
(Developer Experience)
● DX is UX for developers
● Performance: Is the API usable?
Call successful? Available?
Uptime? Response time?
● Dev Onboarding: Testing,
sandboxing, SDKs, libraries.
● API Monitoring & Testing now
crucial
FROM: https://www.openbanking.org.uk/providers/account-providers/api-performance/
26. @DoerrfeldBill
Future of The Bank
● Banks are now tech companies
● Architecture: composable Microservices
● Banking-as-a-Service
● Agility = Competitive Advantage
● Amazon Model: Future infrastructure must be built to be externalized
○ API-first development
27. @DoerrfeldBill
API Thinking not Doing
When Flavia joined ING, they weren’t just lacking in
API execution, or “API doing”, but they were also
lacking in API understanding, or “API thinking.” This
was making it hard to execute a definite platform
strategy.
Flavia Sequeira, ING Bank
Presented at Nordic APIs
Platform Summit 2017
FROM: https://nordicapis.com/from-api-doing-to-api-thinking-in-a-major-bank/
28. @DoerrfeldBill
Business Benefits From API-First Mindset
● Regulation: Helps to conform to
regulation
● Reusability: Transforms all
infrastructure into reusable
components
● API-as-a-Product: Banking-as-
a-Service can be monetized as a
product
● Partnerships: Enables new
business partnerships to form.
Ex. 300 Signups in 72 Hours,
Nordea Bank.
● Brand Awareness: Can help
spread brand awareness
● Indirect: Open data & open
source breeds innovation
31. 31 | Open Banking akana.com
The Value of APIs
• Decoupling
• Delegation of specific
responsibilities
32. 32 | Open Banking akana.com
Open Banking
Standards
• Service and data model
• Security profile
33. 33 | Open Banking akana.com
Open Banking – Sample Solution Building Blocks
Open
Banking
IAM
(Identity and Access
Management)
APIM
(API Management)
Banking
System
Onboarding
Fraud
Detection
34. 34 | Open Banking akana.com
Overview of Technical Requirements
• Effectively create API interface
(based on Swagger/OAS as part
of OB standard)
• Map the API interface to back-
end resources (banking services)
• Satisfy security requirements
(security profile)
35. 35 | Open Banking akana.com
APIs and API Management
API Management
Gives you control over the API across
its entire lifecycle, from design to
deployment to operational health.
APIs
Expose a business capability to
designated consumers in a secure
and controlled manner.
API Management Solutions
Provide the capabilities to address
and automate your API management
requirements.
36. 36 | Open Banking akana.com
Import Open Banking API Specification
37. 37 | Open Banking akana.com
Connect API Interface to Back-End
This typically calls for effective:
• Orchestration (back-end resources)
• Transformation (data)
• Mediation (security context)
38. 38 | Open Banking akana.com
Implement the Security Profile
Consumer Authentication
and Authorization
Transport Layer Security Content Security
39. 39 | Open Banking akana.com
Security Profile Implementation Summary
Consumer Authentication
and Authorization
OAuth2.0 (and OpenID Connect)
Transport Layer Security
Mutual TLS
Content Security
JSON Web Tokens (JWS/JWE)
40. 40 | Open Banking akana.com
Open Banking Security Summary
Ensure that each request is coming from a trusted source
OAuth
Ensures client authorization
MTLS
Ensures client authenticity
JWT
Ensures message integrity,
confidentiality, and non-repudiation
41. 41 | Open Banking akana.com
API Security Policies
Policies should be:
- configurable
- reusable
- versioned
42. 42 | Open Banking akana.com
Open Banking API Portal
43. 43 | Open Banking akana.com
Benefits of an APIM Solution for Open Banking
• Decouple Open Banking API from back-end systems
• Delegate Open Banking requirements
• In particular: consumer authentication, authorization, message security
• In addition, take care of ‘implicit’ API requirements
• API security, rate limiting, consumer management, API versioning, etc.
• Allow for evolution
• API lifecycle management (maintainability, interoperability, premium APIs,…)
The value of APIs:
Essentially: decoupling (create an interface that corresponds to ‘external demands’: regulatory standards, consumer demands)Different perceived benefits, depending on the approach. For example, regulation -> compliancy -> cost if you fail to comply.
Personally, I find it hard to imagine successful open banking without any regulation. Think of onboarding (criteria, safeguarding data access), accountability (what if things go wrong), etc.
In an opportunistic environment, there may be more dynamics (evolution) than in regulated environment. Hence, adopted implementation should be able to deal with changes effectively.
From a technical perspective (interface implementation perspective), there’s a number of open banking standards that have evolved into a mature specification, which can be taken as a source of inspiration (or adopted as such).
Tendency to look at UK OB across the globe (except Europe, where PSD2-specific standards are currently more preferred).
Distinguish in functional model and security model.
Different vendors will claim to support a broader or wider range of open banking requirements: …
Why an APIM solution is deemed to be an indispensable solution building block:
Stuff that is required by Open Banking and APIM can help with;
Stuff that is required by Open Banking but is out-of-scope for APIM;
Stuff that is not required by Open Banking, but is essential from an API perspective.
In a full Open Banking implementation, different systems are involved. Next to APIM, one also needs IAM, and obviously system responsible for fraud detection as well as the banking system itself come into play,
First, addressing the requirements as specified in the open banking standards
Summary introduction to APIs, API management and API management solutions.
An API Portal should allow for effective API publication based on available specifications (API Swagger documents) as published by OB/PSD2 standards organizations.
Note: the essential aspect here is that by importing the Swagger doc, the API will be represented on the Platform – including automatic deployment. In other words, fast-forward to having the API available (once required policies have been attached).
Ultimately, you need an API Portal in which make your APIs available to developers. DX is increasingly regarded as a differentiator.
Benefits of having an API Portal:
Rapid publication of APIs
Readily available to prospective consumers
Effective search, available documentation, SDK, etc.
APIM supports the evolving API implementation. This means: API lifecycle has to be managed.
Evolution:
Adjust when standards are updated;
Provide different API ‘products’ (flavours) to help ensure interoperability;
Add premium APIs (beyond the Standard)