This documentation is for WSO2 Open Banking version 1.3.0. View documentation for the latest release.
Skip to end of metadata
Go to start of metadata

Open open-banking.xml file in the repository/conf/finance of both WSO2_OB_APIM and WSO2_OB_KM nodes. Configure the open-banking.xml file based on the configurations listed below. 

Do the following configurations in both the wso2-obam and wso2-obkm nodes, and restart the servers.



Define the specification that you plan to deploy.

Possible values: UK, BERLIN, STET

Select a SCA approach from

1. Redirect (OAUTH2 is subsumed by this)
2. Decoupled
3. Embedded


The endpoint to retrieve OIDC Discovery metadata.


You need to get the latest product updates to verify if an account-id sent within the account-consents resource that is sent by TPP, is valid from the bank back-end. This improvement is available as a product update from June 27, 2019 (06-27-2019) onwards.

  • <SharableAccountsRetriveEndpoint>: Configures the endpoint to retrieve sharable accounts that required to list on the consent page.

Sharable accounts - accounts that are accessible online.


In some banks, some PSUs may have a certain number of accounts, but not all accounts have the ability to be shared externally or to make a payment online. In a bank, the sharable account list and the payable account list can either be the same or different.

In the default WSO2 Open Banking solution, at least two APIs are expected to return sharable and payable accounts when passing the user_id, and the given JSON response must be returned. Then it automatically loads the accounts list in the consent page.

The bank's backend endpoint for retrieving the user's accounts returns a response in the following format:

    type: object
        type: string
        example: DE12345678901234567890
        description: IBAN of account
    type: object
        type: string
        type: array
          $ref: '#/definitions/Account'
    description: The response related to the get method of Account

When bank back-end is configured, required parameters can be passed as query parameters to those endpoints. As an example:


The link to the payment initiation resource, which needs to be updated by the PSU identification. This might be used in an embedded, redirect or decoupled SCA Approach, where the PSU ID was missing in the first request.


The link to the payment initiation resource, which needs to be updated by a PSU password and eventually the PSU identification if not delivered yet. This is used in case of the Embedded or Decoupled SCA approach.


This is a link to a resource, where the TPP can select the applicable strong customer authentication methods for the PSU, if there were several available authentication method.


The link to the payment initiation resource, where the "Payment Authorisation Request" is sent to. This is the link to the resource which will authorise the payment by checking the SCA authentication data within the Embedded SCA approach.


The time interval for duplicate checking of payment consent initiation requests using X-Request-ID.

  • No labels