When incorporating the Basiq API into your application, it's essential to follow best practices that significantly contribute to the success of any implementation. These practices span various areas, including security considerations, user experience (UX), scalability, and more. They have undergone thorough testing to provide you with the essential tools and guidelines for a successful integration.
Explore the Frequently Asked Questions (FAQs) below for our platform:
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
We only get
transaction.Date field from the connector (timestamp not available).
We only store date under user transaction data.
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).
We get full datetime from the connector, as
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:
user_transactions_get response, we normalize the time
obTransactionDateTime can't be validated, we add midnight to the
Exposing Data via GET /transactions Endpoint:
For posted transactions, we return
For pending transactions, we return
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 "
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-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.
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:
- the bank is having temporary problems or performance issues - this is the most common cause and should clear on a retry
- 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
- 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.
There is no mechanism to delete a bank account from Basiq as such. The reason for this is that the user's accounts and transactions are fetched from the source (their bank). Basiq fetches all accounts and transactions that the user's bank connection grants access to.
So the next question is - how does a user select which accounts are available for sharing? The answer depends on which method you are using to fetch your user's data.
For web connections (or "screen scraping"), the user provides the login credentials for their bank. In this scenario, Basiq reads all accounts and transactions from the user's internet banking portal. Just as when you log in to your internet banking, you see all of your accounts and there is no option to "not see" an account; likewise, when Basiq fetches accounts via this mechanism, there is no option to "not see" an account: Basiq fetches all accounts and returns them to you via the API. Note that you can choose to filter this list of accounts to return only certain accounts in your UI.
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.
Under CDR, if you need the user to share different accounts (either to remove an account from that sharing arrangement or to include an additional one), you will need to delete the current connection, and then the user will need to set up a new sharing arrangement with their bank for the desired accounts.
CDR is designed in this way, and it is to protect the user and their privacy - but unfortunately, it does require a bit of UX to update the sharing arrangement as a result.
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.
Please reach out to support, if you have any further questions or concerns.
Updated 3 months ago