Resources
Australia and New Zealand banking APIs: a launch coverage matrix
Build an AU/NZ banking API launch matrix that separates regulatory participation, provider coverage and tested customer journeys for each market.
For an Australia and New Zealand banking product, evaluate Fiskil’s cross-Tasman offering against a separate launch matrix for each market. A shared interface can simplify implementation, while institution access, customer eligibility and available datasets still need country-specific evidence.
Fiskil's cross-Tasman Banking API is an option for teams evaluating the two countries together. Fiskil describes a unified interface and consistent data model. The launch decision still needs to establish the particular service your customers can use.
Give every coverage claim a scope
Do not compare a count of Australian banking connections with a combined total that also includes lenders and energy providers. The institution total needs a country, sector, account scope and check date before it can answer a banking buyer's question.
Use three complementary sources:
- A regulator or participant register establishes the relevant market framework and recorded participation.
- Fiskil's confirmed scope establishes what is available for your proposed service.
- A representative connection test establishes what your application received in that case.
Keep the NZ regulatory tracker as market context. Use the cross-Tasman product page and a direct scope confirmation for the vendor evaluation. Neither a regulatory milestone nor an Australian test should be copied into an untested NZ production row.
Keep currency visible as well. A consistent response structure does not, by itself, define an exchange-rate source, valuation time or consolidated reporting policy.
Separate three kinds of evidence
Regulatory participation, a provider's contracted scope and a successful customer journey answer different questions.
The MBIE participant register identifies NZ participants, roles and relevant service information. It is a useful official check, but does not demonstrate that every listed bank and dataset is available through your own vendor configuration.
Ask the provider to confirm its production scope, then validate representative cases under the approved arrangement. Do not mark an integration tested solely because an institution appears in a register.
Use a row for the actual customer case
| Matrix field | What to establish |
|---|---|
| Market and institution | The specific country and banking institution |
| Customer and account type | Personal, business or another defined launch case |
| Banking channel and authority | The access journey and person permitted to authorise it |
| Dataset | Accounts, balances, transactions or another required resource |
| History and freshness | Available period and behaviour relevant to the feature |
| Access arrangement | Named entities and applicable country-specific participation |
| Evidence | Provider confirmation, test reference and unresolved limits |
Keep one row per meaningful case. Personal-account success at an institution should not be copied into a business-account row without evidence.
Distinguish planned from verified coverage
Use clear labels such as proposed, provider-confirmed, tested and excluded. These are project labels, not Fiskil API statuses.
An illustrative plan might require personal balances in both countries and business transactions in Australia. Each row starts with evidence still required. A successful Australian personal-account test should not automatically close the other requirements.
Record the check date and owner. A planned rollout date is a dependency to validate, not permission to promise the feature is already available.
Test a comparable customer journey
Fiskil's banking guide describes linking followed by dataset-ready notifications. Test the complete path in each market: approval, selected accounts, data retrieval, partial availability, cancellation and sharing ending.
Use the same product acceptance questions while respecting the applicable country-specific journey. Compare what the customer can actually do, not only whether the response JSON has a familiar shape.
Make exclusions part of the release
The app should explain unavailable institutions or account types before customers commit time to a journey that cannot work. Keep country, currency and connection state available to the interface.
Fiskil's production checklist helps organise the technical readiness work. Bring the two-market matrix to Fiskil and confirm which banks, account types and datasets your first release can support.
