Earlier this month we published a piece on APRA’s April letter to Australian banks, insurers and superannuation trustees, which said in plain terms that governance, assurance and operational resilience were not keeping pace with AI adoption.
At the time we said the letter was a preview of what other regulators would say. Two weeks after that piece went live, the next one arrived from across the Tasman.
On 15 October 2026 the Reserve Bank of New Zealand and the Financial Markets Authority stood up together in front of financial services leaders in Auckland and set out their supervisory expectations on cyber risk associated with frontier AI. The session was co-hosted with the Department of the Prime Minister and Cabinet and the National Cyber Security Centre.
Having the prudential and conduct regulators deliver joint remarks, with the national cyber agency and DPMC in the room as co-hosts, sends a clear signal that frontier AI has changed the operating environment, that existing obligations already apply, and that supervisors will be watching how entities respond.
I’ve spent the last few months in conversations with the large Australian financial groups about APRA’s expectations, and I want to walk through what the New Zealand remarks say, why they land harder than their informal format suggests, and what security leaders on both sides of the Tasman should take from them.
Why Joint Remarks Carry This Much Weight
It would be easy to read a roundtable transcript as softer than a formal letter to industry. I think that reading is wrong, for three reasons.
First, the regulators framed these expectations as reflecting existing prudential, conduct, cyber and operational resilience obligations, which means they apply today.
For RBNZ-regulated banks, insurers and non-bank deposit takers, that means the Guidance on Cyber Resilience, the material cyber incident reporting requirement in force since 8 April 2024, and for banks the outsourcing expectations in BS11 that will be carried into the Deposit Takers Act standards from December 2028.
For FMA licensees, it means the Conduct of Financial Institutions regime and, for certain market services licensees, the standard licence condition on business continuity and technology systems that took effect on 1 July 2024.
There is no implementation runway, because nothing new has been implemented. A material AI-enabled cyber incident is reportable to the RBNZ within 72 hours of its materiality being established, the same as any other material cyber incident.
Second, the regulators said this will remain an active supervisory focus and described the session as the beginning of an ongoing conversation.
The FMA already has two pieces of thematic work that will inform how these expectations play out in practice: an exploratory review of AI in financial advice launched on 6 August, and ongoing operational resilience thematic work whose insurance findings were published in July.
Angus McGregor, the Reserve Bank’s Assistant Governor for Financial Stability, and Louise Unger, the FMA’s Executive Director for Response and Enforcement, both made clear that accountability for managing these risks remains with the regulated entity. McGregor closed by saying supervisors will continue to engage with regulated entities so they can be assured the risks are being managed appropriately, and I would plan on that engagement arriving sooner rather than later.
Third, the remarks sit inside a coordinated international push.
The remarks note that frontier AI has been flagged internationally as an “immediate concern” for the global financial system, citing the FSB Chair’s August 2026 letter to G20 finance ministers and central bank governors. The Five Eyes cyber agencies issued a joint call to action in June. New Zealand’s NCSC published guidance on cyber readiness in the frontier AI era the same month.
The RBNZ and FMA cited all three. Regulators are clearly reading each other’s work, and in this part of the world they are moving within months of each other.
For the Australian groups that own four of New Zealand’s five largest banks, this is now a two-regulator story with one set of facts. The APRA letter in April and the RBNZ and FMA remarks in October cover much of the same ground on governance, third-party risk and resilience, and in many cases the same CISOs and CROs will be answering both.
What the RBNZ and FMA Signalled on Securing AI
The remarks are organised around three risk areas: increased cyber risk, evolving governance and oversight challenges, and growing third-party and concentration risk. Underneath those sit five expectations that I think are worth taking one at a time.
Cyber fundamentals, at machine speed
McGregor’s framing was that frontier AI has changed the capability, speed and accessibility of the tools used to find and exploit weaknesses, and that leading open-weight models are now only months behind frontier systems.
The expectation is strong foundational controls, with identity and access management, asset lifecycle management and timely patching named specifically, plus faster risk-based vulnerability remediation.
The line that should get attention is the one asking entities to assess whether predominantly manual monitoring and triage remain adequate against machine-speed threats. I read that as a signal that detective controls relying on people working through alert queues may struggle to keep pace, although the regulators were equally clear that any AI or automation used in defence needs its own oversight, accountability and controls.
Governance that can see where AI is used
Unger’s section was the one most directly aimed at boards. The expectation is that boards and senior management have sufficient visibility of where AI is being used and clear accountability for material AI risks, as adoption extends into areas such as investment research, portfolio management, client communications and financial advice.
The phrase “where AI is being used” sounds simple, yet once organisations start looking they routinely find agents, copilots and MCP servers that never made it onto the risk register. You cannot set risk appetite for something you cannot see.
Third-party and concentration risk
This is the part where New Zealand’s market structure sharpens the point. The regulators pointed to the sector’s increasing reliance on a small number of AI and cloud service providers, a concern the Reserve Bank’s Future of Banking Study also raised. They said plainly that an outage, model failure or operational issue at one of those providers could affect multiple institutions at once.
The expectations are to understand how third parties use AI and how that changes your own exposure, to assess supplier resilience and verify controls, to have contracts that require timely notification of material changes, vulnerabilities and incidents, and to define shared responsibilities clearly.
Fourth parties and foundation models embedded in software are the hard part here, because they are opaque to the entity unless something maps them.
Assume incidents will occur
The regulators expect response and recovery protocols for AI-enabled attacks and disruptions, tested against severe but plausible scenarios. The scenarios they named were high-speed attacks, zero-days, model failure and third-party outages, used to test manual workarounds, backups, failover and recovery.
They also asked for fraud controls, customer and employee verification and awareness programmes to be reviewed against deepfakes, synthetic identities and social engineering.
Listing model failure alongside zero-days and supplier outages puts a model behaving badly in production squarely into resilience testing, in addition to its usual home in model risk management.
An active and ongoing supervisory focus
The regulators set no deadlines and will keep assessing whether current settings remain appropriate, and they asked for sector-wide coordination and information sharing.
In my experience, the absence of a deadline simply means the pressure arrives through the next thematic review, the next cyber capability survey or the next incident report, whichever comes first.
What Security Leaders Should Be Doing
If I were sitting in a New Zealand bank or insurer, or in the Australian parent of one, this is the work plan I would be putting in front of the executive team. Much of it will look familiar to anyone who read the APRA piece, and that overlap is useful because the same evidence can serve both regulators.
Start with a continuous inventory of AI use with named owners. That means a continuously maintained register of models, agents, datasets, tools and MCP servers across cloud services, low-code platforms, source code and endpoints, including the ones that were never sanctioned. Every entry needs a named owner, and that register becomes the artefact that answers Unger’s point about visibility and feeds everything that follows.
Treat agents as distinct identities. The RBNZ named identity and access management first in its list of fundamentals for a reason. Agents and MCP servers hold credentials, roles and tool access, and most IAM programmes were built for humans and service accounts. Map what each agent can reach, flag over-permissive and shared access, and bring non-human actors under privileged access management.
Move from detective to preventive runtime controls. The machine-speed line in the remarks makes a strong case for inline enforcement, inspecting what agents are actually doing, including the arguments of each tool call, and blocking actions outside policy before they complete. Keep a human in the loop for high-risk decisions, and make sure the approval gate is enforced in the request path rather than described in a policy document.
Test on a schedule, and test on change. Point-in-time penetration testing of a deterministic system does not translate to a model that changes when the prompt, the tool set or the upstream provider changes. Recurring, change-triggered adversarial testing for injection, jailbreak, data extraction and tool abuse is what gives the second line evidence that a control still holds.
Map the AI supply chain, including fourth parties. For each agent and application, know the foundation model, the model provider, the hosted services, the MCP servers and the datasets behind it. That dependency map is what lets you quantify concentration, feed the outsourcing register and answer the RBNZ’s question about what happens when a provider fails.
Put model failure in the resilience test plan. Severe but plausible scenario testing should now include an agent that starts behaving off-purpose in production. Know how you detect it, how you cut it off, and how the business continues without it.
Equip the second line and internal audit. Risk and audit need to be able to read inventory, posture and runtime evidence independently of the delivery teams who built the systems. If assurance depends on asking engineering for a screenshot, it is not independent.
Engage early. The regulators have asked for an ongoing conversation. Entities that bring a credible AI risk picture to that conversation early will have far more influence over where it lands than those who wait for the next thematic review.
Where Noma Helps
I work for Noma, so take this section for what it is. I also want to be clear that several of these expectations are organisational and cannot be outsourced to a vendor. Board capability, risk appetite, contract terms, fraud controls and recovery testing stay with the entity.
What a platform can do is give the risk function, the CISO and the auditors a factual, continuous picture of the AI parts of the framework, and enforce controls where policy alone will not.
On visibility, Noma’s continuous discovery across cloud AI services, low-code agent platforms, source code, model registries, data platforms and endpoints builds the register of models, agents, datasets, tools and MCP servers, including unsanctioned ones. Every asset carries an owner, environment, source and first- and last-seen dates. That gives boards the visibility of where AI is being used, and who is accountable for it, that both regulators asked for.
On cyber fundamentals and machine-speed threats, AI-DR inspects prompts, responses, tool output and agent tool calls inline, and blocks prompt injection, sensitive data movement, malicious tool results and unsafe tool and MCP calls as they happen, across AI gateways, agent frameworks and Copilot Studio.
Runtime Protection Profiles set which detectors, including malicious URL detection, inspect each prompt, response, tool call and tool output, and whether a match is blocked, masked or monitored. The Runtime Contextual Engine then evaluates the full session, so an agent action that conflicts with what the user actually asked for can be blocked or sent for approval before it completes. That is the shift from detective to preventive control the RBNZ is pointing toward.
On testing, scheduled and CI/CD-triggered red teaming exercises deployed models and agents for injection, jailbreak, data extraction, tool abuse and MCP exposure, with retests when something changes. Posture scanning finds exposed secrets, vulnerable dependencies and over-permissive tool access. Risk and audit can run their own campaigns and read the results independently of delivery teams.
On third-party and concentration risk, the dependency and lineage view shows the foundation models, providers, hosted services, MCP servers and datasets behind each agent and application. That gives the risk team evidence to quantify concentration and keep the outsourcing register current. The contract terms, notification clauses and exit plans remain the entity’s work.
On incident preparedness, detections and blocked actions reach the SOC through SIEM and webhook integrations as they happen, and fail-open or fail-closed settings per application give a documented kill switch in the request path. Classification, escalation and the 72-hour notification to the RBNZ or FMA remain the entity’s process.
Policies and issues carry alignment to ISO/IEC 42001, NIST AI RMF, the EU AI Act, MITRE ATLAS and OWASP, with export to GRC tooling, so the same evidence can serve the RBNZ, the FMA and, for the trans-Tasman groups, APRA.
We have put together a solution brief that maps each of the RBNZ and FMA expectations to Noma capabilities line by line, and is honest about where Noma covers an expectation directly and where it contributes evidence to a function the entity still owns. Access the brief here: https://noma.security/lp/new-zealands-ai-expectations-and-where-noma-fits.
Closing Thoughts
None of this is exhaustive. The FMA’s thematic reviews will report, the Deposit Takers Act standards will be finalised, and the regulators have said they will keep assessing whether their settings are right. I expect the next eighteen months to produce more specificity, not less.
What I take from October’s remarks is that New Zealand’s regulators have now said, together and on the record, that frontier AI is both a financial stability and a conduct concern, that existing enforceable obligations already cover it, and that they expect boards to be able to see where AI is used and who is accountable for it.
In April that was one regulator in one country, and by October regulators on both sides of the Tasman were drawing on the same international work and reaching broadly similar conclusions.
In previous technology shifts, security arrived after the regulators did, and the regulators arrived after the incidents did. This time supervisors have moved while many of these agents are still being built, which gives security leaders a head start if they choose to use it.
Sources
RBNZ and FMA announcement (15 October 2026) and the published remarks, "Supervisory expectations on cyber risk associated with frontier AI"; NCSC "Cyber readiness in the Frontier AI era" (June 2026); Five Eyes "Call to Action on AI Preparedness" (June 2026); FMA thematic review of AI in financial advice (August 2026); FMA operational resilience thematic, insurance findings (July 2026); RBNZ Deposit Takers Act implementation timeline; RBNZ material cyber incident notification FAQs; FMA standard condition on business continuity and technology systems (July 2024); FSB Chair's letter to the August 2026 G20 finance ministers and central bank governors.
