FAR Eased Up. Your AI Map Still Holds

ASIC and APRA are cutting FAR paperwork. The accountability behind your AI use-case register has not moved. On 16 June 2026 the two regulators announced changes to reduce the administrative burden of the Financial Accountability Regime, and the practical question for a governance, risk and compliance (GRC) team is narrow and important: what must you still actively document, and what now only needs to be available on request.

Context for general readers: The Financial Accountability Regime (FAR) makes named senior executives in banks, insurers and superannuation funds personally answerable for the parts of the business they run. Each accountable person has a documented set of responsibilities, and ASIC and APRA supervise the regime jointly. The 16 June 2026 announcement lightens some of the routine reporting around that regime. It does not change who is accountable for what.

This piece is the companion to the site's earlier analysis of how FAR accountability maps to AI tooling decisions. That piece argued that an AI tool deployed inside a regulated function sits inside a named person's accountability whether or not the responsibility map records it. The relief announced in June sharpens the point rather than softening it. When the scaffolding of routine reporting gets lighter, the record of where AI actually lives becomes more load-bearing, not less.

What ASIC and APRA actually changed

The 16 June 2026 package, developed as part of the Government's Better Regulation reforms announced in the 2026-27 Budget, proposes trimming three categories of reporting obligation under FAR. According to ASIC and APRA's joint announcement, the three are these.

• The prescribed key-functions list goes. Accountable entities have had to assign a defined list of key functions to accountable persons and record them in the FAR register. That prescribed list is being removed from the regulator rules, so entities no longer have to map every function against the fixed schedule.
• Accountability maps lose the direct-report detail. Entities will no longer be required to include information about the direct reports of accountable persons in their accountability maps. The regulators estimated this single change would at least halve the number of updates entities have to make to their maps, since changes among direct reports will no longer need to be recorded in the map.
• The notification threshold rises. The materiality threshold at which an entity must notify ASIC and APRA of a change to its accountability arrangements is being lifted, so smaller or lower-materiality changes no longer trigger a filing.

Alongside the FAR-specific changes, ASIC said it will streamline responsible manager Australian financial services (AFS) licensing requirements for FAR entities by reducing the requirement to submit evidence of competence, from October 2026. The regulators estimated the FAR reforms would reduce reporting for all accountable entities and around 4,500 accountable persons, with the responsible manager change benefiting roughly 2,000 current AFS licensees.

ASIC and APRA will consult on the FAR changes and aim to implement them by the end of 2026. The 16 June announcement set no consultation close date, so watch the regulators' consultation pages for the window. A GRC team should read the exposure material closely, because the shape of the final rules will decide how the two-tier split below is drawn. Note that this FAR relief is separate from APRA's concurrent governance-standard consolidation under draft CPS 510, also announced on 16 June 2026 but on a longer commencement timeline. The two are easy to conflate and should be tracked separately.

What did not change, and why it matters for AI

The regulators were explicit that the package reduces regulatory burden without lowering accountability standards. Read that sentence twice before touching your AI register.

Everything the earlier FAR analysis described as the substance of the regime is untouched. A named accountable person is still identified for each part of the business. The Financial Accountability Regime Act 2023 still requires that person to take reasonable steps to discharge their accountability. ASIC and APRA can still act against an individual who fails to do so. An AI tool deployed in claims triage, AML transaction monitoring, underwriting or customer personalisation still sits inside a prescribed responsibility, and the accountable person still owns the consequences of how it behaves.

What changed is the volume of routine filing, not the substance of the obligation. That distinction is the whole story for AI governance, because it separates two things that are easy to blur: the reporting scaffolding around accountability, and the evidence that an accountable person actually discharged it. The relief lightens the first. It does nothing to the second. If anything, it raises the stakes on the second, because there will now be fewer scheduled map updates prompting anyone to notice that an AI tool has quietly entered a regulated workflow.

The failure mode to watch is a plausible-sounding misread on the executive floor: "regulators are cutting FAR paperwork, so we can ease off the AI documentation too." That reasoning is wrong in a way that is expensive. Lighter filing does not reduce the need to explain an adverse automated decision, to show who owns a given AI tool, or to evidence that its risks were monitored through the existing risk channels. Those are exactly the questions a supervisor asks when something goes wrong, and they are exactly the questions an AI use-case register the board can actually use exists to answer.

The real shift: document the core, produce the rest on request

The useful way to absorb this change is to stop thinking of AI documentation as one undifferentiated pile that either grows or shrinks. Split it in two.

There is documentation you must actively maintain: the current, owned, reported record that a named accountable person keeps live and reports against on a defined cadence. Then there is documentation you must be able to produce on request: the deeper evidence library that supports a decision when a regulator, an auditor or the board asks for it, but that does not need to be routinely filed or refreshed on a calendar.

FAR's relief moves several items from the first bucket toward the second. Direct-report detail in the map, sub-threshold notifications and the prescribed key-functions schedule were all "maintain and file" obligations. They are becoming "hold and produce" at most. The mistake is to let AI evidence drift the same way by default. Some of it genuinely belongs in the on-request library. The core of it belongs in the maintained record precisely because the lighter map no longer forces the question of where AI sits.

Use this split to restructure the AI use-case register rather than trim it. The following belongs in the actively maintained core, and a named owner should keep it current:

• Every AI tool operating inside a regulated function, mapped to the accountable person whose responsibility it sits within.
• The current risk rating and the control owner for each tool, routed through the existing operational, compliance or conduct risk channels rather than a separate AI committee.
• Material changes since the last review: a new use case, a model or vendor change, a new automated decision that affects customers, or a near-miss.
• The date of the last accountable-person attestation that explicitly covered AI risk, and the next one due.

The following can sit in the on-request evidence library, available but not routinely filed:

• Procurement and due-diligence records for each AI tool, including vendor assurances and the concentration and substitutability assessment.
• Model documentation, testing results and monitoring output that evidence the tool was fit for purpose.
• The reasoning trail behind a specific automated decision, retained so it can be reconstructed if that decision is challenged.
• Historical map and register versions showing how accountability allocations changed over time.

The test for which bucket an item belongs in is simple. If a named accountable person needs it to know their portfolio is under control this quarter, it is core. If a regulator or auditor might ask for it after the fact, it is on-request. Almost everything about AI belongs in one bucket or the other. Nothing about AI belongs in neither.

A worked example

Consider a mid-sized general insurer, described here in de-identified terms. Before June, its FAR responsibility map was refreshed roughly monthly, and most of those refreshes were driven by personnel changes below the accountable-person line. Its AI use-case register, maintained by the operational risk team, was updated on the same monthly rhythm because the two processes had been bolted together for convenience.

After the relief, the map no longer needs the direct-report detail, so the monthly personnel-driven churn largely disappears. The risk is obvious once it is named: if the AI register was only ever updated because the map update forced it, the register now goes stale by default. Three new AI use cases could enter claims and underwriting over a quarter without anyone updating the record, because the trigger that used to prompt the update is gone.

The insurer's fix is to decouple the two and give the register its own cadence and its own owner. The maintained core of the register is reviewed quarterly by the accountable person for operational risk, with material changes flagged as they happen rather than batched. The procurement records, model documentation and decision-reasoning trails move to a clearly labelled on-request library with defined retention. The accountability did not change. The insurer simply stopped relying on a soon-to-be-lighter reporting obligation to do its AI record-keeping for it.

Two prompts to run on the register

These prompts assume a de-identified working copy of the register. Strip names, employee identifiers and any customer data before pasting anything into a general-purpose AI tool, and keep the analysis inside an approved, access-controlled workspace.

You are helping a GRC analyst restructure an AI use-case register in light of
the June 2026 FAR reporting relief. Below is a de-identified list of AI use
cases, each with: [USE_CASE], [REGULATED_FUNCTION], [ACCOUNTABLE_ROLE],
[RISK_RATING], [LAST_REVIEWED_DATE].

For each use case, classify its supporting documentation into two tiers:
1. Maintained core (owned and reported on a cadence).
2. On-request evidence library (available but not routinely filed).

Flag any use case where the accountable role is missing or ambiguous, and any
where the last review date is older than one quarter. Return a table in plain
text. Do not invent use cases or dates that are not in the input.

[PASTE_DEIDENTIFIED_REGISTER]

Act as a critical reviewer. Here is a draft two-tier AI documentation split for
a [ENTITY_TYPE] under FAR: [PASTE_DRAFT_SPLIT].

The FAR relief of 16 June 2026 removed direct-report detail from accountability
maps, removed the prescribed key-functions list, and raised the notification
threshold, without lowering accountability standards. Assess whether this split
would leave the entity unable to answer any of these on request: who owns each
AI tool, why an adverse automated decision was made, and how each tool's risk is
monitored. List every gap and the single change that would close it. Be specific
and do not soften the findings.

Do this Monday

1. Confirm whether your AI use-case register updates are triggered by FAR map updates. If they are, that trigger is about to get weaker, so schedule the decoupling now.
2. Give the register its own named owner and its own review cadence, independent of the map refresh cycle. Quarterly is a sensible default for the core.
3. Split the register into the maintained core and the on-request evidence library using the two-bucket test above. Label each item so no one has to guess later.
4. Route AI risk reporting for the maintained core through existing operational, compliance and conduct risk channels, not a separate AI committee report.
5. Check that each accountable person's next attestation prompts them to consider AI risk explicitly, with the maintained core attached as supporting evidence.
6. Watch for the ASIC and APRA consultation material and lodge any concerns once the window opens, focusing on where the lighter map could obscure AI use cases.
7. Brief the board or risk committee in one line: FAR reporting is easing, accountability is not, and the AI register is now the primary record of where AI sits.

Bottom line

The 16 June 2026 FAR relief is real and welcome, and it is narrow. ASIC and APRA are cutting routine reporting, not accountability. For a GRC team, the trap is treating "less FAR paperwork" as "less AI documentation," when the honest response is to restructure the AI use-case register into a maintained core and an on-request library and give it a cadence of its own. The map got lighter. What a named person owns did not. Package the evidence to match that reality, and the relief is a genuine efficiency rather than a quiet erosion of the record you will one day need.

Content disclaimer: This article is for general educational and informational purposes only. It does not constitute legal advice, regulatory guidance, or a substitute for professional compliance judgement. Regulatory obligations vary by entity type, licence, and circumstance. The FAR changes described here were announced for consultation at the time of writing and may change before they are finalised. Always refer to primary source guidance from APRA, ASIC, or the relevant regulatory authority.