Policy RegisterComplianceInspectionAudit Evidence

Compliance Policy Register with Clause-Level Citations

A folder of PDFs tells an inspector you have policies. A compliance policy register with clause-level citations shows which approved section answers which rule, who owns it, and how you know nothing was altered.

Shubham Khandelwal

Founder, Omnified · October 14, 2026 · 7 min read

Editorial card reading "A policy register with clause-level citations", with policy sections linked to clause chips.

Short answer. A compliance policy register is not a list of documents. It is a list of obligations, each tied to the section of an approved policy that meets it, with the clause it rests on quoted word for word, a verdict on how well it is met, an owner, and a record of every change. That is what lets you answer an inspector's question in the room instead of after the visit.

Folder versus register

Most regulated firms start with a folder: an AML policy, a sanctions procedure, an outsourcing policy, each a file with a version number in its name. A folder answers one question well: do we have a document called this? It answers the questions that matter during an inspection badly.

Which rule does this paragraph exist to satisfy, and is that rule still in force in the same words?
Which obligations does no approved policy cover at all?
Who is accountable for each obligation, and when was it last checked?
Which version was in force on the date of the transaction under review, and who approved it?

A register turns those into lookups. The unit is the obligation, not the file. Each obligation points to the policy section that covers it, and each policy section points back to the obligations it covers. When either side changes, the link shows it.

The register also keeps time. Every version keeps the dates it was in force and the name of whoever approved it, so the answer to "what did your policy say in March?" is a lookup too, not an archaeology project through e-mail attachments.

What clause-level means

Clause-level mapping ties a policy section to a specific provision: the instrument, the paragraph, and the words. In a good register, each link carries three things.

The verbatim quote: the regulator's own words, copied exactly, so anyone can find them in the source.
The instrument: for example the IFSCA (AML, CFT and KYC) Guidelines, 2022, or, for a Singapore fund management company, MAS Notice SFA04-N02.
The paragraph: for example clause 5.4.2(b)-(c) of the IFSCA Guidelines on legal persons and arrangements, not just "the AML guidelines".

In Policy Register, the quote on a verdict is marked when it has been found word for word in the source, so a reviewer can tell a checked quotation from a paraphrase at a glance.

Obligation detail in Policy Register, demo data: an IFSCA Guidelines clause, a partial verdict with the verified quote and reasoning, the covering section, and the option to overrule with a reason. — One obligation in detail: the clause, the verdict with the quote it relied on and why, the section that covers it, any human override, and the owner. Demo data: fictitious entity (Demo Capital IFSC / Demo Asset Management). Not a customer.

Covered, partial and gap

Each obligation gets one of three working verdicts, plus not applicable where a rule does not reach your licence or activities.

Covered: an approved, effective section meets the obligation.
Partial: a section addresses it, but leaves part of it out. The verdict says which part, so the fix is a targeted edit rather than a rewrite.
Gap: no effective policy text addresses it.

Verdicts come from your policy text and are reviewed by your team. They are re-checked when a policy takes effect and when a rule they rest on changes, and each shows the date it was last checked. Partials and gaps also open tasks in an upgrade inbox, so they do not sit unnoticed in a report.

Policy Register obligations register filtered to gaps for a Singapore fund management company, demo data. — The register filtered to gaps for a Singapore fund management company, each row an SFA04-N02 obligation no effective section covers yet. Demo data: fictitious entity (Demo Capital IFSC / Demo Asset Management). Not a customer.

Owners and overrides with reasons

Every obligation has an owner: the person accountable for keeping it covered. Ownership is what turns a gap from a finding into somebody's task.

Sometimes the verdict is wrong for your firm: a rule that does not apply because you do not offer the product, or a requirement met by a procedure the register does not hold. An authorised person can overrule the verdict, but only with a written reason. The override is recorded with who made it and when, it is shown next to the original verdict rather than replacing it, and it stands until the rule's text changes, when the obligation is assessed again. An inspector sees both the judgment and the reasoning.

Where each answer lives

It helps to test a register against the questions you expect, before an inspector asks them. If the answer to any of these is "we would have to put that together", the register is not yet doing its job.

The inspector asks	Where the answer is
Which of our rules does this policy address?	The obligation trace: each requirement, its citation, the covering section and the verdict
Which rules does nothing address?	The register filtered to gaps, each with an owner
Who decided this rule does not apply to you?	The override on that obligation: who, when and the written reason
Was this version approved, and by whom?	The approval evidence: stage, decision, signer and any board resolution
What did the policy say on a past date?	The version history, with the dates each version was in force
How do we know this file is the one you approved?	The recorded SHA-256 of the pack, and the hash of the approved text

Inspection questions mapped to the register record that answers them.

Showing an inspector

The register earns its keep on inspection day. Three things make the evidence checkable rather than merely presentable.

An expiring, read-only link

An administrator can share chosen approved, effective or superseded policy versions with an external inspector through a link that lasts from 1 to 30 days. The inspector needs no account and can only read. The link can be withdrawn at any time, and visits and downloads are recorded.

Inspector links in Policy Register, demo data: time-limited, read-only links for an external inspector, one active and one withdrawn, with visits and downloads logged. — Inspector links: one active until its expiry date, one withdrawn, each with its visits and pack downloads. Demo data: fictitious entity (Demo Capital IFSC / Demo Asset Management). Not a customer.

A regulator pack with a SHA-256

For each approved version you can export a regulator pack, as PDF or DOCX. It holds the approved text with your firm's facts filled in, an obligation trace (each requirement, its citation, the section that covers it and the verdict, with overrides marked), the version history, the approval evidence including board resolutions, and an extract of the audit trail. The SHA-256 of every pack is recorded when it is generated. Later, anyone in your team can check a file against that record: if a single byte has changed, it will not match.

Pages from a Policy Register regulator pack, demo data: version history with text hashes, board approval evidence, and a hash-chained audit extract. — Inside a regulator pack: version history with the hash of each approved text, board approval evidence, and the audit extract. Demo data: fictitious entity (Demo Capital IFSC / Demo Asset Management). Not a customer.

The audit trail, in plain words

Every change of state is written to an append-only audit log: a draft submitted, a review completed, a version approved or taking effect, an override, a pack exported, an inspector link created or withdrawn. Each entry is linked to the one before it, so removing or editing an old entry breaks the chain and shows. The pack's extract carries the entry numbers and their hashes, so an inspector can match it against the log rather than taking the firm's word for it.

Reference

Policy Register

Clause-level mapping for IFSCA-regulated entities and Singapore fund management companies, with owners, reasoned overrides and inspector-ready evidence.

See the obligations register →

Frequently asked questions

What is clause-level mapping?

Linking each section of a policy to the specific provision it satisfies, named by instrument and paragraph, with the regulator's words quoted exactly, instead of linking a whole document to a whole regulation.

How is coverage decided?

From your policy text, reviewed by your team. Each obligation gets a verdict of covered, partial or gap with the passage it relied on, and an authorised person can overrule any verdict with a written reason.

Can an inspector see our policies without an account?

Yes. An administrator can create a read-only link to chosen approved versions that expires after 1 to 30 days. The inspector opens it without an account and can download a regulator pack for each document; visits and downloads are recorded, and the link can be withdrawn at any time.

How do we prove a pack wasn't altered?

The SHA-256 of every regulator pack is recorded when it is generated. Checking a file against that record shows whether it is exactly the pack that was produced, and when it was produced. Each approved version's text carries its own hash too.

Keep reading

Editorial graphic for Omnified's analysis of FinCEN Consent Order 2026-03 against Bank of America, showing a monitoring threshold with alerts falling just below it.

October 14, 2026 · 27 min

Bank of America's $1.2B FinCEN Penalty: What Happened, Where It Failed, How to Avoid It

Editorial card reading "Policy management for regulated fintechs", with stacked policy sections and clause chips.

October 14, 2026 · 8 min