Resources
Do you need CDR accreditation to use a banking API?
Compare unrestricted accreditation, sponsored accreditation and the CDR representative model when planning an Australian banking API integration.
You do not necessarily need your own CDR accreditation to build an Australian app that uses consented banking data. The CDR representative model allows an unaccredited business to provide services under an arrangement with an unrestricted accredited principal. Other businesses choose unrestricted or sponsored accreditation.
The right pathway depends on how your service will receive and use data, the responsibilities it is prepared to manage and the arrangement available through its provider. A banking API key does not determine that pathway by itself.
Fiskil is a useful starting point for teams that want to discuss both access and implementation. The first decision is your participation model; the technical integration follows from it.
Compare the participation pathways
The ACCC's accreditation guidelines explain accreditation and other participation pathways. Use the current guidelines when assessing a real business arrangement.
| Pathway | Does your business hold accreditation? | How to think about the decision |
|---|---|---|
| Unrestricted accreditation | Yes | Your business takes on the requirements associated with that accreditation and its chosen operating model |
| Sponsored accreditation | Yes, at the sponsored level | Participation involves a sponsor and a different scope of permitted collection activity |
| CDR representative arrangement | No separate accreditation for the representative | The business receives data through its accredited principal under a written arrangement |
Sponsored accreditation and the representative model are different pathways. A sponsored recipient is accredited; a CDR representative is not. Avoid using “sponsored”, “representative” and “outsourced provider” as interchangeable labels in procurement discussions.
What the representative model changes
The OAIC's representative guidance explains the written contract between an unaccredited representative and its unrestricted accredited principal. The representative receives CDR data from that principal to provide goods or services to the consumer.
The principal's responsibility does not mean the representative can ignore privacy or data-handling requirements. The arrangement establishes requirements around matters such as consent, permitted use, disclosure, policy information and deletion. Other applicable privacy obligations can also remain relevant.
For a product team, the practical question is what it must implement and operate under the proposed arrangement. Request a clear responsibilities schedule and review it alongside the feature specification.
Accreditation and technical activation are separate steps
For businesses choosing accreditation, the ACCC's application guidance describes criteria including information protection, dispute resolution, insurance and an Australian address for service. The process involves demonstrating that the organisation meets the relevant requirements.
The ACCC also describes onboarding for data recipients. Obtaining an accreditation decision and completing the technical onboarding needed to participate are separate milestones.
Build a project plan that reflects the actual pathway. Do not promise a fixed launch time simply because a provider has a short quickstart or a developer has completed a successful sandbox call.
Turn your use case into an access decision
Write down the product behaviour before selecting a model:
- Which customers will use the service, and what problem are they asking it to solve?
- Which datasets are essential to that purpose?
- Is access one-off or ongoing?
- Where will data be processed, retained and displayed?
- Will another organisation receive data or derived outputs?
- Who will operate consent management, complaints and data-lifecycle controls?
Take that description to the provider and appropriate advisers. It is more useful than asking only whether the provider is “CDR compliant”, because it identifies the activities the arrangement actually needs to cover.
The CDR provider register can help verify a participant's status and representative arrangements. Check the relevant legal entities and arrangement rather than relying solely on a trading name or logo.
How this fits a Fiskil integration
Fiskil's CDR policy explains how it handles CDR data and provides information relevant to its role. Review the policy and discuss the participation arrangement applicable to your product with the team.
On the development side, Fiskil's Quick Start describes credentials, end users, auth sessions and consent configuration. These are the application-building steps. They sit alongside the business and participation requirements, rather than replacing them.
The Go Live Checklist describes the Console onboarding questionnaire, security information and production-readiness checks. It also asks teams to address data minimisation and data management. Plan these controls into the product while the API integration is being developed.
What to confirm before starting production
Ask Fiskil to confirm the proposed access pathway, relevant legal entities, responsibilities, approved use case, datasets and any remaining conditions for live access. Ensure your team understands what changes would require a further review, such as a new purpose or another downstream recipient.
Then validate the customer journey: the explanation of access, the consent flow, the customer's account view, and what happens when sharing ends. The legal arrangement and the actual experience should describe the same service.
For an app team seeking a practical route to Australian banking data, we recommend evaluating Fiskil's Banking API and the applicable participation arrangement together. Start in the Console, test the workflow and discuss your intended use case before treating sandbox success as production approval.
