Set up Connect with your own license

🚧

For regulated clients only

To use this method of connecting with Bud you must be a licensed AISP in the UK. This requires a license from the FCA.

If you have questions please contact us to confirm your status

Below we’ll provide you with a step-by-step guide to help you integrate Bud’s Open Banking Aggregation service when using Bud as a Technical Service Provider (TSP). This means that Bud will be using your license (as a registered AISP) in order to provide an Open Banking Aggregation service to your Customers. This will allow you to use your own interface to connect new account(s).

Before starting

Before starting you’ll need:

• to have provided your account manager with details requested during onboarding to allow Bud to register your Open Banking License with providers (ie banks);
• a valid OAuth access token - for further details on how to authenticate to Bud’s APIs please see this guide; and
• a valid customer_id and customer_secret associated with your ‘Project’ (API Credentials). For further details on how to register a customer, please refer to this guide.

View providers & check maintenance windows

The GET /v1/open-banking/providers endpoint (here) will allow you to view the available providers supported by Bud’s Open Banking Aggregation service. Each provider object will contain a maintenance_window and maintenance_status fields. These can be used to check if a provider is currently (or soon to be) undergoing maintenance and may include a timescale for how long it will be in maintenance.

{
    "operation_id": "open_banking_providers_get",
    "data": [
        {
            "provider": "Amex",
            “regions": [
                "GBR",
                "FRA"
            ],
            "display_name": "American Express",
            "icon": "https://assets.thisisbud.com/openbanking/amex-logo.png",
            "maintenance_window": null,
            "maintenance_status": "inactive"
        },
        {
            "provider": "Monzo",
            "regions": [
                "GBR"
            ],
            "display_name": "Monzo",
            "icon": "https://assets.thisisbud.com/logos/Monzo/v1/[email protected]",
            "maintenance_window": null,
            "maintenance_status": "inactive"
        }
    ],
    "metadata": null
}

The provider field within the response body, e.g. “provider”: “Lloyds”, shows the name of the ASPSP that your Customers can connect to. Please note that the value of this provider field is the unique identifier for the corresponding ASPSP, and it is used elsewhere within Bud’s OB Aggregation APIs.

📘

What is a maintenance window?

A maintenance window is a period of time where the provider (ASPSP) will be making changes or improvements to their service. During this time the maintenance_status will be listed as active and your customers will be unable to make a connection to these providers. When the maintenance_window is over the provider will be available to connect to.

Configuring Callback URL(s)

Clients are required to configure their Callback URL(s) in order to receive event notifications regarding the status of different tasks. In terms of Bud Connect, Bud will use your Callback URL to send requests detailing the status of different account connections and refresh tasks.

There are three different webhooks available in regard to the Open Banking Aggregation flow:

1. Open banking sync completed - works for both connect and refresh tasks. This will fire when an open banking connect or refresh task (in both the TSP and TPP scenarios) either completes or fails. The result field returned in the response will provide some details as to why a given task may have failed (if the status field is equal to “Failed”).
2. Open banking connection completed - for those who are just interested in the connect tasks (i.e. not refresh). This will fire when an open banking connect task (in both the TSP and TPP scenarios) either completes or fails. The result field will provide some details as to why a given task may have failed (if the status field is equal to “Failed”)
3. Open banking refresh completed - those who are just interested in the refresh tasks (i.e. not connect). This will fire when an open banking refresh task (in both the TSP and TPP scenarios) either completes or fails. The result field will provide some details as to why a given task may have failed (if the status field is equal to “Failed”)

❗️

Please note that all of Bud's Callbacks are sent over TLS as standard

Callback URL set up steps

The steps to set-up your Callback URL are as follows:

• Log into the Bud developer console
• Navigate to Projects
• Select the project that you would like to configure the callback for
• There will be a header for Webhooks that will appear within the project
• Select the edit icon next to Open Banking Sync Complete
• Input your chosen URL into the text space provided.

The Callback URL specified will be used to notify you when Bud has completed (or failed) fetching the customer’s account information from the relevant ASPSP. At this point, the customer’s account information will be ready to collect via the relevant GET data endpoints (of which there are many).

Steps to connect account(s)

The steps to connect your customers(?) account(s) are as follows:

1. The first step to allow your customers to connect to a new provider, is to make a request to the Initiate Provider Authorisation URL endpoint. Using the POST /v1/open-banking/authorisation-url endpoint (here), you will need to specify a provider_redirect_url and provider (retrieved from the providers endpoint detailed above, value is provider within each object) within the request payload e.g. {"provider": "Natwest_Sandbox", "provider_redirect_url"="https://thisisbud.com/"}.
   This will initiate the process for generating an authorisation URL with the specified provider. The URL returned in the metadata block under the next_url value can then be queried to retrieve the URL to be presented to the user. The output for this request can be found under the Retrieve Authorisation URL endpoint

❗️

Please note that the returned URL returned by authorisation-url/{task_id} needs to be presented to the user within three hours for all providers. Once this expiration time has been reached, you will need to obtain a new URL for that customer by repeating step 1 above.

2. Direct your customer to the Providers Authorisation URL provided in the response. (maybe add an example, eg send customer to the URL via web browser)
3. Having completed the authorisation flow with their provider, your customer will then be redirected back to your specified redirect_url provided to your account manager. The provider will return a number of different query parameters in the URL calling your redirect_url. All these query parameters should be transposed into the body of a request to Submit Authorisation Codes POST v1/open-banking/authorisation-codes endpoint (here). This as a minimum needs to include a code and state value as below.

{  
	"code":"test_code",  
	"state":"360e5821-4f18-4077-83f4-c9a7c1768bea"  
}

Please note this should be submitted for all responses.

4. On a successful submission, Bud will then start fetching your customers account information from the provider. The result of this task will be pushed to your configured Callback URL. An example request payload within a callback of a successful connection task is follows:

{  
    "data": {  
        "event": "open-banking.sync.success",  
        "task_type": "connect",  
        "customer_id": "cb43172f-418a-46e9-b8ab-508654fbc7e3",  
        "task_id": "360e5821-4f18-4077-83f4-c9a7c1768bea",  
    }  
}

❗️

Please note that the account will be connected in a matter of seconds. If the connection fails, the customer will need to try again.

Fetch account information

To see the customer's account information you will need to use the GET v1/open-banking/accounts (here) and GET financial/v2/transactions (here) endpoints. These endpoints are used to show the accounts a customer has given their consent to connect to and the transactions of the accounts respectively.

1. Use the GET /v1/open-banking/accounts endpoint (here) to return all of your customers’ connected accounts in the response. You can also specify the account_id in the request headers to return the data for a specific bank account. The results field found within the metadata object shows the number of accounts returned in the response body.

2. Use GET /financial/v2/transactions endpoint (here) to return the latest transactions for all your customers' connected accounts.

• You can use the X-to and X-from parameters (along with a huge variety of others to filter the response) to specify a timeframe, by default the endpoint will return the last three months.

• You can use the account_id of your customer's account in order to return transactions for a specific account.

• The transaction information is returned with various enrichments that have been applied to the data, which include (but are not limited to):

  • Categorisation: transactions are enriched with 12 categories and 90 subcategories.
  • Merchant Identification: identifies any merchant associated with a transaction and returns its name and logo.
  • Regular Transactions: identifies whether a transaction reoccurs over a weekly, monthly, or quarterly period, including (but not limited to) Direct Debits, Standing Orders, regular credit card subscriptions, and regular transfers.

Refresh an existing account connection

The refresh endpoint pulls the latest data from your customer's connected account(s). Without the use of this endpoint, only the transactions that were pulled at the date/time the account was initially connected would be available via the Retrieve OB Data endpoints. Further recommendations for refreshes can be found here

To initiate a refresh for a customer’s accounts, use the POST /v1/open-banking/refresh endpoint (here) with the name of the provider in the body e.g. Barclays. You may also specify the timeframe of the transactions you would like to retrieve using from and to both followed by the date and time of each parameter; in the format 2019-01-01T00:00:00+00:00. If you do not specify a timeframe, transactions will automatically be retrieved, from seven days prior to the date of the most recent transaction within an account (this is to account for any changes in the account information that the provider may have made), and to today's date and time.

You will be provided with a task_id within a successful response which can be used to poll for the status of the refresh task.

{
  "operation_id": "open_banking_provider_refresh_post",
  "data": {
  	"task_id": "0169b8b6-69e0-4d85-8e3a-c7aa275eed02"
  },
  "metadata": {
  	"next_url": "/v1/open-banking/refresh/0169b8b6-69e0-4d85-8e3a-c7aa275eed02",
  	"next_url_delay": 50
  }
}

To see the status of an account refresh use GET /v1/open-banking/refresh/{task_id} endpoint (here) followed with the task_id. The status will show as Pending, Completed or Failed. If the status is Pending please wait for 10s before retrying (unless it’s time-sensitive, in which case try every 5s). If pending persists, then get in touch with get in touch with support. Once completed, the data is ready to be collected via the Fetch Financial Data endpoints here . See the payload below for an example of a successful account refresh task.

❗️

Please note that clients will also receive a callback on the successful completion of a refresh task.

This payload contains a number of useful fields which will inform your next step. If 'reconnect_required': true then the consent has either expired or been revoked. This means we will no longer be able to fetch new transactions or the balance. In this case, you should prompt your customer to reauthenticate their consent.

📘

The 'has_new_transactions' field will tell you whether any new transactions have been pulled from the provider as part of the refresh. Only if the value is set to true should you then hit our Insight APIs.

{
    "operation_id": "open_banking_provider_refresh_get",
    "data": {
        "bank_name": "Capital_One",
        "provider": "Capital_One",
        "reconnect_required": false,
        "step": 2,
        "text": "Success"
    },
    "metadata": {
        "status": "Completed"
        "has_new_transactions":true
    }
}

If the refresh task has failed you will need to understand why before determining your next step. The reason for the failure will be documented in the "result" field. Please find an example response below.

{
   "operation_id":"open_banking_refresh_get",
   "data":{
      "provider":"Capital_One",
      "reconnect_required":true,
      "result":"connection_revoked",
      "status":"Failed",
      "step":4,
      "task_id":"360e5821-4f18-4077-83f4-c9a7c1768bea",
      "text":"Completed"
   },
   "metadata":{
      "status":"Failed"
   }
}

The request payload of the callback from a successful refresh task is as follows:

{
  "data": {
    "event": "open-banking.sync.success",
    "task_type": "refresh",
    "customer_id": "cb43172f-418a-46e9-b8ab-508654fbc7e3",
    "task_id": "360e5821-4f18-4077-83f4-c9a7c1768bea"
  }
}

Reconsent

A customer's consent will only ever last for a maximum of 90 days. This means that 90 days after the customer created the initial consent Bud will no longer be able to refresh the account information and the reconnect_required field within the response of a given refresh task status will be set to true. At this point, you will have to prompt your customers to reconsent to that provider. This is achieved by simply repeating the connect account calls and allowing the customer to complete the connection process again via your interface.

📘

Bud recommends that you store the datetime at which customers provide their initial consent against a given provider. This will allow you to pre-empt when a customer's consent for a given provider is due to expire.

If the customer’s consent is less than 90 days old and hasn’t been revoked it is possible to reconfirm the consent to extend the consent for a further 90 days. This can be achieved using the Reconfirm Consent endpoint with a request to POST /v1/open-banking/account-access-consents/{consent_id}/reconfirm endpoint here.

Remove customer consent

If your customer no longer consent to providing access to their account information, it is possible to revoke their consent by following the steps below. These steps cover calling the Initiate Revoke Consent endpoint to perform the task of revoking consent then calling the Retrieve Revoke Consent Status endpoint to check if it has been completed.

Remove customer consent steps

1. CallPOST/v1/open-banking/account-access-consent/revoke endpoint (here) with the customer_id in the request header and name of the provider of the account the customer would like to be removed in the request body. A task_id will be returned as showing in the example below:

{
  "operation_id": "open_banking_provider_revoke_post",
  "data": {
  	"task_id": "01b06f03-46e1-4a0a-91b4-3502aff12774"
  },
  "metadata": {
  	"next_url": "/v1/open-banking/account-access-consent/revoke/01b06f03-46e1-4a0a-91b4-3502aff12774",
  	"next_url_delay": 1000
  }
}

2. Use the task_id in the following GET /v1/open-banking/account-access-consent/revoke/{task_id} (here) to check the status of the response. Status response can be failed, pending and completed.
   1. If the endpoint returns Failed repeatedly; get in touch with support;
   2. if Pending, wait a moment and retry; and
   3. if Completed, revoking consent for your customer has been successful. An example of a successful response is provided below:

{
  "operation_id": "open_banking_provider_revoke_get",
  "data": {},
  "metadata": {
    "status": "Completed",
    "next_url": "/v1/open-banking/account-access-consent/revoke/01b06f03-46e1-4a0a-91b4-3502aff12774",
    "next_url_delay": 1000
  }
}

If you have any questions, please contact us via the chatbot (bottom-right of screen 👉) or via a support request or check our FAQs.