The document discusses the importance of banks developing application programming interfaces (APIs) to improve customer experience, gain competitive advantages over non-bank competitors, and keep up with changing customer behaviors and aging IT systems. It introduces the Open Bank Project, an open source API and app store that offers a standardized API solution for banks along with complementary services like connectors to core banking systems. The Open Bank Project aims to help banks launch API platforms and build developer communities around open banking.

1. Simon Redfern
Bank as a
Platform

2. Our Vision
1995!
Why do we need a Web
site?!
2000! 2010! 2020!
Of course we have a
Web site!
Of course we have an
API!
Why do we need an
API?!
In the future, every bank will have an API
• Banks gain faster time-to-market and save money!
• Developers have easy data access!
• Customers enjoy improved experience!
“By 2016, 75% of the top 50 global banks will have launched an API
platform and 25% will have launched a customer-facing app store”!

3. Why is it important
Banks can leverage the OBP API to create better customer relationships!
Source: faberNovel, 6 reasons why API are reshaping our business
An API reduces the time, complexity and cost of deploying banking apps!

4. Why now
Current “workarounds” do not work anymore!
Non-Banking
Competitors!
¾ millennials would be more excited about an offering
from new entrants than from their own bank!
Changing!
Customer Behavior!
71% of millennials would rather go to the dentists than
listen to what banks are saying!
Ageing IT systems!
IT systems are perceived as!
the #1 barrier to innovation!
Upcoming Regulation!
See UK Treasury Open Banking Call for evidence, EU’s
PSD-II, Poland’s KNF anti-screen-scrapping decision.!
Source: The Millennial Disruption Index, Scratch 2014 / Innovation in Retail Banking 2013, Efma-Infosys!

5. The Open Bank Project
1/ Open
Standard!
2/ API Platform!
3/ Developer
Community
Banks can leverage the OBP API to create better customer relationshipsBanks can leverage the OBP API to create better customer relationships
The Open Bank Project is an open
source API and App Store for banks
and a developer community around.!

6. Overview
We offer a white-labeled API solution for banks and complementary services!
OBP Connectors!
OBP API!
Core Banking Systems!
Bank’s
Customers
Trusted!
developers
The Bank
Mobile and web applications
South side!
Adapters!
Public Facing
APIs!

7. Past Participants
Past Participants
App example - Underdraft
API Catalogue
A catalogue of 120+ API Definitions available!

8. Architecture
• RESTful banking model
• Functional
• Scala in JVM
• OAuth included
• Flexible Connectors
• AGPL & Commercial (on
github)

9. Past Participants
Past Participants
App example - Underdraft
Developer Community
5500+ FinTechs use the Open Bank Project API !

10. What makes a good API?
• RESTful
• JSON
• Good documentation / API Explorer
• Examples / SDKs with at least GET, POST
• Pragmatic Auth options
• Developer Experience (few surprises)
• Support (what can it do, where and how?)
• Reliability (SLA)
• Good error messages
• Management and Metrics
• Sandbox mode

11. What makes a bad API?
• SOAPY (actions not resources, GET a MakePayment)
• Not respecting HTTP (e.g. 400 vs 500)
• Abrvted Nms
• InconsistentNaming_Conventions
• Inconsistent URL design (devs have to think)
• Unreliable performance (worse than online banking)
• Non specific error messages
• Overuse of headers
• Poor developer terms and conditions
• ....No one using it.

12. RESTful
• HTTP(s)
• An approach to API design
• Resources to GET / POST / PUT / PATCH / DELETE
• Not quite CRUD
• Supported by many clients, servers (the internet)
• If consistent, developers can make assumptions about endpoints
• Test in browser
• Versioning in URL
• Sort params in URL
• Test in REST client
• Direct Auth options

13. JSON
Strings, numbers, true, false, null, objects and arrays:
{
"id": 1,
"name": "REST in Practice: Hypermedia and Systems Architecture",
"price": {
"currency": "USD",
"amount": 12.50
},
"good_book": true,
"publisher": "O'Reilly",
"authors": ["Ian Robinson", "Jim Webber", "Savas Parastatidis"],
"available_since": "2010-09-15T17:14:55Z",
"comment": null
}
http://jsonlint.com/ to validate

14. Documentation
Swagger, RAML,
API Blueprint,
ResourceDoc
Twitter
Facebook
Stripe
OBP

15. API Explorer

16. Developer Tools - SDKs
Apache Licensed
(Handle the OAuth flow)
https://github.com/OpenBankProject/OBP-API/wiki/OAuth-Client-SDKS!

17. OBP Entitlements Manager
Explore API
in context of
the logged in
user.
https://danskebank-manager.openbankproject.com/

18. The Open Bank ProjectWhy an API “sandbox”?
• RESTful
• JSON
• Few surprises
• Good documentation
• Examples / SDKs
• REST client friendly Authentication Options
• API Explorer
• Consistensy
• Developers want:
• Meaningful data (not gobbledygook)
• Meaningful results (e.g. accounts, transactions etc. should persist)
• Portability (write once)
• Pragmatic authentication + authorisation (get on with App)
• Banks want:
• Separation from core banking system (Cloud installed)
• Compliance (no issues with data, terms of use)
• Range of Apps (groups of APIs: Accounts, Onboarding, Payments…)
• Branded Demos to show and tell (relationships with startups)

19. Sandbox!

20. Sandbox Equipment!
• Python 3
• Requests
• PIP
• Virtual Env
• Github Client
• Notepad ++
• Postman REST client
• OBP API Explorer
• OBP Sofi

21. What’s a Hackathon?
A hackathon is an intensive marathon of brainstorming and
programming that rapidly engages the creativity of
designers, developers and innovators.

22. What about PSD2?
Deadline: September 2018!
The Second Payment Services Directive is a new EU regulation that forces
banks to open up their transaction and payment infrastructure to third
party providers!

23. PSD2 RTS Compliance
• Article 1: Strong customer authentication - with exemptions (level of risk,
amount, counterparty, frequency of payment, channel, when did they last strong
auth? Etc.)
• Article 2: Monitoring and alerts - for fraudulent payments / Transaction
Requests. Consider previous user behavior, transaction history, location of payer
and payee, known compromised secure elements and current attacks.
• Article 3: Review of security measures – must be documented, periodically
tested, evaluated and audited by internal or external independent and qualified
auditors.
• Article 4: AuthCode - Non reversible, One time use. Temp user lockout. Inform
user. Max 5 attempts. Max Timeout 5 mins.
• Article 5: Dynamic linking – Inform the payer of amount and payee, Auth Code
must be bound to original Transaction Request. Assure confidentiality, authenticity
and integrity of amount, payee in all phases of authentication, AuthCode generation
and info displayed to user.
• Article 6: Requirements of “knowledge” – Don’t disclose user secrets
• …. Article 33: Entry into force!

24. Past Participants
Past Participants
App example - Underdraft
API Catalogue
Designed with Developers & Bank feedback in mind!
PSD2 !
Catalogue!

25. Security
• Software deployed on-premise behind bank’s firewall!
• Built-in OAuth 1.0a Server. Direct Login (JWT) & OpenID
Connect (experimental) + External OAuth2!
• Powerful entitlement & views system!
• Banks grants access to production data & APIs!
• OBP storage can be separated from the API layer!
• Common security attacks addressed using Scala, secure &
scalable language!

26. Deployment Scenario

27. Commercial License
• Commercial license:
• Freedom to fork, privately modify and merge AGPL code
• Commercial Bank support
• Commercial Developer support
• Commercial Core Banking System adapters
• Prioritized development
• Developer and Fintech community building
• Internal and external evangelization
• Customised sandbox data

28. Simon Redfern, CEO
simon@tesobe.com!
+49 (0)30 8145 3994!
www.openbankproject.com
www.github.com/OpenBankProject
Bank as a
Platform