Frequently asked questions

Open Banking (CDR): Open banking, also known as the Consumer Data Right (CDR) in Australia, is a new method for capturing user consent and sharing financial data. Regulated by the Australian federal government, it requires banks to share data via APIs specifically built for this purpose. Unlike DDC, CDR does not require users to share login credentials, is more performant and robust, and banks are mandated to participate.

DDC Connector: Digital Data Capture (or "screen scraping") is a well-established method of aggregating financial data. It involves securely sharing login credentials, which are then passed to the bank's internet banking portal. The portal is parsed to extract a user's accounts and transactions. This method can be slow and is susceptible to changes in the bank's portal. DDC has seen a decline, especially after recent data breaches, as banks take measures to prevent bot access to their internet banking portals.

API Versions: Version 2 of the API supports DDC only. Version 3 supports both DDC and CDR, allowing dynamic switching between the two methods.

A Data Holder refers to a business that currently holds a consumers’ data, such as a bank. Consumers have the authority to instruct registered Data Holders to share their data with an Accredited Data Recipient (ADR).

An ADR is a business accredited by the Australian Competition and Consumer Commission (ACCC) to receive consumer data from a Data Holder, contingent upon the consumer's explicit consent. The ADR then utilises the data for the specified purpose.

BASIQ operates as an ADR within the CDR system, having obtained accreditation by meeting the stringent criteria outlined by the ACCC.

For a comprehensive list of registered Data Holders, refer to the government's CDR website: https://www.cdr.gov.au/find-a-provider

Web Connectors:

We only get transaction.Date field from the connector (timestamp not available).

We only store date under user transaction data.

When compiling user_transactions_get response, we add midnight time normalizedDateTime := transaction.Date + utils.RFCMIDNIGHT.

We set the date for transactions, then 00:00:00Z is appended (indicating UTC).

OB/CDR Connectors:

We get full datetime from the connector, as obTransactionDateTime.

postingDateTime in the case of posted transactions.

executionDateTime in the case of pending transactions.

We store the date in two fields within user transactions data: date and obTransactionDateTime.

When compiling user_transactions_get response, we normalize the time normalizedDateTime.UTC().Format(time.RFC3339).

In case obTransactionDateTime can't be validated, we add midnight to the transaction.Date.

Exposing Data via GET /transactions Endpoint:

For posted transactions, we return postDate.

For pending transactions, we return transactionDate.

We initially save transaction’s dateTime as received from the DH, without any modifications. Per CDR standard, RFC3339 is used for dateTime, meaning all times expressed have a stated relationship (offset) to Coordinated Universal Time (UTC).

All DHs return data in UTC (plus offset, if there is any), or at least they are obligated to convert to UTC, not just set this timezone.

Some DHs actually provide the offset to UTC, like ANZ. Example is "2021-11-19T00:00:00+11:00". This represents UTC + 11 hours. In our system, we have a logic where we calculate this offset to provide in standardized format in UTC without the offset so, "2021-11-19T00:00:00+11:00" becomes "2021-11-18T13:00:00Z". We subtracted 11 hours from midnight, and got the previous day at 13:00 hours. This is correct behavior from our side.

Note: all dateTimes for open banking are in UTC, as this is CDR standard. We cannot convert to local times depending on the time zone, this is impossible for us, and we strive to have a single time zone (UTC is usually the standard).

Some DHs just append 00:00:00Z at the end - now, if they haven’t done conversion to UTC, but just take the date and say it is UTC, this is incorrect behavior from the DH side. In those instances, that transaction within the customer's Internet/Online Banking would show exact times in the local time zone.

We raise these behaviors in a ticket to the DH via the CDR Portal and, over time, we will see improvements in the accuracy of these time stamps.

No, this error does not indicate any problem with Basiq. The error indicates that there was a problem retrieving your user's data from their bank, and as the Basiq job relates closely to your user interaction, we provide a range of actionable error codes to help you to provide the best possible user experience in those cases where the bank fails to return data.

You can read more about these scenarios and recommended actions and user comms here:

The service-unavailable error code is our way to tell you (so that you can tell your user) that their bank was unable to return their data. The equivalent human experience is if I login to my NetBank internet banking and get an error from the bank, "We can't do this right now. Please try again later."

If Basiq gets this response from the bank, there is nothing that we can do other than to pass this detail back to you and your user. Advice is to let your user know there was a problem retrieving their data but to leave the problem with you. You can retry after some appropriate period (e.g., an hour) by refreshing the connection, and if that works you can let the user know that their data has come through.

If the error does not clear after a couple of retries, please reach out to Basiq support portal so that we can take a look. In that case, please just include the Basiq user ID, connection ID and if possible the job ID, to help us to trace the logs.

Reasons that a job might fail with the service-unavailable error:

1. the bank is having temporary problems or performance issues - this is the most common cause and should clear on a retry
2. the bank has made changes to their internet banking portal - in this case, we will need to update our parser code to handle the change, this typically takes a couple of days but depends on the nature of the change
3. the bank is blocking screen scraping - banks are not obliged to support web connections / screen scraping, and some of them are insisting on sharing data through CDR channels only

The Smart-cache is Basiq's way of performing a nightly refresh on your user's data for you! For all active connections, we put the connection in the queue and fetch the most up-to-date data for you once refreshed, e.g., new transactions and updated account balance, etc.

Open Banking allows you up to 20 refreshes per day, which is a huge benefit as compared to Web connections, which requires a more sophisticated approach to not overload the specific institution's server.

Partners should be aware that all data on Basiq is deleted upon expiration or revocation of consent. Partners may wish to keep a de-identified version of the data based on the retainData settings within Basiq customise UI. There may be circumstances where partners are subject to other legal obligations that necessitate the retention of data. These obligations could arise from laws related to financial record-keeping, anti-money laundering regulations, or other relevant legislation. Under these circumstances and based on independent legal advice partners might be able to retain the data beyond expiry date in accordance to relevant legislation.

For open banking (or "CDR", the Consumer Data Right), the user explicitly selects which accounts they want to share with Basiq and your app. The user's selection creates a sharing arrangement between the bank and Basiq, and the selected accounts are in scope for the arrangement (in Basiq we call this a "connection"). The selected accounts and only those accounts are shared with Basiq. If you want the user to add the remaining accounts, you should provide a new consent link with the connectionId parameter to the user, so they can share the missing accounts..

If you are not receiving the verification code by email when trying to reset your Dashboard password, it could be due to several reasons:

• Single Sign-On (SSO) Users:

  If you use Single Sign-On (SSO) methods such as Google Account, Okta, or Azure to log in, you will not receive a verification code. Instead, you need to recover your password through your SSO provider.

• Email Issues:
  • Spam/Junk Folder: Check your spam or junk email folders to see if the verification email was filtered there.
  • Email Address: Ensure that the email address you are checking is the one associated with your Dashboard account.
  • Email Filters: Make sure there are no filters set up in your email account that might be blocking or redirecting the verification emails.
• Technical Issues:
  • Server Delays: Occasionally, there might be delays with the email server. Wait a few minutes and try again.
  • Incorrect Details: Double-check that you entered the correct email address when requesting the verification code.

If you have verified all the above points and are still not receiving the verification code, please contact our support team for further assistance.

Web Connections: Yes, a user can connect multiple times with the same bank using different credentials.

Open Banking Connections: No, only one connection at a time is allowed for each bank.

An account may be ineligible for open banking data sharing under the Consumer Data Right (CDR) for several reasons, particularly within the banking sector:

• Online Accessibility: A key eligibility criterion for Consumer Data Right (CDR) consumers related to a particular data holder in the banking sector is that the account must be set up in a way that it can be accessed online.
• Age Restrictions: Account data related to a joint account or partnership account for which any of the individuals who are account holders is less than 18 years of age at that time is not considered required consumer data nor voluntary consumer data, making such accounts potentially ineligible for open banking data sharing.
• Historical Transactions: For an account that is open, transaction data relating to transactions that occurred more than 7 years before the current time is not considered required consumer data at that time.
• Closed Accounts: For an account that is closed, certain types of data (e.g., account data related to authorizations for direct debit deductions more than 13 months old, transaction data for transactions that occurred more than 12 months before the account was closed if the account was closed no more than 24 months ago, and all account data if the account was closed more than 24 months before the current time) are not considered required consumer data.
• Restrictions on Specific Data Types: Certain data types, like those related to transactions or events that occurred more than 2 years before the current time for an account that is open, are not considered required consumer data.
• Joint Accounts: All parties involved in the joint account must agree to share their data. If such consent is not obtained or the account setup does not support obtaining such consent, the account may be ineligible.

The user is advised to directly contact the respective Data Holder to ascertain the specific reason for the disablement of their account for data sharing. Additionally, they should inquire about the possibility of enabling the account if feasible.