OBP at the heart of your PSD2 strategy

Transcription

1 OBP at the heart of your PSD2 strategy API Days Nov 2017 Simon Redfern

2 Open Banking Open APIs for every bank.! Open Standards! Open Source! Open Data! Open Innovation! Why do we need a Web site?! Of course we have a Web site! Why do we need an API?! Of course we have an API! 1995! 2000! 2010! 2020! Banks gain faster time-to-market and save money! Developers have easy data access! Customers enjoy improved experience! In the future, every bank will have an API

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

4 Why now? Changing! Customer Behavior! 71% of millennials would rather go to the dentists than listen to what banks are saying! Non-Banking Competitors! ¾ millennials would be more excited about an offering from new entrants than from their own bank! Ageing IT systems! IT systems are perceived as! the #1 barrier to innovation! Upcoming Regulation! EU PSD2, UK Open Banking, Australia..! Current workarounds do not work anymore! Source: The Millennial Disruption Index, Scratch 2014 / Innovation in Retail Banking 2013, Efma-Infosys!

5 PSD2 33 Articles regulating Third-party access to Transaction History Payments In the context of: Strong customer authentication Exemptions to strong customer authentication Security measures Monitoring Compliance and reporting on the above

6 PSD2 - Dynamic Strong Auth Article 1 requires strong authentication in certain contexts but also exemptions depending on level of risk, amount, counterparty, frequency of payment, channel, time since the user performed strong authentication etc.. OBP provides base authentication (OAuth or Gateway Login) and Security Challenges (e.g. SMS TAN) which are required to complete certain transactions. OBP messages such as getchallengethreshold and validatechallengeanswer communicate with CBS to provide dynamic strong auth inside the OBP APIs.

7 PSD2 - Monitoring + Alerts Article 2 covers monitoring and alerts in response to fraudulent payments payments considering previous user behavior, transaction history, location of payer and payee, known compromised secure elements and current attacks. OBP provides numerous sources for this: RESTful resources include: Transaction Requests, Transaction + Counterparty Geolocation Metadata, KYC info. In flight messages that can be monitored using open source tools include: createtransactionrequest, createsecuritychallenge

8 PSD2 Security Testing Article 3 covers review of security measures which must be documented, periodically tested, evaluated and audited by internal or external independent and qualified auditors. OBP provides: OBP API Tester Unit Tests API Explorer for manual validation API Manager for Role checking Reference Apps for manual validation Jenkins integration for test automation.

9 PSD2 Authcode Article 4 covers AuthCode, a non-reversible, one time use code that is locked to a specific payment (Transaction Request) or other operation that should be submitted correctly by the user for the operation to proceed. OBP provides functions that call / implement this functionality including: getauthcode, storeauthcodechallenge, sendauthcode - and endpoints e.g. answer transaction request challenge that use checkauthcode

10 PSD2 Dynamic Linking Article 5 covers Dynamic linking Inform the payer of the amount and the payee. The Auth Code must be bound to the original Transaction Request. Assure the confidentiality, authenticity and integrity of the amount and payee during all phases of authentication, the AuthCode generation and when information is displayed to user. OBP Transaction Requests and challenge endpoints contain counterparty and amount information that allows the calling App to present this information to the user. The AuthCode is a digest of the originally submitted Transaction Request.

11 PSD2 Elements Articles cover Requirements of elements categorised as knowledge, possession (hardware) and inherence (biometrics) and their independence. OAuth keeps user credentials separate from the resource endpoints. Any authentication scheme (biometric, password, SMS TAN) can be used on the user login page and OBP step up security challenge flows.

12 PSD2 Restricted data Articles 10 requires that strong customer authentication not be required a second time where a payment service user is limited to accessing either or both of the following items online without disclosure of sensitive payment data: (a) the balance of one or more designated payment accounts; (b) the payment transactions executed in the last 90 days. OBP provides account views which provide fine grained access to account and transaction data over unified endpoints.

13 PSD2 Point of Sale Article 11 covers contactless point of sale. OBP supports multiple authentication methods, transaction request types and security challenges to support a variety of payment initiation contexts.

14 PSD2 Transport + Parking Article 12 specifies that transport and parking fares should not incur payment charges. OBP transaction charges are are configurable by Transaction Request Type Transaction Request Type = TRANSPORT or PARKING would have a charge of 0.

15 PSD2 Trusted beneficiaries and recurring transactions Article 13 regulates that trusted beneficiaries and recurring transactions are not subject to strong auth. OBP Transaction Request Type = COUNTERPARTY requires payment to an account previously specified by the customer (Counterparty is_beneficiary=true). The return value of challengelevel controls if step-up authorisation is activated for repeated based on regular counterparty and amounts.

16 PSD2 Payments to Self Article 14 regulates that Payments to own accounts be treated separately. OBP Views include the permission can_create_transaction_request_to_own account. The owner of an account has access to this permission which allows payments to own accounts by a different Transaction Request Type

17 PSD2 Low value payments Article 15 regulates that low value payments are not subject to strong auth. The OBP function getchallengelevel accepts a number of parameters that allow back end systems to respond with a dynamic currency and amount level - depending on various real-time risk factors and constant elements - at which step up authentication will be triggered. If the payment amount is below the threshold the Transaction Request will cause OBP to directly request a Transaction in the payment system / CBS.

18 PSD2 Trans Risk Analysis Article 16 Transaction risk analysis. Payments exempted from strong customer authentication where transaction monitoring shows low risk. OBP provides a number of REST API endpoints and other interfaces that risk engines can use to query core banking and related metadata. Some relevant data points include: Payer location (Lat, Long of Transaction) Payee location (Lat, Long of Counterparty) History of Transaction Locations (Lat, Longs of Transactions) History of Counterparty Locations (Lat, Longs of Counterparties) History of Transaction amounts, dates, counterparties and tags available via a high performance search interface.

19 PSD2 Monitoring Article 17 Monitoring - Payment service providers that make use of the exemptions need to make the following available: Average transaction value under strong auth Average transaction value under exemption Number of transactions under exemption. Percentage of exemptions compared to total number. OBP endpoints for the regulators will be available under at /obp/v3.0.0/reporting/transaction-statistics This endpoint will require the Role: CanGetTransactionStatistics

20 PSD2 Excessive Fraud Rates Article 18 covers invalidation and optionality of exemptions. PSPs must immediately report excessive fraud rates to the regulators. OBP will provide endpoints for the regulators to query fraud rates e.g. /obp/v3.0.0/reporting/fraud-rates/ TRANSACTION_REQUEST_TYPE The OBP PSD2 App (WIP) and automated processes (cron job) will consume these endpoints and send s to the regulator if numbers exceed a threshold.

21 PSD2 Credentials Article 19 and 20 - cover the creation, confidentiality and integrity of the personalised security credentials OBP uses end-to-end encryption for: REST interfaces (https) OAuth1.0a encrypts credentials in addition to transport TLS. Akka communication to Storage Servers to RDBMS Connector communication with Kafka message queues Adapter communication with core banking systems OBP data is stored in a three tiered architecture and the RDBMS is protected by type safe storage APIs. Database file system is encrypted with private keys stored in Hardware Security Module (HSM) OBP is OWASP safe. Passwords are not echoed to the user. Strong passwords are enforced. Users are locked out following successive failed password attempts.

22 PSD2 Report For the remaining PSD2 articles - and more details on the above, please request our PSD2 report from contact@tesobe.com

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

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

25 App API example Catalogue - Underdraft Past Participants Past Participants A catalogue of 130+ API Definitions available!

26 App Developer example - Community Underdraft Past Participants Past Participants FinTechs use the Open Bank Project API!

27 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

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

29 Developer Portal

30 Explore API + Swagger + ResourceDoc

31 Manage API Explore API in context of the logged in user.

32 Fine grained Access (Views)

33 Metadata

34 Developer Tools - SDKs Apache Licensed (Handle the OAuth flow)

35 Customer Logins

36 Deployment options Developers, Partners & Bank IT can easily run OBP on laptop or cloud - from source code or Docker. Images are now regularly updated!

37 OBP API

38 OBP API

39 Auth OAuth 1.0a OAuth2 + OpenID Connect (Ext.) Direct Login Gateway Login

40 Docs Swagger ResourceDoc API Explorer

41 Bank as a Platform Simon Redfern, simon@tesobe.com