This document summarizes trends in banking APIs. It discusses how standards like Open Banking UK define API access authorization, typically using OAuth 2.0. Open Banking UK specifies the client credentials grant type and OIDC hybrid flow for account information and payment initiation APIs. It involves the TPP obtaining an identifier from the ASPSP, including it in a request object for authorization. Other standards like NextGenPSD2 and PolishAPI also utilize decoupled or OAuth-based authorization flows. Mutual TLS authentication between TPPs and ASPSPs is common across specifications.

1. Financial APIs Workshop - Japan/UK Open Banking and APIs Summit 2018
Trends in Banking APIs
Tatsuo Kudo

2. Preface
• A couple of standardization efforts on banking APIs are
emerging around the world, especially in Europe. This
presentation summarizes how such standards define API
access authorization and gives insights on future
directions.
2

3. About me
• Tatsuo Kudo https://www.linkedin.com/in/tatsuokudo
– Sun Microsystems (1998-2008)
– Nomura Research Institute (2008-2018)
– OpenID Foundation Japan (2013-2014)
– NRI SecureTechnologies (2014-2018)
– Authlete (2018-)
• VP of Solution Strategy
3

4. What are ”Banking APIs?”
• They vary, such as:
– Providing “Open Data” (e.g.
branch location)
– White-labeled banking services
(e.g. “Bank as a Service”)
– Providing bank accounts’
information and accepting
transaction requests based on
end-user consent
371 APIs are listed in Banking category
Source: https://www.programmableweb.com/category/banking
4

5. Leveraging “OAuth 2.0” in Banking APIs
• The framework is often
utilized to enable API
access authorization
with customer’s
consent
5
Actors in “OAuth 2.0” and a typical authorization flow
Source: https://www.slideshare.net/tkudo/api-meetup-oauth

6. Who Defines Banking APIs
• Bank defines its own spec
• Industry groups and consortia
define common spec
• (Vendor defines its proprietary
spec)
6
• Open Banking UK
• Berlin Group
NextGenPSD2
• Polish Bank Association
• Slovak Banking
Association
• (France Stet)

7. Open Banking UK
• FAPI Part 2
• Client Credentials Grant Type (OAuth 2.0) / OIDC Hybrid
Flow
• Request Object
• Mutual TLS
7
Source: Open Banking Security Profile - Implementer's Draft v1.1.2
https://openbanking.atlassian.net/wiki/spaces/DZ/pages/83919096/Open+Banking+Security+Profile+-+Implementer+s+Draft+v1.1.2

8. Open Banking UK
Account Information
1. PSU (Payment Service User) allows AISP (Account
Information Service Provider) to make a request
2. AISP sends the request to ASPSP (Account Servicing
Payment Service Provider) using POST /account-resource
(Mutual TLS, Client Credentials Grant Type)
3. ASPSP provides PISP with “AccountRequestId”
4. AISP creates a Request Object that contains
AccountRequestId and send it to ASPSP as authorization
request (OIDC Hybrid Flow)
5. ASPSP authenticates PSU
6. ASPSP provides AISP with authorization code
7. AISP sends the code to ASPSP to obtain access token
(Mutual TLS)
8. AISP sends a request using GET /accounts with the
access token (Mutual TLS)
8
Source: Account and Transaction API - v2.0.0
https://openbanking.atlassian.net/wiki/spaces/DZ/pages/127009546/Account+and+
Transaction+API+Specification+-+v2.0.0

9. Open Banking UK
Payment Initiation
1. PSU allows PISP (Payment Initiation Service Provider) to
make a payment initiation request
2. PISP sends the request to ASPSP using POST /payments
(Mutual TLS, Client Credentials Grant Type)
3. ASPSP provides PISP with ”PaymentId”
4. PISP creates a Request Object that contains PaymentId and
send it to ASPSP as authorization request (OIDC Hybrid
Flow)
5. ASPSP authenticates PSU
6. ASPSP provides PISP with authorization code
7. PISP sends the code to ASPSP to obtain access token
(Mutual TLS)
8. PISP sends a request using POST /payment-submissions
with the access token (Mutual TLS)
9. PISP optionally retrieves the status of a payment setup or
submission
9
Source: Payment Initiation API - v1.1.0
https://openbanking.atlassian.net/wiki/spaces/DZ/pages/5786479/Payment+Initiation+API+Specification+-+v1.1.0

10. Other Payment Initiation with OIDC Hybrid Flow Example
• Slovak Banking API Standard
– Like OB UK, PISP obtains identifier of payment (orderId) from ASPSP, puts it in Request Object and
invokes authorization request
10
Source: Slovak Banking API Standard Version 1.1 http://www.sbaonline.sk/files/subory/projekty/sbas/sbas_ver1.1-final.pdf

11. Other Payment Initiation with OIDC Hybrid Flow Example
• MKB in Hungary
– Utilizes Open Banking UK
Security Profile
– Like OB UK, PISP obtains
identifier of payment
(openbanking_intent_id) from
ASPSP, puts it in Request
Object and invokes
authorization request
11
Source: Account and Transaction API Specification
https://portal.sandbox.mkb.hu/api-documentation/account-info

12. Berlin Group “NextGenPSD2”
• The spec defines four authn/authz flows in general
– Redirect SCA Approach
– OAuth2 SCA Approach
– Decoupled SCA Approach
– Embedded SCA Approach
12

13. Berlin Group “NextGenPSD2”
Redirect / OAuth2 SCA Approach
• PSU is redirected to
ASPSP to confirm
consent
• “OAuth2” is a variant of
Redirect
– Redirection location is
dynamically determined
with Authorization Server
Metadata
13
Source: NextGenPSD2 XS2A Framework Implementation Guidelines Version 1.1
https://docs.wixstatic.com/ugd/c2914b_5351b289bf844c6881e46ee3561d95bb.pdf

14. Berlin Group “NextGenPSD2”
Decoupled SCA Approach
• ASPSP confirms
consent from PSU
through a path
bypassing PISP/AISP
14
Source: NextGenPSD2 XS2A Framework Implementation Guidelines Version 1.1
https://docs.wixstatic.com/ugd/c2914b_5351b289bf844c6881e46ee3561d95bb.pdf

15. Berlin Group “NextGenPSD2”
Embedded SCA Approach
• ASPSP confirms consent
from PSU through
PISP/AISP
15
Source: NextGenPSD2 XS2A Framework Implementation Guidelines Version 1.1
https://docs.wixstatic.com/ugd/c2914b_5351b289bf844c6881e46ee3561d95bb.pdf

16. Berlin Group “NextGenPSD2”
Relation with OAuth 2.0
• The framework is positioned as “Optional Usage”
• PISP/AISP eventually obtains access token from ASPSP
as a result of “pre-step” and/or doing OAuth SCA
Approach, and calls API (XS2A interface) with the token
16

17. Other Decoupled Authentication Example
• Poland “PolishAPI”
• Different approach from
NextGenPSD2
– Utilizes OAuth 2.0
Authorization Code grant
– TPP (Third-Party Provider)
sends output from EAT
(External Authorization
Tool) to ASPSP
17
Source: PolishAPI Verison 2.0
https://docs.polishapi.org/files/ver2.0/PolishAPI-spec-v2.0-EN.pdf

18. Other Decoupled Authentication Example
• France “STET”
• Resource Owner
Password Grant
– AISP/PISP asks PSU to
provide result of Strong
Customer Authentication
done by ASPSP, and
send it to the ASPSP as
“Password”
18
Source: PolishAPI Verison 2.0
https://www.stet.eu/assets/files/PSD2/1_3/API_DSP2_STET_V1_3.pdf

19. Conclusion
• A flow of “intent” – TPP sends an intent to ASPSP using POST,
crafts Request Object that contains identifier of the intent and
makes an authorization request – is becoming a common
practice. It is not only Open Banking UK but also other
standardization initiatives
• Mutual TLS authentication between TPP and ASPSP is a
must
• “Embedded” vs “Decoupled”
19

20. Thanks!