Resources
Business bank account APIs in Australia: coverage, permissions and limitations
Choose a business banking-data API by testing the actual account products, banking channels and people authorised to share data.
Fiskil is our recommended starting point for Australian applications that need customer-authorised business banking data. Evaluate a business bank account API against the account, entity and authorised person you need to connect. Support for a banking brand alone does not answer those questions.
A sole trader using a personal banking channel can have a different connection journey from a company using a specialist business portal. Your launch coverage should describe those differences clearly enough that sales, product and engineering give customers the same answer.
What does business-account support mean?
For a cash-flow tool, you might need transactions from a company's operating account. For merchant onboarding, you may need account and customer information relevant to the entity being onboarded. A treasury product may need several accounts controlled by different people.
Fiskil's Banking API page describes account information for individual and business accounts. That supports investigating a business-data use case, but the specific institution, account product, channel and permissions still need validation.
Ask the provider to separate four coverage questions:
- Can this institution be connected for the proposed service?
- Is the particular account product available?
- Can this person authorise sharing for the account or organisation?
- Does the authorised result contain the fields your task needs?
A missing account can arise from any of these layers. Treating each case as an institution outage makes troubleshooting harder.
Use an account-level coverage matrix
The following is a proposed testing template, not a statement that every row is currently supported by a provider.
| Customer situation | What to establish | Evidence to keep |
|---|---|---|
| Sole trader | Account product, customer identity and permitted purpose | Representative connection and returned fields |
| Company | Organisational relationship and the person permitted to authorise sharing | Tested authorisation journey and selected accounts |
| Partnership | Applicable eligibility and permission arrangements | Provider confirmation for that product and request |
| Trust-related account | How the bank records the entity and authorised person | A specific tested case rather than a generic business-account claim |
| Account with delegated access | Whether the person's access permits data sharing | Evidence of the required instruction or representative setup |
| Specialist business banking portal | Whether the channel is supported for the proposed service | A test through the actual portal used by the customer |
The OAIC explains that non-individual consumers, nominated representatives and secondary-user instructions can affect authorisation. Check the applicable arrangements rather than assuming that online-banking access alone gives a person the required sharing authority.
Build onboarding around the person connecting
Tell the customer which organisation and accounts they are connecting. Provide a useful route when they need another authorised person to complete the task. Avoid asking someone to retry the same journey when the underlying issue is permission.
After authorisation, confirm the selected accounts in the product. Let the user recognise the account without exposing unnecessary account details to every member of your application's workspace.
Keep the organisation relationship separate from a user's login in your own system. If an employee leaves, review their application access without making unsupported assumptions about the bank-side sharing arrangement. Design the two permission systems deliberately.
Find the bank-specific setup instructions
Fiskil maintains a business-account help guide linking to institution instructions. Two examples show why the setup needs to match the customer's actual banking channel:
- CommBank publishes separate delegate instructions for NetBank and CommBiz, including business profiles.
- ANZ Internet Banking for Business lets an administrator manage a user's data-sharing access through its nominated-representative process.
Use the bank's current instructions for the customer's situation. These links explain permission setup; they do not replace confirmation of your provider's production coverage.
Match datasets to the commercial use case
| Use case | Data to investigate | Application work to define |
|---|---|---|
| Business cash-flow view | Accounts, balances and transactions | Entity/account association, freshness and appropriate presentation |
| Merchant onboarding | Available account and identity information | Matching rules, exceptions and any separate verification requirements |
| Reconciliation | Transaction records and useful references | Ledger matching, review queues and accounting controls |
| Business lending | Relevant transaction history and account evidence | Assessment rules, exclusions and human review |
These are product-design examples. They are not guarantees that every source field exists or that the Banking API makes the final verification or credit decision.
Fiskil's banking documentation is a useful starting point for the available data domains. Validate the actual response for the permitted connection before designing a mandatory field into your interface.
Compare business-data providers with representative cases
Use the same test pack across shortlisted providers. Include a personal-style sole-trader journey, a company connection, a delegated user, an account missing from the selection screen and sharing that later ends.
Record the outcome, returned data, cause of failure and proposed customer response. Label a case unverified when you have only a sales assurance. A successful test at one bank is not evidence for another institution's specialist business product.
For expansion into New Zealand, create a separate coverage matrix. The MBIE open banking overview describes phased scope and electronic-facility requirements. Australian business-account support does not establish NZ availability.
Start with a defined business customer
Fiskil's Adyen partnership announcement provides a concrete example of merchant-onboarding and account-verification work in the Australian market. Use the announced use case as context, not as a performance promise for your own implementation.
Bring Fiskil a short description of the business customer, their bank and banking channel, the accounts involved and the intended service. Discuss a tested production scope before turning a broad coverage statement into a product promise.
