Public CDR APIs vs customer banking APIs: what’s the difference?

Public CDR product APIs describe banking products. Customer banking APIs provide access to an individual or business customer's accounts, balances and transactions through an authorised, consented data-sharing journey. If you are building an Australian app that needs a user's bank feed, a public product endpoint is only part of the picture.

That distinction matters when evaluating a banking API in Australia. A successful request for a list of savings accounts does not mean your app can read the balance of someone who holds one of those accounts.

Fiskil's Banking API is the starting point we recommend for teams building consented customer-data experiences. Here is how to identify which data you need and design the right integration.

Two kinds of banking data, two different jobs

Banks publish product information so software can work with offerings such as transaction accounts, savings accounts and loans. Customer data describes the relationship a particular customer actually has with an institution.

CommBank's developer documentation separates public product APIs from consumer APIs for transactions, accounts, balances and other customer information. AMP's product API documentation explains that its public product data includes features, rates, fees and eligibility criteria, with no authentication required for those product endpoints.

Your app needs to know	Relevant data	Example product decision
What savings products are offered?	Public product information	Build a product catalogue
What fees and rates are advertised?	Public product details	Compare published offerings
Which accounts has this user connected?	Consented customer account data	Populate an account selector
What has the user spent?	Consented transaction data	Build a spending view
What balance is reported for an account?	Consented balance data	Display a financial position

A product comparison can use public data without being personalised. A budgeting app needs the user's actual financial activity. A more personalised service may need both, with each dataset handled through its appropriate access path.

A public endpoint is not a customer's bank connection

An API being publicly documented does not make all data behind it public. Documentation tells a developer how a resource works; authorisation determines whether the application can access that resource for a particular person.

The CDR's customer journey involves a customer giving permission, authenticating with their existing provider and authorising sharing. A product catalogue does not substitute for that journey.

When planning an integration, keep three questions separate:

1. Is the information about a product, or about a customer?
2. What permission and participation pathway applies to the customer-data use case?
3. Which technical interface will return the specific resource?

This prevents a common planning error: testing an easy public endpoint, then discovering late in the project that the feature depends on a completely different access model.

How customer banking data reaches your app with Fiskil

For customer-data applications, Fiskil's Quick Start describes creating an account, generating credentials, creating an end user and setting up the consent flow. Credentials belong on your backend, where they are exchanged for an API access token.

The user then connects an institution and authorises the data sharing. Your backend retrieves the permitted data after it becomes available. Fiskil's Banking guide describes account, balance and transaction datasets, and the sync events used to notify an application when data is ready.

Your app still needs to connect those resources to an actual feature. That might mean transforming transactions into a spending timeline, displaying accounts in an onboarding journey, or calculating a product-specific insight. An endpoint response is an input to that experience.

What if your service needs both datasets?

Consider a hypothetical home-loan comparison app. Public product data can describe offers on the market. Customer banking data can help the service understand the connected user's position. The app's own comparison logic and the customer's preferences determine how the information becomes useful.

Do not treat an advertised rate as proof of the rate a particular borrower currently pays, or an account transaction as a complete description of every product available to that borrower. Record where each value comes from and what it represents.

Useful interface labels include the source of an advertised offer, the account associated with a customer value, and the relevant update time. These are product-design recommendations, not additional fields guaranteed in every API response.

Questions to ask before choosing an API

Ask a provider to demonstrate the exact dataset your feature needs. For a customer-data product, review the consent journey, supported institutions and account types, response fields, freshness information and production-access process. For product data, check coverage, product categories, version requirements and how updates are handled.

Then test one representative journey end to end. A catalogue request, a successful bank link and a complete transaction import prove different things. Document what your test actually covered.

Fiskil brings the customer-data workflow together through its Banking API, supported by current documentation and a sandbox. Start in the Fiskil Console, identify the resource your feature depends on, and build the consented customer journey around it.