Open Banking in Australia is the customer-controlled sharing of financial data between accredited providers through the Consumer Data Right. It uses regulated APIs and explicit consent so banks and third parties can access account, transaction, and product data under defined privacy, security, and revocation controls.
How Open Banking Works in Australia
Australia’s Consumer Data Right turns open banking into a regulated data-sharing model rather than a generic API integration. Banks and accredited third parties exchange account, transaction, and product data only within a defined consent framework, so the core operating model is permissioned access to financial data.
The practical effect is that the data holder, the accredited recipient, and the customer each have specific roles. That makes open banking less about simple connectivity and more about governed disclosure, where consent scope, data minimisation, and revocation determine what can move and for how long.
Why the API and Accreditation Model Matters
Open banking depends on regulated APIs because the API is the enforcement point for what may be requested, shared, and withdrawn. A well-designed API layer also creates auditability, which matters when a data access path has to be defensible under privacy and consumer-protection rules.
Accreditation is equally important because it separates ordinary third parties from parties that are permitted to receive CDR data. That distinction reduces the chance that financial data is exposed through informal integrations, weak partner onboarding, or uncontrolled data scraping. For a broader view of how secure data sharing should be structured across financial institutions, see Financial Services Identity Security Guide.
For cloud-delivered implementations, the same trust boundaries also intersect with runtime security, service exposure, and privileged access to data platforms, which is why the CNAPP Guide is relevant to teams operating the infrastructure behind CDR-enabled services.
Security, Consent, and Data Governance Considerations
Open banking creates a direct dependency on consent quality. If consent is vague, overly broad, difficult to revoke, or poorly recorded, the legal permission model weakens even when the API itself is functioning correctly. That makes consent governance part of the security model, not just a customer-experience feature.
Data governance also matters because CDR data is sensitive by nature, even when it is not all equally sensitive. Organisations need clear rules for purpose limitation, retention, logging, and access separation so that shared financial data is not reused beyond the intent the customer approved.
The strongest operational risk is usually not the existence of APIs, but the combination of consent errors, excessive access, and weak partner oversight. If those controls fail, a legitimate sharing channel can become an over-permissive distribution path for customer financial information.
How Organisations Should Assess and Control Exposure
Exposure assessment starts with knowing which systems actually hold CDR data, which interfaces expose it, and which accredited parties can receive it. Organisations should map the full data path, including upstream source systems, API gateways, consent services, and downstream recipients, because hidden copies and shadow integrations often create the real risk.
Controls should focus on revocation handling, monitoring of unusual access patterns, and clear separation between production data and any testing or analytics environments. Where API security is the governing concern, the OWASP API Security Top 10 is a useful companion reference for broken authorisation, authentication, and exposure risks.
Open banking also sits naturally alongside identity and access governance, because approved access depends on strong authentication, controlled delegation, and traceable accountability. Teams that need the control perspective behind that layer should also review NIST SP 800-53 Rev 5 Security and Privacy Controls and NIST SP 800-63 Digital Identity Guidelines.
Risk and Threat Considerations
Open banking can expand the blast radius of a compromise because a single weak consent flow, token, or partner integration may expose high-value financial data across multiple organisations. The main threat is not only direct theft, but abuse of legitimate access paths that were supposed to be tightly limited and revocable.
Failure mechanism: Attackers or negligent integrators can exploit weak authentication, broken authorisation, excessive API scope, or poor consent revocation to access more CDR data than intended.
Impact: The result can be customer data exposure, account profiling, fraudulent product targeting, compliance failure, and loss of trust in the open banking ecosystem.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack surface, NIST SP 800-53 Rev 5, NIST SP 800-63 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API1 — Broken Object Level Authorization | CDR APIs must restrict each request to the specific customer data authorised by consent. |
| Recommendation — Enforce object-level checks so each CDR request returns only data the customer authorised. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Open banking depends on strong authenticated access for staff and operators handling regulated financial data. |
| AC-6 — Least Privilege | CDR implementations need tightly limited access to reduce overexposure of financial data and administrative functions. | |
| Recommendation — Require strong authentication for privileged staff who manage CDR systems and data access. Limit each service and user to the minimum CDR privileges needed to perform its role. | ||
| NIST SP 800-63 | Digital Identity Guidelines | Open banking relies on high-assurance authentication and consented delegation in a regulated access flow. |
| Recommendation — Use phishing-resistant authentication and assurance-aligned identity processes for CDR access. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Open banking requires managed account access, revocation, and review across regulated data-sharing relationships. |
| Recommendation — Control, review, and revoke access paths that can reach CDR data and APIs. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Open banking requires formal access rules for regulated financial data sharing and third-party access. |
| Recommendation — Define and enforce access rules for CDR data, APIs, and third-party connections. | ||
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org