Your policies should know what the regulator said

Every newly licensed financial entity meets the same wall a few weeks before commencement. The licence is granted, the team is small, often one person, and the regulator expects a complete, board-approved set of policies to be in place and working.

The questions arrive in a predictable order. Which policies do we actually need? What must each one contain? Who has to approve it? How often must it be reviewed? And, a year later, the harder one: when the regulator issued that circular last month, which of our policies did it make out of date?

Most firms answer these with a consultant's checklist, a folder of Word documents and a spreadsheet that maps paragraphs to rules. It works until the first inspection or the first significant rule change. Then it becomes an archaeology exercise.

We think the policy register is one of the most under-engineered pieces of compliance infrastructure, and that it can be rebuilt on a better foundation. This post explains how we are approaching it at Omnified.

Why policy registers fail today

The typical register treats a policy as a file. It records a title, an owner, a version number and a review date, and stores the PDF. That is document management, not compliance management.

Three failures follow from that design.

The link to the rule lives in someone's head. Whether the AML policy actually satisfies the regulator's record-retention clause is known only to the person who wrote it, or to the spreadsheet they left behind. When that person moves on, the reasoning goes with them.

Review runs on the calendar, not on the rulebook. Annual review catches drift eventually. It does not catch the circular that changed a threshold in March and took effect in May. Regulators increasingly expect firms to show they responded to a specific change, not that they reread everything once a year.

A small change costs a full re-approval. When the policy is one 40-page document, a one-clause amendment sends the whole thing back to the board. Teams delay updates to avoid the overhead, which is exactly the wrong incentive.

None of this is a people problem. Compliance officers are doing careful work with tools that were never designed to hold the relationship between a policy and a rule.

Start from the obligation, not the document

Our starting point is different. Omnified maintains a structured regulatory corpus: the regulator's circulars, regulations, notifications and guidance, broken down to the clause, with each binding obligation extracted, coded and tied to its verbatim source text. For IFSCA alone, that is more than a thousand instruments, each classified as binding or non-binding.

In the Policy Register, that obligation graph is the spine. A policy is a set of sections, and every section is linked to the specific obligations it satisfies. Each link carries a verdict (covered, partial, gap or not applicable), the exact passage of the policy that does the work, and the reasoning behind the verdict.

That single change makes several things possible that a file store cannot do.

• Coverage is computed rather than asserted. You can see, for every applicable obligation, which section of which policy addresses it.
• A rule change can be traced to the precise sections it touches, instead of to "the AML policy, somewhere".
• Versioning, redlines and approval can happen per section, so a one-clause amendment stays a one-clause amendment.

The section, not the document, becomes the unit of compliance work.

Which policies do you actually need?

Regulations do not only impose duties on how you run the business. Many of them also impose duties about the policies themselves: that a firm shall have a board-approved policy on a topic, shall review it at a set interval, and that it shall cover certain elements.

We treat these clauses as a distinct class of obligation, which we call a policy mandate. Each mandate records the topic, the type of document required (policy, procedure or register), the approving body, the review cadence and the required contents, all traced to the source clause.

Combine the mandates with what we already know about the entity from onboarding (its regulator, licence class, activities, customer types, markets and risk profile) and the register can produce a policy blueprint: the list of policies this specific entity needs, and why.

Each item in the blueprint shows:

• whether it is required, conditionally required or recommended;
• the clause that mandates it, quoted verbatim;
• who must approve it and how often it must be reviewed;
• a checklist of what it must contain;
• where the entity stands today: missing, uploaded, in draft, approved or overdue.

Two design choices matter here. Conditional requirements are asked, not assumed: "required if you onboard virtual-asset customers" becomes a question, and the answer updates the profile. And recommendations drawn from non-binding guidance are clearly labelled as such, never presented as law.

When the business changes, the blueprint changes with it. Add a new activity or customer segment and the register shows which policies that decision just added to your obligations.

Drafting from the regulator's own words

Generative AI can produce a plausible AML policy in seconds. That is the problem. A plausible policy that cites the wrong clause, borrows language from another regulator, or invents a threshold is worse than a blank page, because it looks finished.

So the question we set ourselves was not "can AI write a policy?" but "can a compliance officer defend every sentence of an AI-assisted draft to an inspector?" That led to five rules.

1. The right regulator only. Before any text is retrieved, the drafting request is scoped to the entity's own jurisdictions. A verbatim quote from the wrong regulator is a failure that a citation check alone cannot catch, so we stop it upstream.

2. Binding text first. Consultation papers, press releases and FAQs can inform a draft, but only binding instruments can be cited as obligations. Our corpus marks every instrument accordingly.

3. Cite verbatim or stay silent. Every sentence that states a regulatory requirement must carry a quote that is an exact match to the source clause. If the quote does not validate, the sentence is removed, not softened.

4. Separate the regulator's words from the firm's choices. Each sentence in a draft is tagged by where it came from: regulator-derived (with its citation), entity fact (from the profile) or firm choice (a decision the business makes, such as a threshold stricter than the regulatory minimum). Approvers can see the tags. An inspector asking "is this your choice or the rule?" gets an immediate answer.

5. Never invent a fact. Who is the MLRO? Which screening provider do you use? What triggers enhanced due diligence in your business? The AI does not guess. It leaves a typed placeholder, and a draft cannot go for approval while a required placeholder is empty. A short, pre-filled interview collects these facts before drafting begins.

The workflow itself is deliberately staged. The register proposes an outline from the mandate's required contents. You adjust it. Only then are sections drafted, one at a time, and each arrives already mapped to the obligations it is meant to cover, so you see its coverage the moment it is written.

Bringing the policies you already have

Most firms are not starting from zero. An established entity may hold 20 to 60 policies and procedures of varying age and quality, and it has no appetite for rewriting them.

The register takes them as they are. Upload a PDF, Word file or text (scanned pages included) and it is broken into sections along its own headings, then mapped against every obligation that applies to the entity. Within minutes you get a gap report: which obligations are fully covered, which only partly, which not at all, and which sections still refer to instruments the regulator has since replaced.

From there, the register can propose new sections to close specific gaps, drafted under the same rules as above and placed in a draft version alongside your original. Your existing wording stays yours; the proposals sit next to it for review.

This is often the most valuable first step for an established firm. It turns "we think our policies are fine" into a clause-by-clause answer.

Nothing goes live without a named human

No draft, whether written by a person, proposed by AI or triggered by a rule change, becomes the effective policy on its own. Every version passes through compliance review and then a named approver. The author of a version cannot approve it.

The approval route follows the regulator's own requirement. Where a mandate calls for board approval, the version needs the board resolution attached as evidence. Where senior management approval is enough, a named sign-off is recorded. Approvers see a one-page summary of what changed, why, and which rule required it, rather than a 40-page redline.

Approval sets an effective date, which can be in the future. Earlier versions are kept, so the register can answer a question inspectors ask often and firms struggle with: what did our policy say on a given date? Every state change is written to a tamper-evident audit log.

Staying current as the rules move

A policy set is never finished. The register watches for the events that should reopen a policy and routes each one into a single upgrade inbox:

• A regulatory change. When an obligation is added, amended or withdrawn, the sections mapped to it are flagged and re-assessed, and an upgrade is opened with a due date ahead of the rule's effective date.
• A review falling due. Each policy carries the cadence its mandate requires, and the review opens before the deadline, not after.
• A gap. If a re-assessment finds an obligation no longer covered, the policy that should cover it is reopened.
• A change in the business. New activities, customer types or markets update the blueprint.
• An outdated reference. A section citing an instrument that has been superseded is flagged for review.

Because mapping happens per section, an upgrade redrafts only the sections affected. The rest of the policy, and its approval history, is untouched.

What an inspector sees

The test of any policy register is the inspection. The register produces a policy pack for any approved version: the policy itself, an appendix tracing each applicable obligation to the section that addresses it with the verbatim clause, the full version history, the approval evidence and an audit extract, sealed with a cryptographic hash.

The conversation with the inspector changes as a result. Instead of "let me find the person who wrote this", it becomes "here is the clause, here is our section, here is who approved it and when".

What comes next

The Policy Register is being built in stages, starting with the foundations (stable policy identity, section-level structure and the approval workflow), then the blueprint and AI-assisted drafting, then continuous monitoring and inspection-ready exports.

Two further pieces follow. Groups operating in several jurisdictions, for example an IFSC entity alongside MAS and FCA-regulated affiliates, will be able to maintain one group policy with local addenda only where a regulator's requirements differ. And the register is designed to feed a sister product, a compliance dashboard that will present coverage, review schedules and regulatory exposure across the whole programme. That dashboard is not part of this release, but the register is being built as its system of record from day one.

The point

Policies exist to meet obligations. A policy register should therefore know, sentence by sentence, which obligation each part of a policy meets, where that obligation came from, who decided the rest, and when it last changed. That is the register we are building.

If you run compliance at a regulated entity, particularly a new licensee in GIFT City or Singapore, and want to see how your current policy set maps against your regulator's obligations, we would welcome the conversation.