A bank’s AI programme now touches credit, fraud operations, customer service, software delivery, and the daily work of thousands of staff, all under the bank’s licence conditions in one of the most closely supervised industries in Australia and New Zealand. This explains what AI governance for ANZ banks means, and what it takes to keep AI accountable to APRA, the RBNZ, and the Privacy Commissioner.
What it means for an ANZ bank
AI governance for banks in Australia and New Zealand is the framework and practices that ensure responsible, compliant use of AI across the organisation. It works across four layers: policy defines what AI and its users may do, enforcement applies that policy while the work happens, evidence records what occurred in a form that survives scrutiny, and assurance maps all of it onto the regulatory frameworks the bank answers to.
Those frameworks are specific. In Australia, APRA’s CPS 234 Information Security standard makes boards ultimately responsible for information security, including assets managed by third parties, and CPS 230 Operational Risk Management, now in force, raises expectations around operational resilience and service-provider risk. In New Zealand, the Reserve Bank’s Outsourcing Policy, RBNZ BS-11, requires large registered banks to retain the ability to control and execute functions they outsource, and the Privacy Act 2020 governs how personal information is handled, with breach notification to the Privacy Commissioner. The regimes compound: most of New Zealand’s largest banks are subsidiaries of Australian parents, so a single AI initiative can fall under APRA at group level and RBNZ and Privacy Act requirements locally.
The pressure on ANZ banks
CPS 234 requires an information security capability commensurate with the threats to a bank’s information assets, controls that are tested and assured, and notification of material incidents no later than 72 hours after the bank becomes aware of them. AI creates new information assets and new paths into existing ones: prompts that carry customer records, agents that hold credentials, and model providers outside the bank’s perimeter. RBNZ BS-11 asks whether the bank can still control a function it has outsourced, which a hosted model performing a business function plainly is. The Privacy Act’s information privacy principles are engaged the moment customer data appears in a prompt.
What makes AI different from earlier technology waves is speed and volume. A copilot deployment can generate tens of thousands of governable decisions a day, and agentic systems chain actions together without a human at each step. Governance built on quarterly reviews and periodic sign-offs cannot supervise decisions that happen in milliseconds, continuously. Monitoring platforms describe what the AI estate did after it did it. The moment that matters in a bank is the one where a breach can still be prevented or contained.
In a bank, an ungoverned AI action is itself a risk event, so the absence of a policy decision is treated as a denial.
What it takes
Keeping AI accountable in a bank comes down to three properties, none of which a monitoring dashboard provides.
Enforcement at the point of every AI request. Policy is applied before the action runs, so a breach can be prevented rather than reported.
A graduated response. Observe, alert, require approval, and block or contain, chosen per policy and fail-closed by default. Because an ungoverned AI action is itself a risk event, a request that cannot be evaluated does not run.
Evidence that verifies offline. Every decision is recorded in a tamper-evident trail that internal audit, an external auditor, or a prudential regulator can verify on their own equipment, without trusting the vendor.
Mapping to CPS 234, RBNZ BS-11 and the Privacy Act 2020
Under CPS 234, enforcement at the request layer is a control that demonstrably operates on every AI interaction, and the evidence trail turns assurance from periodic sampling into a continuous record that also shortens reconstruction against the 72-hour clock. Under RBNZ BS-11, the control point sits between the bank’s users and an external model provider, so the bank’s own policy applies before any request reaches the provider. Under the Privacy Act 2020, personal-information handling rules are enforced at request time, and the trail establishes exactly which information was involved if a breach ever has to be assessed.
| Framework | What it covers | What Helixar provides | Status |
|---|---|---|---|
| APRA CPS 234 | Information security for APRA-regulated entities | A control that operates on every AI request, with a continuous record that it operated | Mapped and delivered at implementation |
| RBNZ BS-11 | Outsourcing policy for large NZ registered banks | A bank-owned control point over outsourced AI functions, with per-request evidence | Mapped and delivered at implementation |
| NZ Privacy Act 2020 | Personal information and the information privacy principles | Personal-information rules enforced at request time; evidence for breach assessment | Mapped and delivered at implementation |
| SOC 2 | AICPA Trust Services Criteria | Evidence pack | Available today |
| ISO/IEC 27001 | Information security management systems | Evidence pack | Available today |
Precision matters here. Helixar’s SOC 2 and ISO 27001 evidence packs are available today. Mappings for APRA CPS 234, RBNZ BS-11, and the NZ Privacy Act 2020 are delivered at implementation, tailored to each bank’s control framework. Helixar does not claim certification against these prudential and privacy frameworks. The compliance obligations remain the bank’s, and Helixar supplies the enforced controls and verifiable evidence that support them.
How Helixar approaches it
Helixar is an AI control plane. It enforces policy at the moment of every AI request with the graduated response above, is fail-closed by default, and records every decision in a tamper-evident, independently verifiable trail. A typical rollout starts with observe across the estate to establish a baseline of real AI behaviour, then tightens the highest-risk actions to require approval or block, with verifiable evidence generated from day one. Helixar Limited is based in Auckland, New Zealand, works with design partners in regulated ANZ environments, is an NVIDIA Inception member and supported by Google for Startups, and contributed its HDP protocol to the IETF.
What a prudential regulator sees
The shift is in the nature of the assurance. Point-in-time evidence, such as screenshots and attestation letters, shows a control existed on the day it was examined. A tamper-evident decision record shows the control operated on every governed action across the whole period, and the supervisor can confirm that independently, without relying on the bank’s assertions or on Helixar’s word. Evidence that anyone can check changes the tone of a review.
Common questions
Is Helixar certified under APRA CPS 234, RBNZ BS-11 or the NZ Privacy Act 2020? No. SOC 2 and ISO 27001 evidence packs are available today; those ANZ frameworks are mapped and delivered at implementation. Compliance obligations remain the bank’s.
What happens if the policy engine is unavailable? Helixar is fail-closed by default, so a governed request that cannot be evaluated does not proceed.
How does this differ from Microsoft Purview or IBM watsonx.governance? Those platforms focus on observation and monitoring. Helixar applies policy at the point of every AI action, with graduated enforcement and a verifiable evidence record. Many banks run monitoring alongside it, because the two address different layers.
References
- Prudential Standard CPS 234 Information Security (APRA)
- Prudential Standard CPS 230 Operational Risk Management (APRA)
- Outsourcing Policy for Banks, BS-11 (Reserve Bank of New Zealand)
- Privacy Act 2020 (New Zealand Legislation)
- Privacy Act 2020 and the Privacy Principles (Office of the Privacy Commissioner)
- ISO/IEC 27001, Information security management systems
- AICPA System and Organization Controls (SOC) Suite of Services