Refreshing customer accounts

The ability to refresh customers' data is an important part of Open Banking (OB) and one of the key advantages over other sources of financial data like credit reference agencies (CRA). With OB, clients are able to refresh a customer's account data in the background daily and more frequently if the customer requests.

When initiating refreshes it’s important to consider the concurrency of requests. In order to control the use of their APIs, banks often set rate limits on the number of calls that can be made at once. If Bud exceeds these rate limits we will receive a 429 response from the banks as detailed by the Open Banking Specification. Since the limit is set by the bank, it is unfortunately out of Bud’s control, furthermore, each bank has its own logic as to how it applies rate limits and varies widely, because of this it is important to spread out your refreshes throughout the day.

A client who is trying to refresh all accounts in bulk, like below, is likely to experience a higher rate of request failures than a client who spreads refreshes over the course of a day.

Refresh recommendations

Below we have documented two approaches you can take in order to spread these requests.

Queuing refreshes

One approach you can take is to queue customer refreshes and fix the number of concurrent refreshes. You should start with the minimum concurrency necessary to refresh your user base during a one-day window and as your user base increases, you can increase your concurrency as appropriate to ensure all accounts can be refreshed at least once a day. Below are examples of how many users per day would be refreshed assuming a constant concurrency:

Random allocation

Alternatively, you can allocate a random offset for each of your accounts on the time that they should be refreshed, the fact that the allocation is random will ensure that refreshes are spaced equally and will help to avoid hitting bank rate limits.

By following one of these two methods you will be able to lower the upper bound of refreshes that are happening concurrently and therefore reduce the number of refresh failures that you experience.

If you would like more information on how to perform an account refresh you can find more information below.

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} (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 Bud’s helpdesk. Once completed, the data is ready to be collected via the Retrieve Financial Data endpoints. See the payload below for an example of a successful account 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"
   }
}

Please note that clients will also receive a callback on the successful completion of a refresh task. The request payload of the callback from a successful refresh task is as follows:

{  
  "data": {  
    "task_id": "030c78b0-617c-4649-9319-e07569362a14",  
    "task_type": "refresh",  
    "customer_id": "82a90a04-4bdf-446a-932e-fb559ea99c29",  
    "status": "Completed",  
    "result": "success",
    "has_new_transactions": "true",
    "reconnect_required": "false",
    "provider": "Capital_One"
  }  
}

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