Page Comparison

...

Table of Content Zone

maxLevel	3
location	top

Step 1 - Sign up as a TPP

In this step, the TPP registers its TPP application in WSO2 API Store.

Expand

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

Navigate to the API Store at https://<WSO2_OB_APIM_HOST>:9443/store
Select Sign-up that is on the top left corner of the homepage.

Provide the requested details on the Sign Up page.

Expand

title	Click here for more information..

a. Generic details:

Field	Description
Username/Email	The username/email that the TPP uses to sign in to the API Store.
Password	The password that the TPP uses to sign in to the API Store.
Retype Password	This is to prevent the TPP from accidentally setting an incorrect password.
Last Name	This is the last name of the TPP.
First Name	This is the first name of the TPP.

b. Company details:

Field	Description
Legal Entity Name	The official name of the TPP.
Country of Registration	The country in which the TPP is registered.
Legal Identifier Number (LEI)	This identifies the TPP.
Company Register	The organization that registered the TPP.
Company Registration Number	Identifier issued at the TPP registration.
Address Line 1	Address of the TPP.
Address Line 2	Address of the TPP.
City	City in which the TPP is located.
Postal Code	Postal code of the geographical location of the TPP.
Country	The country in which the TPP is located.

c. Competent authority registration details:

Field	Description
Competent Authority	The regulatory body that authorises and supervises the open banking services delivered by the TPP.
Competent Authority Country	Country of the competent authority that authorised the TPP to provide open banking services.
Competent Authority Registration Number	The registration number issued by the Competent Authority to the TPP.
URL of the Competent Authority Register Page	URL of the page that has the list of organizations authorised by the competent authority.
Open Banking Roles	Captures the open banking roles the TPP is willing to take up: Account Information Service Provider: An Account Information Service Provider (AISP) provides an aggregated view of all the accounts and past transactions that a customer has with different banks. To provide this view to the customer, the AISP should have authorisation from the customer to view the corresponding transaction and balance information of all the payment accounts. The AISPs can also provide the facility to analyze the customer's spending patterns, expenses, and financial needs. Unlike a PISP, an AISP cannot transfer funds from a payment account. Payment Initiation Service Provider: A Payment Initiation Service Provider (PISP) initiates credit transfers on behalf of a bank's customer. Payment Instrument Issuer Service Provider (PIISP)/ Card Based Payment Instrument Issuer (CBPII) : A Card Based Payment Instrument Issuer issues card-based payment instruments that can be used to initiate a payment transaction from a payment account held with another payment service provider After selecting PIISP, indicate whether the TPP is authorised by a competent authority to provide the services of the selected roles. If the TPP is not yet registered to provide the services of the selected roles, indicate whether the TPP has applied for registration or not.

Read terms and conditions. Click the checkbox to agree to the terms and conditions.
Click Sign Up. A request to approve the TPP sign up is now sent to the Approver users.

Step 2 - Approve the TPP

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

Note
It is not mandatory to include the approval step for approving the TPP. 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.
Click Start to start the approval process.
Select Approve then Complete.

Now the TPP can sign in to the API Store.

Step 3 - Sign in to the API Store as the TPP

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 TPP 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 TPP.
Click Sign In.

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

Step 4 - Create an application

The TPP with a CBPII 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.
Click Add Application.
Enter application details.

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 the instructions.

Step 5 - Subscribe to API

The TPP user needs to subscribe to the ConfirmationOfFundsAPI - v3.1 API in order to access 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.
Select the ConfirmationOfFundsAPI - v3.1 API.
Select the application you created in the Create an application section.
Set the throttling policy to Unlimited.
Click Subscribe.

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

Step 6 - Create and upload certificates

The TPP user needs to create certificates to validate whether the TPP is registered in a governing entity. It is verified in the TPP Onboarding process. For example, in Dynamic Client Registration, the TPP is dynamically registered with ASPSPs when the client sends a registration request with its metadata. Therefore, the ASPSP is required to upload the root and issuer certificates obtained from Open Banking Implementation Entity. For more information, see Dynamic Client Registration v3.2.

Tip

You can also create a self-signed certificate the following instructions given below and try out the API flow:

Note

When you are using self-signed certificates, make sure to disable the certificate revocation validation:

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

Navigate to the certificate revocation validation configuration and disable it as follows:

Code Block
<CertificateManagement> <!-- Enable certificate OCSP and CRL validation --> <CertificateRevocationValidationEnabled>true</CertificateRevocationValidationEnabled> /CertificateManagement>

Expand

title	Click here to see a self-signed certificate is created...

Note
In order to use self-signed certificates as mentioned in the below steps, disable the `<CertificateRevocationValidationEnabled>` configuration under `<CertificateManagement>` in the `<WSO2_OB_KM_HOME>/repository/conf/finance/open-banking.xml` and `<WSO2_OB_APIM_HOME>/repository/conf/finance/open-banking.xml` files.

A keystore file is used to store the trusted certificates of the TPP 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 TPP.
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 TPP user requires to;
1. Anchor
  sourcekeystorePS
  sourcekeystorePS
  Set a password for the keystore.
2. Provide information, acquired when registering with a governing entity.
3. 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 TPP user requires to;
1. Set a password for the destination keystore.
2. 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: tpp.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 TPP user requires to;

Set a password to import the .pem file.

Once you create a self-signed certificate, upload it to the client trust stores of WSO2 OB APIM and WSO2 OB KM.

Locate the client trust stores in WSO2 OB APIM and WSO2 OB KM in the following directory paths:
- <WSO2_OB_APIM_HOME>/repository/resources/security/client-truststore.jks
- <WSO2_OB_KM_HOME>/repository/resources/security/client-truststore.jks
Use the following command to upload the self-signed certificate:
Code Block
keytool -import -alias <alias> -keystore cacerts -file <PEMFileName>.pem

Step 7 - Generate keys

The TPP 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 TPP user and click either of the following on the Applications tab.

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.
Client ID	OrganizationIdentifier as provided in the EIDAS certificate. The organizationIdentifier attribute contains information using the following structure in the presented order: PSD as the 3-character legal person identity type reference; 2-character ISO 3166 country code representing the NCA country; hyphen-minus (-) 2-8 character NCA identifier (A-Z upper case only, no separator) hyphen-minus (-) PSP (Payment Service Provider) identifier (authorisation number as specified by NCA)
Callback URL	This is the URL used by the CBPII to receive the authorisation code sent from the Account Servicing Payment Service Provider (ASPSP), e.g: 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.
Select Approve and then click Complete.
Navigate back to the API Store and click Applications.
On the Applications tab in the API Store, click View of the application that you created.
Click Production Keys tab to find the generated keys.
It includes the consumer key and consumer secret as follows:

Step 9 - Generate application access token

When invoking the API resources in the Confirmation of Funds flow, application access tokens must be generated using the client credential grant type. The generated application access token is used to invoke the ConfirmationOfFundsAPI - v3.1API.

Expand

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

Note
You can skip the above steps and use DCR v3.2 API to dynamically register the clients.

Once the client is successfully registered, sign in to the /wiki/spaces/OB140/pages/29394577 and go to the Applications tab.
Select your client application from the Application List. Click View of the application that you created.
Choose the Production Keys or Sandbox Keys tab based on your environment.
The Consumer Key shown above is the client ID of your application.

Generate the client assertion by signing the following JSON payload using the supported algorithms.

Localtabgroup

Localtab

title	client_assertion format

Code Block

language	text

{ 
"alg": "<<The algorithm used for signing.>>", 
"kid": "<<The thumbprint of the certificate.>>", 
"typ": "JWT" 
} 

{ 
"iss": "<<This is the issuer of the token. For example, client ID of your application>>", 
"sub": "<<This is the subject identifier of the issuer. For example, client ID of your application>>", 
"exp": <<This is epoch time of the token expiration date/time>>, 
"iat": <<This is epoch time of the token issuance date/time>>, 
"jti": "<<This is an incremental unique value>>", 
"aud": "<<This is the audience that the ID token is intended for. For example, https://<<OB_HOST>>:8243/token>>" 
} 

<signature: For DCR, the client assertion is signed by the private key of the signing certificate. Otherwise the private signature of the application certificate is used.>

Localtab

title	sample client_assertion

Code Block

eyJraWQiOiJoY2dleHVndVZiNXJZU1lWQnNsLWM5aEJQdlkiLCJhbGciOiJQUzI1NiJ9.eyJzdWIiOiJpMkJmbFJyeWIxVkdsRUpHNlpTMDR0bTNHaGNhIiwiYXVkIjoiaHR0cHM6Ly9sb2NhbGhvc3Q6ODI0My90b2tlbiIsImlzcyI6ImkyQmZsUnJ5YjFWR2xFSkc2WlMwNHRtM0doY2EiLCJleHAiOjE1OTkxODcyMDEsImlhdCI6MTU2NTcyMDUzNywianRpIjoiMTU2NTcyMTUzOCJ9.THAG1Ox8hAoGe3hXUvX8rrsIoU7SJfcfSWOxNkdnERb827hxDx2FbVN2wrNhe4A93AYMaCYsHqq8s6p4gkeREWGbJ_IGSjmzJPATWC0oAfAP8hRqdFNUfnTufN7lNlWwySJ7OyBgqorq_ABOx1i741bnld4Jyz8e58gi9UPRi7lFuWnvO-6RwlZY771B1qYNQFTULitV5jX38XJXTX2jrdc_2OkoAS3cL_2x05zZqNFpIvtoK-6XJP1HgRrlDdYx3jzuhAk9F5Q-4BlrbdiUS6QP0PFA_by4y-1vScBAGBhCH4_ViUuGdT9c0FSBGE9_3sLkyj_4SLJRPiQwn6NLbg

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. Update the placeholders with the relevant values.

Code Block

curl -X POST \
  https://<WSO2_OB_APIM_HOST>:8243/token \
  -H 'Cache-Control:no-cache' \
  -H 'Content-Type:application/x-www-form-urlencoded' \
  --cert <PUBLIC_KEY_FILE_PATH> --key <PRIVATE_KEY_FILE_PATH> \
   -d 'grant_type=client_credentials&scope=fundsconfirmations&client_assertion=eyJraWQiOiJqeVJVY3l0MWtWQ2xjSXZsVWxjRHVrVlozdFUiLCJhbGciOiJQUzI1NiJ9.eyJzdWIiOiJVVmF2TmxfQVU0YUtLcWhmRG5LQ0s4Vm9NNmNhIiwiYXVkIjoiaHR0cHM6Ly9sb2NhbGhvc3Q6ODI0My90b2tlbiIsImlzcyI6IlVWYXZObF9BVTRhS0txaGZEbktDSzhWb002Y2EiLCJleHAiOjE1OTkxODcyMDEsImlhdCI6MTU4MDE4NTQ1NCwianRpIjoiMTU4MDE4NTQ1NCJ9.cTzQuuzQ5dEZBWioHwH5rOB58Vk73M3Gds7CxYIWYuPrV5U6fTRh1wAbtA447BXPThJ_jPyyxotlTU3nBnJOuUDhXcj0TFjEjZS4s1YvAQoBTbIrEuH0Do2Lar1G2U9jFXmjLRuQc5N_zlBe2zAe8g-UlDYE6gsdLlc3hz60zWuYjUKaYBAnrTdDpYpP3UiEzEtwyptMmBSRZ3KVluZz3tT43nvqGj3eLOVEdSXFW6ZGMEPu3OxSDOk7QTAgRpdm777ek2aIcv946Zw4LiWDPkP8LdD_4Cb5o35pVpstVI-DY1bLhKCAzTpivOUrY7v_BJUSvFvWa08UQV2JufL_aA&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer&redirect_uri=https://wso2.com/' -k

The access token is now generated.

Tip
You can use the same cURL command to regenerate the access token.

Step 10 - Initiate funds confirmation consents

In this step, the TPP creates a request to get the consent of the PSU to confirm the funds available in the bank account. The Bank sends the request to the PSU stating the accounts and information that the TPP wants to access. Upon the user approving or denying the account consent, the TPP is now eligible to access to confirm funds are available.

Expand

title	Click here to see how it is done

POST /funds-confirmation-consents

This resource creates a consent to access the accounts to confirm that the funds are available. Use the following format in the request body.

Code Block

{
  "Data": {
    "DebtorAccount": {
      "SchemeName": "UK.OBIE.IBAN",
      "Identification": "GB76LOYD30949301273801",
      "SecondaryIdentification": "Roll 56988"
    },
    "ExpirationDateTime": "2020-05-02T00:00:00+00:00"
  }
}

Fill in all mandatory fields.
- x-fapi-financial-id - The unique id of the ASPSP to which the request is issued. This id will be issued by OBIE.
- Authorization - An Authorisation Token as per https://tools.ietf.org/html/rfc6750. Enter the application access token, you generated from the above step.

A sample request follows the format given below.

Code Block

curl -X POST \
  https://<WSO2_OB_APIM_HOST>:8243/open-banking/v3.1/cbpii/funds-confirmation-consents \
  -H 'Authorization: Bearer <APPLICATION_ACCESS_TOKEN>' \
  -H 'Cache-Control: no-cache' -k \
  -H 'Content-Type: application/json' \
  -H 'accept: application/json' \
  -H 'x-fapi-financial-id: open-bank' \
  -d '{
  "Data": {
    "DebtorAccount": {
      "SchemeName": "UK.OBIE.IBAN",
      "Identification": "GB76LOYD30949301273801",
      "SecondaryIdentification": "Roll 56988"
    },
    "ExpirationDateTime": "2020-05-02T00:00:00+00:00"
  }
}'

The response will bear the ConsentId.

Code Block

{
   "Data":{
      "Status":"AwaitingAuthorisation",
      "StatusUpdateDateTime":"2020-01-28T04:46Z",
      "DebtorAccount":{
         "SecondaryIdentification":"Roll 56988",
         "SchemeName":"UK.OBIE.IBAN",
         "Identification":"GB76LOYD30949301273801"
      },
      "CreationDateTime":"2020-01-28T04:46Z",
      "ExpirationDateTime":"2020-05-02T00:00Z",
      "ConsentId":"a964ec37-5b26-47e4-a865-974921aa3b6c"
   },
   "Links":{
      "Self":"https://localhost:8243/open-banking/v3.1/cbpii/funds-confirmation-consents/a964ec37-5b26-47e4-a865-974921aa3b6c"
   },
   "Meta":{
      "TotalPages":1
   }
}

GET /funds-confirmation-consents/{ConsentId}

A CBPII may retrieve a funds-confirmation-consent resource that they have created to check its status. In order to make this request, the CBPII must have an access token issued by the ASPSP using client credentials grant.
Fill in the mandatory fields.
ConsentId - The unique id of the consent which you want to retrieve.
x-fapi-financial-id - The unique id of the ASPSP to which the request is issued. This id will be issued by the OBIE.
Authorization - An Authorisation Token as per https://tools.ietf.org/html/rfc6750. Enter the application access token, you generated from the above step.

A sample request is in the format below.

Code Block

curl -X GET \
  https://<WSO2_OB_APIM_HOST>:8243/open-banking/v3.1/cbpii/funds-confirmation-consents/<CONSENTID> \
  -H 'Authorization: Bearer <APPLICATION_ACCESS_TOKEN>' \
  -H 'Cache-Control: no-cache' -k \
  -H 'Content-Type: application/json' \
  -H 'accept: application/json' \
  -H 'x-fapi-financial-id: open-bank'

Following is a sample response.

Code Block

{   
   "Data":{
      "Status":"AwaitingAuthorisation",
      "StatusUpdateDateTime":"2020-01-28T04:46Z",
      "DebtorAccount":{
         "SecondaryIdentification":"Roll 56988",
         "SchemeName":"UK.OBIE.IBAN",
         "Identification":"GB76LOYD30949301273801"
      },
      "CreationDateTime":"2020-01-28T04:46Z",
      "ExpirationDateTime":"2020-05-02T00:00Z",
      "ConsentId":"a964ec37-5b26-47e4-a865-974921aa3b6c"
   },
   "Links":{
      "Self":"https://localhost:8243/open-banking/v3.1/cbpii/funds-confirmation-consents/a964ec37-5b26-47e4-a865-974921aa3b6c"
   },
   "Meta":{
      "TotalPages":1
   }
}

DELETE /funds-confirmation-consents/{ConsentId}

If the PSU revokes the consent to data access with the CBPII, the CBPII must delete the funds-confirmation-consent resource. In order to make this request, the CBPII must have an access token issued by the ASPSP using client credentials grant.
Fill in the mandatory fields.
- ConsentId - The unique id of the consent which you want to delete.
- x-fapi-financial-id - The unique id of the ASPSP to which the request is issued. This id will be issued by OBIE.
- Authorization - An Authorisation Token as per https://tools.ietf.org/html/rfc6750. Enter the application access token, you generated from the above step. Use the following format and replace the placeholders.

Given below is a sample request.

Code Block

curl -X DELETE \
  https://<WSO2_OB_APIM_HOST>:8243/open-banking/v3.1/cbpii/funds-confirmation-consents/<CONSENTID> \
  -H 'Authorization: Bearer <APPLICATION_ACCESS_TOKEN>' \
  -H 'Cache-Control: no-cache' -k \
  -H 'x-fapi-financial-id: open-bank'

If the deletion is successful you will get a 204 No Content response.

Step 11 - Authorizing funds-confirmation-consents

The CBPII 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.

Localtabgroup

Localtab

title	Request object format

Code Block

{
  "kid": "<CERTIFICATE_FINGERPRINT>",
  "alg": "<SUPPORTED_ALGORITHM>",
  "typ": "JWT"
}
{
  "max_age": 86400,
  "aud": "<This is the audience that the ID token is intended for. e.g., https://<WSO2_OB_APIM_HOST>:8243/token>",
  "scope": "fundsconfirmation openid",
  "iss": "<APPLICATION_ID>",
  "claims": {
    "id_token": {
      "acr": {
        "values": [
          "urn:openbanking:psd2:sca",
          "urn:openbanking:psd2:ca"
        ],
        "essential": true
      },
      "openbanking_intent_id": {
        "value": "<CONSENTID>",
        "essential": true
      }
    },
    "userinfo": {
      "openbanking_intent_id": {
        "value": "<CONSENTID>",
        "essential": true
      }
    }
  },
  "response_type": "<code:Retrieves authorize code/code id_token: Retrieves authorize token and ID token>",   
  "redirect_uri": "<CLIENT_APPLICATION_REDIRECT_URI>",
  "state": "YWlzcDozMTQ2",
  "exp": <EPOCH_TIME_OF_TOKEN_EXPIRATION>,
  "nonce": "<PREVENTS_REPLAY_ATTACKS>",
  "client_id": "<APPLICATION_ID>"
}

Localtab

title	Sample request object

Code Block

eyJraWQiOiJqeVJVY3l0MWtWQ2xjSXZsVWxjRHVrVlozdFUiLCJhbGciOiJQUzI1NiIsInR5cCI6IkpXVCJ9.eyJtYXhfYWdlIjo4NjQwMCwiYXVkIjoiaHR0cHM6Ly9sb2NhbGhvc3Q6ODI0My90b2tlbiIsInNjb3BlIjoiZnVuZHNjb25maXJtYXRpb24gb3BlbmlkIiwiaXNzIjoiVVZhdk5sX0FVNGFLS3FoZkRuS0NLOFZvTTZjYSIsImNsYWltcyI6eyJpZF90b2tlbiI6eyJhY3IiOnsidmFsdWVzIjpbInVybjpvcGVuYmFua2luZzpwc2QyOnNjYSIsInVybjpvcGVuYmFua2luZzpwc2QyOmNhIl0sImVzc2VudGlhbCI6dHJ1ZX0sIm9wZW5iYW5raW5nX2ludGVudF9pZCI6eyJ2YWx1ZSI6ImE5NjRlYzM3LTViMjYtNDdlNC1hODY1LTk3NDkyMWFhM2I2YyIsImVzc2VudGlhbCI6dHJ1ZX19LCJ1c2VyaW5mbyI6eyJvcGVuYmFua2luZ19pbnRlbnRfaWQiOnsidmFsdWUiOiJhOTY0ZWMzNy01YjI2LTQ3ZTQtYTg2NS05NzQ5MjFhYTNiNmMiLCJlc3NlbnRpYWwiOnRydWV9fX0sInJlc3BvbnNlX3R5cGUiOiJjb2RlIGlkX3Rva2VuIiwicmVkaXJlY3RfdXJpIjoiaHR0cDovL3dzbzIuY29tLyIsInN0YXRlIjoiWVdsemNEb3pNVFEyIiwiZXhwIjoxNjExNzQ1NDIwLCJub25jZSI6Im4tMFM2X1d6QTJNaiIsImNsaWVudF9pZCI6IlVWYXZObF9BVTRhS0txaGZEbktDSzhWb002Y2EifQ.bnMr41blZrEPplgeXtdNn4pHvss2D6cgcrhwHQI5rJDIuPNTFLgneG4QMfDis9iKnoYUclU3zqIi9Kr2XxJpUVntJS-Rx7_QcYMQGzgjSskyI7aEi8zDUoCq6YJ2qI6aqFD6vIgMKPja9at2WkoPqun1ZJnRa1hPPm0GUNwGUl5j8pu7G0dBgSEvvD_INQfI1eryOqLUFhaW4z903rV0TulSeOWlR1HFEoq1M53wCGY4F6ZOFOUr2Hsq4NP-nR28ddedmkQz5uHwjisDfhQjvWMS7oQS2pCFxe7Ud6gvWYSbpXmKiITYW6X9rRVl16p4MFJKyGpF0jWiEyCH-CLImQ

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

Code Block

https://<WSO2_OB_APIM_HOST>:8243/authorize/?response_type=code%20id_token&client_id=<APPLICATION_ID>&scope=fundsconfirmation%20openid&redirect_uri=<APPLICATION_REDIRECT_URI>&state=YWlzcDozMTQ2&prompt=login&nonce=<REQUEST_OBJECT_NONCE>&request=<REQUEST_OBJECT>

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, e.g. SMSOTP, provide the relevant values. Upon successful authentication, the user is redirected to the consent management page.
Upon providing consent, an authorization code is generated.

Step 12 - Generate user access token

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

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

Code Block

language	js

eyJraWQiOiJoY2dleHVndVZiNXJZU1lWQnNsLWM5aEJQdlkiLCJhbGciOiJQUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJVVmF2TmxfQVU0YUtLcWhmRG5LQ0s4Vm9NNmNhIiwic3ViIjoiVVZhdk5sX0FVNGFLS3FoZkRuS0NLOFZvTTZjYSIsImV4cCI6MTYxMTc0NTQyMCwiaWF0IjoxNTgwMTkwNzA4LCJqdGkiOiIxNTgwMTkwNzE4IiwiYXVkIjoiaHR0cHM6Ly9sb2NhbGhvc3Q6ODI0My90b2tlbiJ9.BUS6sx6lVvoNTZF49kWYhmqm5tXcVjQJSB_wbIpLiAC-FHmAM_FzEF4822mOrzNNY5cJdJxB0Echu3bnHrSwfZQT2jEIUU-94YqK63w8JTVnkql9C5dUvba-C2t8zGkSdoOtKBZVlIMQ0uOCbReinfiviXFY_KpBV5N2870Q3k1L9thjht0cWFGSo4Sep8lhR7v5Dc02b6bpXdNDMKRLIUstz2Rub9PxdBvUy_bb9mPBzgVaid8Q_3YsEfWp4RwXhlrDugmFRgKk9XFJK76hHDe5uX020clPhfrxoX1CL4kw_r6ONbBy_hPJrKtc-J76Bmqb0pfYADLISwmodo0ASQ

Run the following cURL command in a command prompt to generate the access token as a TPP user:

Code Block

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

The response contains an access token and a refresh token.

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 a CBPII:

Step 13 - Invoke Confirmation of Funds API

Following API functionality is available in the Confirmation of Funds API. These requests use the access token generated in the step above.

POST /funds-confirmations

If the CBPII would like to confirm funds with the ASPSP, it should create a new funds-confirmation resource, and check the FundsAvailable flag in the response.

Localtabgroup

Localtab

title	Request

Code Block

curl -X POST \
  https://<WSO2_OB_APIM_HOST>:8243/open-banking/v3.1/cbpii/funds-confirmations \
  -H 'Accept: application/json; charset=utf-8' -k \
  -H 'Authorization: Bearer <USER_ACCESS_TOKEN>' \
  -H 'Cache-Control: no-cache' \
  -H 'Content-Type: application/json; charset=UTF-8' \
  -H 'x-fapi-financial-id: open-bank' \
  -d '{
  "Data": {
    "ConsentId": "<CONSENTID>",
    "Reference": "Purchase02",
    "InstructedAmount": {
       "Amount": "20.00",
       "Currency": "USD"
    }
  }
}'

Localtab

title	Response

Code Block

{
   "Data":{
      "FundsConfirmationId":"836403",
      "CreationDateTime":"2017-06-02T00:00:00+00:00",
      "Reference":"Purchase02",
      "FundsAvailable":true,
      "ConsentId":"1941900b-9373-429f-957b-502d397f510e",
      "InstructedAmount":{
         "Amount":"20.00",
         "Currency":"USD"
      }
   },
   "Links":{
      "Self":"https://api.alphabank.com/open-banking/v3.0/funds-confirmations/836403"
   }
}

...

Versions Compared

Old Version 5

New Version Current

Key

Step 1 - Sign up as a TPP

Step 2 - Approve the TPP

Step 3 - Sign in to the API Store as the TPP

Step 4 - Create an application

Step 5 - Subscribe to API

Step 6 - Create and upload certificates

Step 7 - Generate keys

Step 8 - Approve Production Key generation

Step 9 - Generate application access token

Step 10 - Initiate funds confirmation consents

POST /funds-confirmation-consents

GET /funds-confirmation-consents/{ConsentId}

DELETE /funds-confirmation-consents/{ConsentId}

Step 11 - Authorizing funds-confirmation-consents

Step 12 - Generate user access token

Step 13 - Invoke Confirmation of Funds API

POST /funds-confirmations