Page Comparison

...

Navigate to the API Store at https://<WSO2_OB_APIM_HOST>:9443/store.

Select Sign-up on the top left corner of the homepage.

Image Removed

Provide the requested details on the signup page.

a. Generic details:

b. Company details:

c. Competent authority registration details:

Read terms and conditions. Click the checkbox to agree to the terms and conditions.

Image Removed

Click Sign Up. A request to approve the DR sign up is now sent to the Approver users.

Image Removed

Step 2 - Approve the DR

Now that you have signed up as a DR, an admin who overlooks all DR sign-up forms must approve it.

Tip

title	Before you begin:

You need to deploy the following APIS.

Consumer Data Standards API in <WSO2_OB_APIM_HOME>/repository/resources/finance/apis/consumerdatastandards.org.au/1.0.0/consumer-data-standards.yaml

file

file. See

Configuring

Deploying APIs

for AUYou can use the CDR Dynamic

, for instruction on how to deploy this API.

Warning

Consumer Data Standards Dynamic Client Registration API v0.1

API

to register

a

an Accredited Data Recipient (

DR

ADR) application.

See Deploying

See Dynamic Client Registration API v0.1

, and continue from the Authorizing account consents step if you are using the CDR Dynamic Client Registration API v0.1 API.

For evaluation purposes, you may manually register the DR application and invoke the Consumer Data Rights APINby following follow all the steps given below.

Table of Content Zone

maxLevel	3
location	top

Step 1 - Sign up as a Data Recipient

In this step, the Data Recipient (DR) registers its application in WSO2 API store.

Expand

title	Click here to see how it is done...

Expand

title	Click here for more information..

Field

Description

Username/Email

The username/email that the DR uses to sign in to the API Store.

Password

The password that the DR uses to sign in to the API Store.

Retype Password

This is to prevent the DR from accidentally setting an incorrect password.

Last Name

This is the last name of the DR.

First Name

This is the first name of the DR.

Field

Description

Legal Entity Name

The official name of the DR.

Country of Registration

The country in which the DR is registered.

Legal Identifier Number (LEI)

This identifies the DR.

Company Register

The organization that registered the DR.

Company Registration Number

Identifier issued at the DR registration.

Address Line 1

Address of the DR.

Address Line 2

Address of the DR.

City

City in which the DR is located.

Postal Code

Postal code of the geographical location of the DR.

Country

The country in which the DR is located.

Field

Description

Competent Authority

The regulatory body that authorises and supervises the open banking services delivered by the DR.

Competent Authority Country

Country of the competent authority that authorised the DR to provide open banking services.

Competent Authority Registration Number

The registration number issued by the Competent Authority to the DR.

URL of the Competent Authority Register Page

URL of the page that has the list of organizations authorised by the competent authority.

Note
It is not mandatory to include the approval step for approving the DR. In order to add this step, you need to configure workflows in the WSO2 Open Banking solution.

Expand

title	Click here to see how it is done...

Sign in to the WSO2 Open Banking API Manager Admin portal as an Approver at https://<WSO2_OB_APIM_HOST>:9443/admin.
Locate the approval request and click Assign To Me.
Image Removed
Click Start to start the approval process.
Image Removed
Select Approve then Complete.
Image Removed

Now the DR can sign in to the API store.

Step 3 - Sign in to the API store as the DR

Users can sign in to the API store and proceed with the steps mentioned below.

Expand

title	Click here to see how it is done...

Sign in to the API Store as the DR at https://<WSO2_OB_APIM_HOST>:9443/store.
Click Sign In and navigate to the Sign In page.
Enter the username and the password you entered when signing up as a DR.
Click Sign In.

The homepage of the API store is now displayed along with the APIs.

Step 4 - Create an application

The DR with an application needs to create an application using WSO2 API store. The application created via WSO2 API store allows to observe statistics of APIs, subscribe to APIs, and access the subscribed APIs.

Expand

title	Click here to see how it is done...

Go to the Applications tab in the API Store.

Image Removed

Click Add Application.

Image Removed

Enter application details.

Image Removed

Field

Description

Name

Application name.

Per Token Quota

Determines the maximum number of API requests accepted within a given duration.

Description

This describes the purpose of the application.

Click Add.

Note
An application can be used to subscribe to multiple APIs. See Subscribe to an API for instructions.

Step 5 - Subscribe to API

The DR user needs to subscribe to the ConsumerDataStandards v1 API in order to access its API resources. Once subscribed, the users can access all the supported services of the API resources.

Expand

title	Click here to see how it is done...

Go to the APIs tab in the API Store.

Image Removed

Select the ConsumerDataStandards v1 API.
Image Removed

Select the application you created in the Create an application section.

Image Removed

Set the Tiers to Unlimited.

Click Subscribe.

Now that you have subscribed to the API, generate access tokens and invoke the API.

Step 6 - Create certificates

The DR user needs to create certificates to validate whether the DR is registered in a governing entity.

Expand

title	Click here to see how it is done...

A keystore file is used to store the trusted certificates of the DR in the WSO2 Open Banking solution. Use the commands given below in a command-line interface in order to create a keystore file as a DR.

Make sure to update the following placeholders:

<alias>A preferred alias for the keystore file.<filename>A preferred name for the keystore file.

Code Block
keytool -genkey -alias <alias> -keyalg RSA -keystore <filename>.jks

During the command execution, the DR user requires to;

AnchorsourcekeystorePSsourcekeystorePSSet a password for the keystore.

Provide information, acquired when registering with a governing entity.

Set a password for user-defined alias (<alias>).

Convert the keystore from the .jks format to .PKCS12. Make sure to update the following placeholders:

<keyStoreName>This is the name of the <filename>, given above.<PKCS12FileName>This is the name of the keystore in the .PKCS12 format.

Code Block
keytool -importkeystore -srckeystore <keystoreStoreName>.jks -destkeystore <PKCS12FileName>.p12 -deststoretype PKCS12

During the command execution, the DR user requires to;

Set a password for the destination keystore.
Enter the source keystore password, as defined in the above step .

Create the application certificate (.pem) file in the PKCS12 format using the keystore. e.g: dr.p12.

Make sure to update the following placeholders:

<PKCS12FileName>This is the name of the keystore in the PKCS12 format, as mentioned above for the <PKCS12FileName>.<PEMFileName>This is the name of the application certificate that is created in the .pem format.

Code Block
openssl pkcs12 -in <PKCS12FileName>.p12 -nokeys -out <PEMFileName>.pem

During the command execution, the DR user requires to;

Set a password to import the .pem file.

Import the public key you extracted in the previous step to the truststore file.

Update the placeholder values and use the given command.

<alias>The alias for the keystore file.<PEMFileName>The name of the application certificate that is created in the .pem format.<truststoreFileName>The name of the truststore file that you want to import the public key.<password>The keystore password of the truststore file.

Code Block
keytool -import -alias <alias> -file <PEMFileName>.pem -keystore <truststoreFileName>.jks -storepass <password>

Step 7 - Generate keys

The DR user requires a Client ID (Consumer Key) and a Client secret (Consumer Secret) to access the subscribed APIs.

Expand

title	Click here to see how it is done...

Sign in to the API store as a DR user and go to the Applications tab.

Image Removed

Choose your application from the Application List and select either of the following:

Production Keys: Generates access tokens in the production environment.
Sandbox Keys: Generates access tokens in the sandbox environment.

Provide the requested information as defined below:

Field

Description

Grant Types

These determine the credentials that are used to generate the access token.

Refresh Token: This is to renew an expired access token.
Client Credential: This relates to the client credentials grant type and is applicable when consuming the API as an application.
Code: This relates to the authorisation code grant type and is applicable when consuming the API as a user.

Callback URL

This is the URL used by the DR to receive the authorisation code sent from the Data Holder (bank). The authorisation code can be used later to generate an OAuth2 access token.

Application Certificate

This is the content between the BEGIN CERTIFICATE and END CERTIFICATE strings of the application certificate (.pem) that you created above.

Click Request Access if you are generating production keys. If workflows are configured in the solution, it sends a request to Approver user to approve the token generation. Otherwise, it generates consumer key and consumer secret.

Click Generate Keys if you are generating sandbox keys. It generates consumer key and consumer secret.

Step 8 - Approve Production Key generation

This step includes instructions to an Approver user to review and approve a request to generate production keys for an application.

Note
It is not mandatory to include the approval step for the Production Key generation. In order to add this step, you need to configure workflows in the WSO2 Open Banking solution.

Expand

title	Click here to see how it is done...

Sign in to the WSO2 Open Banking API Manager Admin portal as an Approver at https://<WSO2_OB_APIM_HOST>:9443/admin.

Click Tasks and then Application Registration.

Locate the approval request and click Assign To Me.

Click Start to start the approval process.

Image Removed

Select Approve and then click Complete.

Image Removed

Navigate back to the API Store and click Applications.

Image Removed

On the Applications tab in the API Store, click View of the application that you created.

Image Removed Select the Production Keys or Sandbox Keys tab to find the generated keys.
The consumer key and consumer secret are displayed as follows:

Image RemovedStep 9 - Authorizing

.

Table of Content Zone

maxLevel	3
location	top

Step 1 - Authorising account consents

The bank redirects the bank customer to authenticate and approve/deny application-provided consents.

Expand

title	Click here to see how it is done

Generate the request object by signing the following JSON payload using the supported algorithms.

Note

To configure the supporting algorithms:

Open the <WSO2_OB_APIM_HOME>/repository/conf/finance/open-banking.xml file.

Update the following configurations with the algorithm:

Code Block

language	xml

<UK>
	<!-- The following configuration specifies the signature algorithms allowed in the DR requests.
        The JWTs signed in algorithms that are not in the following list, will be rejected. If the configuration
        is not present, no validation will occur and any algorithm will be passed through.
        Allowed values are:
            1. PS256
            2. RS256
        -->
	<AllowedInboundSignatureAlgorithms>
		<Algorithm>PS256</Algorithm>
	</AllowedInboundSignatureAlgorithms>
</UK>

Tip
The `scope` claim is required to access the data available via an endpoint. See Consumer Data Standards Australia - Authorisation Scopes, for more information on Authorisation scopes.

Note
The refresh token is used to regenerate an access token. The `sharing_duration` claim in the request object defines the validity period of the refresh token. This is to limit the validity of the consent to the defined period.

Localtabgroup

Localtab

title	Request object format

Code Block

## Decoded request JWT format
{
  "kid": "<Certificate fingerprint>",
  "typ": "JWT",
  "alg": "<Supported algorithm>"
}
{
  "iss": "<Application ID>",
  "aud": "<Audience the ID Token is intended for. For example,https://<WSO2_OB_APIM_HOST>:8243/token>",
  "response_type": "<code:Retrieves authorize code, code id_token: Retrieves authorize token and ID token>",
  "exp": <A JSON number representing the number of seconds from 1970-01-01T00:00:00Z to the UTC expiry time>,
  "client_id": "<Application ID>",
  "redirect_uri": "<Redirect URL of the client application>",
  "scope": "<Available scopes are bank:accounts.basic:read, bank:accounts.detail:read, bank:transactions:read, bank:payees:read, bank:regular_payments:read, common:customer.basic:read, and common:customer.detail:read >",
  "state": "af0ifjsldkj",
  "nonce": "<Prevents replay attacks>",
  "claims": {
    "sharing_duration": "<Requested duration for sharing, in seconds>",
    "id_token": {
      "acr": {
        "values": ["urn:cds.au:cdr:3"]
      }
    }
  }
}
<signature>

Localtab

title	Request object sample

Code Block

eyJhbGciOiJQUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6IjEyMyJ9.eyJhdWQiOiJodHRwczovL2xvY2FsaG9zdDo4MjQzL3Rva2VuIiwicmVzcG9uc2VfdHlwZSI6ImNvZGUgaWRfdG9rZW4iLCJjbGllbnRfaWQiOiJyVnB3dVlFNzJ2WlAyOHVjVGUzdlA3Y0gwemthIiwicmVkaXJlY3RfdXJpIjoiaHR0cHM6Ly93d3cuZ29vZ2xlLmNvbSIsInNjb3BlIjoib3BlbmlkIGJhbms6YWNjb3VudHMuZGV0YWlsOnJlYWQgYmFuazp0cmFuc2FjdGlvbnM6cmVhZCIsInN0YXRlIjoiYWYwaWZqc2xka2oiLCJub25jZSI6Im4tMFM2X1d6QTJNaiIsImNsYWltcyI6eyJzaGFyaW5nX2R1cmF0aW9uIjoiNzIwMCIsImlkX3Rva2VuIjp7ImFjciI6eyJlc3NlbnRpYWwiOnRydWUsInZhbHVlcyI6WyJ1cm46Y2RzLmF1OmNkcjozIl19fSwidXNlcmluZm8iOnsiZ2l2ZW5fbmFtZSI6bnVsbCwiZmFtaWx5X25hbWUiOm51bGx9fX0.HzS8ViBsLvZ_lDyf0ArmejPJfS0Ayz_aBwHHbQezd5iob6ybmIGae5l_pHfgy7-vfMmmpH8hAQp8YjfRy7NFDqw5TSabf_BS_u0Ff2Pj8nhumSRTQITMMoq0YatKJwJttpbFXdSurQWtGnhIFiT5Z2tWgb325ChYSwi4-k7Wk7K9HMFsqrhqqPRw-4lBjwiEYnQUd6Zu0R8ptNNxvZe7rRCB0BKH1Q1f1biE93YeZMkAHMe5TDQt0EHQxiQNwZnDGINGG-YqT4wtzw_ANU_Yll29fr6ed2Fcu1P64OVYpTNHDuWNEgT52Td-CM6-p3Dy8035lIeHB-GN6cyrz_4rqQ

Run the following in a browser to prompt the invocation of the authorize API. Make sure you update the placeholders with the relevant values:

Localtabgroup

Localtab

title	Format

Code Block

https://<WSO2_OB_APIM_HOST>:8243/authorize?prompt=login&response_type=code id_token&client_id=<APPLICATION_ID>&redirect_uri=<APPLICATION_REDIRECT_URI>&scope=<AUTHORISATION_SCOPE_AS_PER_REQUEST_OBJECT>&nonce=n-0S6_WzA2Mj
&state=af0ifjsldkj HTTP/1.1&request=<REQUEST_OBJECT>

Localtab

title	Sample

Code Block

https://localhost:8243/authorize?prompt=login&response_type=code id_token&client_id=rVpwuYE72vZP28ucTe3vP7cH0zka&redirect_uri=https://www.wso2.com&scope=openid bank:accounts.detail:read bank:transactions:read&nonce=n-0S6_WzA2Mj &state=af0ifjsldkj HTTP/1.1&request=eyJhbGciOiJQUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6IjEyMyJ9.eyJhdWQiOiJodHRwczovL2xvY2FsaG9zdDo4MjQzL3Rva2VuIiwicmVzcG9uc2VfdHlwZSI6ImNvZGUgaWRfdG9rZW4iLCJjbGllbnRfaWQiOiJyVnB3dVlFNzJ2WlAyOHVjVGUzdlA3Y0gwemthIiwicmVkaXJlY3RfdXJpIjoiaHR0cHM6Ly93d3cuZ29vZ2xlLmNvbSIsInNjb3BlIjoib3BlbmlkIGJhbms6YWNjb3VudHMuZGV0YWlsOnJlYWQgYmFuazp0cmFuc2FjdGlvbnM6cmVhZCIsInN0YXRlIjoiYWYwaWZqc2xka2oiLCJub25jZSI6Im4tMFM2X1d6QTJNaiIsImNsYWltcyI6eyJzaGFyaW5nX2R1cmF0aW9uIjoiNzIwMCIsImlkX3Rva2VuIjp7ImFjciI6eyJlc3NlbnRpYWwiOnRydWUsInZhbHVlcyI6WyJ1cm46Y2RzLmF1OmNkcjozIl19fSwidXNlcmluZm8iOnsiZ2l2ZW5fbmFtZSI6bnVsbCwiZmFtaWx5X25hbWUiOm51bGx9fX0.ZNp8167aNsr_hn4tqQyOoeUbSkPqz5R1hWu_EE-uFgr7RhMHrBQM9JLXNLvwHMbkyQKZgRrer8jxJZceygJaQUerL8YMkN7886ySYlqS9DRtgAomXbfzC9Otl48BIa7sowy8b0YiSbVTnemCojX6mofIRp6WW2IImhsqxI77Jt6ELSSdGg4w0xkeupdEtrGuQoOSins9DkeDcUqFBwPSFWmMuPcRNDgWDqHztynRG0qtuopjO_ruF0ofPpzDq7GicO3gG-IRWdTakjOF3QGjVXh242m9jP745r69Xx1mrxLSGX6wbCybFJTsRereaP6Isbid6hlL-zeLl4TTjMjaIw

You are directed to a login page. Log in with the credentials of a user that has a Subscriber role.
If a secondary factor is required. For example, SMS OTP, provide the relevant values. Upon successful authentication, the user is redirected to the consent management page.
Upon providing consent, the consumer is redirected to the callback URL of the DR ADR with the authorization code.

Step

10

2 - Generate user access token

In this section, you will be generating an access token using the authorization code generated in the section above.

Expand

title	Click here to see how it is done

The client_assertion is a JSON Web Token (JWT). Generate the client_assertion by signing the following JSON payload using the supported algorithms:

Localtabgroup

Localtab

title	client_assertion format

Code Block

{
"alg": "<The algorithm used for signing>",
"kid": "<The certificate fingerprint>",
"typ": "JWT"
}
 
{
"iss": "<The issuer of the token, e.g., client ID of your application>",
"sub": "<The subject identifier of the issuer, e.g., client ID of your application>",
"exp": "<The epoch time of the token expiration date/time>",
"iat": "<The epoch time of the token issuance date/time>",
"jti": "<An incremental unique value>",
"aud": "<The audience that the ID token is intended for, e.g., https://<WSO2_OB_APIM_HOST>:8243/token>"
}
<signature>

Localtab

title	sample client_assertion (decoded)

Code Block

language	js

#Decoded client assertion

{
  "kid": "hcgexuguVb5rYSYVBsl-c9hBPvY",
  "alg": "PS256",
  "typ": "JWT"
}
{
  "iss": "fSYYpF7XustLQF5Mc2shdmPCMKka",
  "sub": "fSYYpF7XustLQF5Mc2shdmPCMKka",
  "exp": 1576913134,
  "iat": 1574324479,
  "jti": "1574324489",
  "aud": "https://192.168.108.14:8243/token"
}
<signature>

Note

The value of the aud claim should contain the same value as the Identity Provider Entity ID.

Expand

title	Click here to view the Identity Provider Entity ID:

Sign in to the Identity and Access Management console at https://localhost:9446/carbon .
In the Main menu, go to Home > Identity > Identity Providers > Resident.
View the value in Resident Identity Provider > Inbound Authentication Configuration > OAuth2/OpenID Connect Configuration > Identity Provider Entity ID. By default this value is set to https://localhost:8243/token .

Run the following cURL command in a command prompt to generate the access token as a DR an ADR user. Use --cert and --key in the access token generation request, for Mutual TLS authentication.

Code Block

curl -X POST \
  https://<WSO2_OB_APIM_HOST>:8243/token \
  -H 'Cache-Control: no-cache' -k \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  --cert <TRANSPORT_PUBLIC_KEY_FILE_PATH> --key <TRANSPORT_PRIVATE_KEY_FILE_PATH> \
  -d 'client_id=<APPLICATION_ID>&grant_type=authorization_code&code=<GENERATED_CODE>&redirect_uri=<APPLICATION_REDIRECT_URI>&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer&client_assertion=<CLIENT_ASSERTION>'

The response of the contains an access token and a refresh token as follows:

Code Block

{
   "access_token":"4f939510-4330-336a-a3d6-3cee7e9f50da",
   "refresh_token":"cedd647f-cb01-3112-bfea-3a5eb61d05a8",
   "scope":"bank:accounts.basic:read bank:accounts.detail:read bank:transactions:read openid",
   "id_token":"eyJ4NXQiOiJORFV3WldGbE16WmlZalV6WmpJeE5USTNZV0V4T0dWXmw",
   "token_type":"Bearer",
   "expires_in":3496
}

Note

Multiexcerpt

MultiExcerptName	refresh_token

The access tokens have an expiration period, once an access token expires, you need to regenerate it. Run the following cURL command to generate a new access token as an AISPusing the refresh token:

Step

11

3 - Invoke Consumer Data Standards API

This section shows how to invoke the endpoints in the ConsumerDataStandards v1 API using a few samples. These requests use the access token generated in the step above .

GET /banking/accounts

The DR ADR is able to obtain a list of accounts that the consumer has authorised the DR ADR to access.

Localtabgroup

Localtab

title	Request

Code Block

curl -X GET \
  https://<WSO2_OB_APIM_HOST>:8243/cds-au/v1/banking/accounts/ \
  --cert <TRANSPORT_PUBLIC_KEY_FILE_PATH> --key <TRANSPORT_PRIVATE_KEY_FILE_PATH> \
  -H 'Accept: application/json' -k \
  -H 'Authorization: Bearer  <USER_ACCESS_TOKEN>' \
  -H 'Cache-Control: no-cache' \
  -H 'Content-Type: application/json' \
  -H 'x-v: v1'

Localtab

title	Response

Code Block

{
  "data": {
    "accounts": [
      {
        "accountId": "61636",
        "creationDate": "2019-05-01T15:43:00.12345Z",
        "displayName": "account_1",
        "nickname": "Alpha",
        "openStatus": "OPEN",
        "isOwned": true,
        "maskedNumber": "1234",
        "productCategory": "TRANS_AND_SAVINGS_ACCOUNTS",
        "productName": "Product name"
      }
    ]
  },
  "links": {
    "self": "https://api.alphabank.com/cds-au/v1/banking",
    "first": "https://api.alphabank.com/cds-au/v1/banking",
    "prev": "https://api.alphabank.com/cds-au/v1/banking",
    "next": "https://api.alphabank.com/cds-au/v1/banking",
    "last": "https://api.alphabank.com/cds-au/v1/banking"
  },
  "meta": {
    "totalRecords": 10,
    "totalPages": 10
  }
}

POST /banking/accounts/balances

The DR ADR is able to obtain balances for a specified list of accounts. The request body contains a list of account IDs to obtain balances for.

Localtabgroup

Localtab

title	Request

Code Block

curl -X POST \
  https://<WSO2_OB_APIM_HOST>:8243/cds-au/v1/banking/accounts/balances \
  --cert <TRANSPORT_PUBLIC_KEY_FILE_PATH> --key <TRANSPORT_PRIVATE_KEY_FILE_PATH> \
  -H 'Accept: application/json' -k \
  -H 'Authorization: Bearer  <USER_ACCESS_TOKEN>' \
  -H 'Cache-Control: no-cache' \
  -H 'Content-Type: application/json; charset=UTF-8' \
  -H 'x-v: v1' \
  -d '{
    "data": {
        "accountIds": [
            "30080012343456",
            "30080098763459"
        ]
    },
    "meta": {
        
    }
}'

Localtab

title	Response

Code Block

{
  "data": {
    "balances": [
      {
        "accountId": "30080012343456",
        "currentBalance": "1234567.89",
        "availableBalance": "10234567.89",
        "creditLimit": "100234567.89",
        "amortisedLimit": "1034567.89",
        "currency": "AUD",
        "purses": [
          {
            "amount": "10.89",
            "currency": "AUD"
          }
        ]
      },
      {
        "accountId": "30080098763459",
        "currentBalance": "1234567.89",
        "availableBalance": "10234567.89",
        "creditLimit": "100234567.89",
        "amortisedLimit": "1034567.89",
        "currency": "AUD",
        "purses": [
          {
            "amount": "10.89",
            "currency": "AUD"
          }
        ]
      }
    ]
  },
  "links": {
    "self": "https://api.alphabank.com/cds-au/v1/banking",
    "first": "https://api.alphabank.com/cds-au/v1/banking",
    "prev": "https://api.alphabank.com/cds-au/v1/banking",
    "next": "https://api.alphabank.com/cds-au/v1/banking",
    "last": "https://api.alphabank.com/cds-au/v1/banking"
  },
  "meta": {
    "totalRecords": 10,
    "totalPages": 10
  }
}

Tip
See Consumer Data Standards Australia - Banking APIs, for more information on all the available endpoints.

Versions Compared

Old Version 24

New Version Current

Key

Step 2 - Approve the DR

Step 1 - Sign up as a Data Recipient

Step 3 - Sign in to the API store as the DR

Step 4 - Create an application

Step 5 - Subscribe to API

Step 6 - Create certificates

Step 7 - Generate keys

Step 8 - Approve Production Key generation

Step 1 - Authorising account consents

Step

2 - Generate user access token

Step

3 - Invoke Consumer Data Standards API

GET /banking/accounts

POST /banking/accounts/balances