WSO2 Open Banking: TPP On-boarding flow
In this article, I’m going to brief the Third-party provider (TPP) onboarding flow of the WSO2 Open Banking solution. TPP onboarding refers to the process of registering an authorized TPP with a Bank to offer banking services over Open Banking specification.
First let me provide an overview of WSO2 Open Banking is. The WSO2 Open Banking solution is built on top of mature WSO2 API management and identity & access management products that has been in the market for over eight years. The WSO2 Open Banking provides compliance for Open Banking UK 1.1.0, and 2.0.0 (by mid-june) specifications. Support for Berlin and STET specification is on the way. The first customer deployment went to production on last January, and multiple deployments on dev/staging stages awaiting production.
WSO2 Open Banking solution provides a developer portal for TPPs to discover and subscribe to APIs. This is built on top of the API Store portal of the WSO2 API Manager. So, if you have used API-M before, this will feel like a familiar UX. To onboard, interested TPPs has to follow below steps:
How it works
- Fill the registration form
The TPP has to pick a username/password, and provide its company and competent authority (CA) registration details. Finally, TPP should select the open banking roles it is entitled to use. There are three roles:
- Account Servicing Payment Service Provider (ASPSP)
- Account Information Service Provider (AISP)
- Payment Information Service Provider (PISP)
TPP should only select the roles it has been authorized by the CA.
Each registration should be approved by an administrator with ‘admin’ permission via the API-M admin dashboard. This is an optional step if the bank has its own workflow, and does not need to leverage WSO2 built-in workflows. Once approved, the TPP can create an application, and subscribe to APIs for his use. Underneath, this operation creates an OAuth2 application for you which has two-factor inbound authentication enabled by default for Strong Customer Authentication (SCA). It has basic credential validation, and SMS-OTP authenticator as the two factors. There are over 30 different authenticators a bank can choose to use.
2. Await approval from a bank admin
The TPP registration process need to be highly regulated. Therefore, each and every sign-up request need to be approved by a bank admin. The bank admin can use the OB API-M’s admin dashboard for this purpose (/admin). It leverages BPEL workflows feature provided by the WSO2 Enterprise Integrator’s business-process profile.
3. Create an Application, and subscribe to APIs
If the TPP is approved, it can go ahead and create an virtual application to represent its application. User just need to provide a name and the application-level throttling it prefers. TPP can subscribe to the APIs it is entitled to using this application.
4. Provide the TPPs public X.509 certificate to bank
For JWT based client assertion, the bank need to have the TPPs public certificate in its trust store. This is a mandatory step for Open Banking UK 2.0.0 specification. Currently, this is an offline process. TPP need to provide the public certificate bank portal admins over email or any other mechanism.
5. Generate OAuth2 access keys
The outcome of this entire process for the TPP is an OAuth2 clientId and a clientSecret.
The clientId and clientSecret are TPPs access credentials. It can use these to generate an application token, and then create account requests and payment requests.
In a later article, I’ll discuss how a TPP can use its OAuth2 access credentials to generate an application token, and use that to create account requests and payment requests.
If you have questions or clarifications, drop a comment below. I’d also like to know what topics you would like to cover in follow-up articles.
