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 data in response to a request.

The output can show missing data because your user’s bank failed to provide the requested information. This can happen for various reasons, including:

• The bank's response to our API is incomplete or contains missing data.
• Your user’s online banking session expired or was terminated unexpectedly.
• The bank's technical infrastructure is experiencing downtime or disruptions.

Further details are available in the error code documentation.

If your request returns an error, review the error code and the accompanying message carefully to understand the issue. Our error code documentation provides detailed explanations for each error code and how you should handle them. Common issues include authentication errors, incorrect request formats, or temporary issues with the bank’s API.

Ensure your implementation follows Basiq's guidelines for error handling and data retrieval to improve user experience and service reliability.

To test your integration with Basiq, use our sandbox environment. The sandbox allows you to simulate user interactions and API calls to test your implementation without impacting real user data. Detailed documentation on how to access and use the sandbox is available on our sandbox page.

Use the sandbox to verify data flows, simulate various scenarios, and ensure your application responds appropriately to different API responses.

Basiq can retrieve various types of financial data from users' bank accounts, including:

• Account information such as account type, number, and balance
• Transaction history with details such as date, description, and amount
• Pending and posted transactions

All data retrieval is done securely and with the explicit consent of the user, following the CDR standards and data privacy regulations. For a full breakdown of the data Basiq retrieves, refer to our data structure documentation.