Let AI Maintain the Obligations Register. Make a Human Own Every Change.

AI can compare approved source versions and propose candidate regulatory changes. It cannot decide what binds your organisation. Make it propose source-linked deltas, then require a named human to accept the legal state, effective date and register change.*

Your obligations register should not be a regulatory scrapbook. It should tell the business what applies, why it applies, when it applies, who owns it and which control gives effect to it. AI can help keep that record current. It should not be allowed to turn a consultation paper, amended guide or newly made instrument into an accepted obligation by itself.

The decisive control is not a better summary prompt. It is a change workflow in which every AI-proposed delta carries its own primary-source evidence, authority class, instrument version, legal status, commencement date, uncertainty and named human decision. Until that decision is recorded, the proposal stays outside the accepted register.

That boundary also keeps this work distinct from regulatory impact assessment. Register upkeep establishes the verified source state and the obligation record. Only after acceptance should another workflow assess affected products, processes, controls, policies, systems and accountable people. It is the same division of labour as a living validation passport: the accepted record changes only through a named human decision.

Does the law require an obligations register?

Do not describe the register itself as a universal statutory artefact. The current Corporations Act 2001, compilation C2026C00339 from 1 July 2026, requires an Australian financial services licensee under section 912A(1) to meet general obligations including compliance with licence conditions and financial services laws. Section 912A does not prescribe a document called an obligations register.

ASIC Regulatory Guide 104, updated in March 2026, is guidance explaining what ASIC looks for when assessing compliance with most section 912A(1) obligations. RG 104.23 to RG 104.32 discusses documented, implemented, monitored and current compliance measures. RG 104.26 says ASIC expects documentation to include responsibility, timeframes, record keeping and reporting. RG 104.32 says measures should be reviewed when obligations, the business or its environment change. RG 104.44 expressly allows compliance measures to comprise one or several documents and stand-alone or integrated IT systems.

That makes an obligations register a possible control design, not a prescribed label. Your legal and compliance teams still need to determine what form is adequate for the organisation's licences, activities, products, jurisdictions and other applicable regimes.

For APRA-regulated banks and insurers, CPS 220 Risk Management is an enforceable prudential standard in force since 1 July 2019. It requires a risk management framework covering material risks and a designated, adequately staffed compliance function with a reporting line independent from business lines. For RSE licensees, SPS 220 Risk Management is an enforceable prudential standard in force since 1 January 2020. Its risk management strategy must include mechanisms for monitoring and ensuring ongoing compliance with all prudential requirements.

Neither standard tells you to buy a particular obligations library or maintain a field with a particular name. APRA's 17 February 2022 compliance-risk publication is supervisory commentary, not a prudential standard. It says financial services organisations do not face one consolidated set of obligations and describes better practice as a hybrid of subscription services and compliance subject matter expertise, enhanced by business-unit involvement. It also warns that when Line 1 fails to take accountability for compliance management, Line 2 must step into day-to-day management of obligations and controls, limiting its capacity for oversight and challenge.

The hierarchy matters. Law, enforceable prudential standards and licence conditions are not the same as regulatory guidance, supervisory commentary, consultation material or internal policy. If the register collapses those categories into one column called requirement, AI will accelerate the ambiguity.

What should AI be allowed to change?

Give AI permission to create a candidate change envelope, never permission to overwrite an accepted row. The envelope is an immutable proposal containing the evidence needed for a human decision.

At minimum, require:

• primary-source URL and issuing body;
• Act, instrument, standard, guide or document identifier;
• source version or compilation and the earlier version compared;
• authority class, such as law, enforceable standard, licence condition, guidance, consultation or internal control;
• status, such as proposed, made but not commenced, in force, amended, repealed or superseded;
• publication or making date, commencement or effective date, and any transition date;
• exact changed passage and source location, not just a model summary;
• candidate register rows affected, with the match reason;
• confidence, unresolved ambiguity and missing evidence; and
• named reviewer decision, rationale and timestamp.

This is a source-state decision, not legal advice from a model. The reviewer checks that the documents are authentic and current, the versions are correctly paired, the change is within scope, the authority class is right and the dates have the claimed legal effect. Applicability and interpretation remain human judgements.

Use this prompt to produce a change envelope from approved primary documents. A regulatory subject matter expert must verify the comparison and decide whether any proposal enters the accepted register.

Compare [CURRENT_PRIMARY_SOURCE] with [PRIOR_PRIMARY_SOURCE] for [DOCUMENT_ID]. Use only the supplied official documents. Do not decide legal effect and do not update the obligations register.

Return:
1. issuing body and authority class
2. document IDs, versions or compilations
3. status of each document
4. publication or making date, commencement or effective date, and transition dates
5. exact changed passages with source locations
6. candidate affected register IDs and match reasons
7. confidence, ambiguity and missing evidence

Separate consultation, made but not commenced, in-force and superseded material. Mark unknown information as NOT VERIFIED. End with a proposed reviewer queue, not a recommendation to accept.

Build a hard gate around acceptance. The service account used for ingestion can write to a candidate queue but not the production register. The human approver selects accept, reject or return for evidence. Acceptance creates a new version and preserves the old one. It does not silently edit history. That versioned trail serves the same purpose as run lineage: another authorised reviewer can rebuild exactly what was compared and what was decided.

The control checklist is short:

• the cited source is official and the identified version is current for the relevant point in time;
• authority class and legal status are explicit;
• entity, product and jurisdictional applicability have been reviewed;
• commencement, transition and cessation dates have been verified;
• the accepted wording and human rationale are retained; and
• downstream impact assessment has been queued separately where required.

Why does every obligation need two clocks?

One date field cannot answer two different questions. Use valid time for when the obligation applies in the world, and recorded time for when your organisation captured and handled the information. This two-clock method is a proposed internal control, not terminology prescribed by APRA or ASIC.

Keep the source publication or making date as a separate fact. These fields prevent an announcement date, publication date and commencement date from being treated as interchangeable.

The second clock exposes operational lag. If a final instrument was published on [DATEA], recorded on [DATEB] and accepted on [DATEC], the sequence is visible even where its legal commencement is [DATED]. You can investigate why capture or review took too long without rewriting the legal timeline.

It also protects future changes. A rule made now for later commencement can sit as made but not commenced, with its future valid date intact. A consultation can remain proposed and never contaminate the in-force view. When a final document differs from its draft, the draft is closed as a proposal and the final source receives its own envelope.

Fictional worked example: [ENTITYNAME] records consultation paper [CONSULTATIONDOCUMENTID] on [DATEA]. The AI proposes three candidate changes, but each remains outside the accepted register with status consultation. Final instrument [INSTRUMENTID] is made on [DATEB] and commences on [DATEC]. The AI compares the final text with both the prior instrument and draft, while [APPROVERROLE] verifies the source, scope and dates. The accepted obligation is recorded at [DATED], becomes valid from [DATEC] and links back to the superseded obligation and both change envelopes.

The example does not claim the draft created an obligation. Nor does it hide that the organisation learned of the final rule after it was made. Both truths remain queryable.

Use this prompt to test register integrity. The compliance owner must resolve every missing field and decide whether stale or ambiguous rows require correction.

Audit [REGISTER_VERSION] against the supplied change envelopes and primary-source index. Do not search outside the approved source set. Do not infer missing dates, legal status or applicability.

Identify rows missing:
primary source and exact location
document identifier and version or compilation
authority class and legal status
valid_from, valid_to and transition dates
detected_at, reviewed_at, accepted_at and superseded_at
named obligation owner and human approver
supersession link and decision rationale

Return a prioritised remediation queue with evidence references. Mark conflicts as HUMAN REVIEW REQUIRED. Do not amend the register.

Do this Monday

1. Freeze autonomous writes. Remove AI and feed-provider permissions to edit accepted obligation records. Route every machine-generated change to a separate candidate queue.
2. Add the authority and status fields. Start with law, enforceable standard, licence condition, guidance, consultation and internal control. Define who can assign each class.
3. Install the two clocks. Add valid, detected, reviewed, accepted and superseded dates. Preserve source publication or making dates separately.
4. Pilot one instrument family. Select a bounded set with reliable version history. Run the delta prompt against two official versions, then compare the output with a manual expert review.
5. Test the acceptance evidence. Sample five accepted changes. Confirm each can be traced to the exact source passage, date logic, reviewer, decision rationale and previous row.
6. Separate the hand-off. Once a source-state change is accepted, create a distinct impact-assessment task for affected controls and processes. Do not ask the register-maintenance agent to decide implementation.

Bottom line

AI can assist obligations-register upkeep, but only when legal state and history remain intact. The accepted register should change only through a source-linked, versioned and named human decision. Two clocks show both when an obligation applies and when your organisation knew and acted. Let the model propose the delta; make a person own the truth that enters the register.

This article is general information and education only. It is not legal, compliance, financial or professional advice. Obligations vary by organisation and circumstance. Verify current requirements against the primary sources cited and seek advice specific to your situation.

References

1. Federal Register of Legislation, Corporations Act 2001, current compilation C2026C00339, 1 July 2026, including section 912A. https://www.legislation.gov.au/C2004A00818/latest
2. Australian Securities and Investments Commission, Regulatory Guide 104: AFS licensing: Meeting the general obligations, issued 23 June 2022 and updated March 2026. https://download.asic.gov.au/media/av3fovx5/rg104-published-23-june-2022-20260310.pdf
3. Australian Prudential Regulation Authority, Prudential Standard CPS 220 Risk Management, in force 1 July 2019. https://www.apra.gov.au/standards/cps-220
4. Australian Prudential Regulation Authority, Prudential Standard SPS 220 Risk Management, in force 1 January 2020. https://www.apra.gov.au/standards/sps-220
5. Australian Prudential Regulation Authority, How to manage compliance risk and stay out of the headlines, 17 February 2022. https://www.apra.gov.au/news-and-publications/how-manage-compliance-risk-and-stay-out-headlines