Regulatory Change Management Software: How Do You Prove a New Rule Reached the Right Control and the Right Owner?

Everyone buys the feed and thinks they bought change management

Here is the shape of the problem at almost every bank, insurer and asset manager we have worked with. Somebody bought a regulatory intelligence subscription. It works. Every morning it delivers between forty and four hundred items across the regulators that matter to the firm. An analyst opens the digest, reads down it, and makes a series of judgement calls: not us, not us, possibly us, definitely us, and forwards the last two to a business line lead with a short note. The note goes to an inbox. Sometimes there is a reply. Sometimes the reply says it is being handled. Frequently that is the last recorded event in the life of that obligation.

Eighteen months later a supervisor asks how the firm identified a particular requirement, who assessed it, what changed as a result, and how the firm knows the change is working. The honest answer is that the assessment happened in a conversation and the evidence is in an archived mailbox belonging to someone who has since moved to a different department.

That is the failure. Not missing the rule, which is rare. Failing to demonstrate the chain from the rule to a control that somebody owns and somebody tests.

What the vendors do well, and where the gap opens

Thomson Reuters Regulatory Intelligence and Wolters Kluwer OneSumX are strong at sourcing: monitoring regulators across jurisdictions, normalising publications, tagging them and alerting. Corlytics brings enforcement analytics and a serious taxonomy. Ascent works on generating obligations from rule text. RegEd is strong in the licensing, registration and distribution compliance space.

None of them knows your firm. They do not know that your Luxembourg entity holds one licence and your Singapore branch holds another, that you exited retail mortgages in 2023, that your outsourced fund accounting sits with a particular administrator, or that control OP-114 in your register is the one that would have to change. That knowledge is your firm's own model of itself, and building it is the entire value of the exercise. Firms that skip it end up with an excellent feed and a SharePoint folder, which is where this category earns its bad reputation.

One caution before spending anything: if you already own an enterprise governance, risk and compliance platform, check whether your obligation register and control library can live inside it. Sometimes they can, and the build reduces to an ingestion and applicability layer. That is a much smaller project and we will tell you when we think it is the right one.

Problem one: relevance is a function of your footprint

Most alerts are irrelevant to most firms, and the analyst's real skill is filtering. But filtering is not a personal talent, it is a lookup against facts the firm already knows: which legal entities exist, in which jurisdictions, holding which licences and permissions, offering which products through which channels to which customer types.

What a custom build does: model that footprint explicitly, as data, with effective dates, because footprints change and a rule that did not apply to you in 2024 may apply now. Applicability rules then evaluate every inbound publication against the footprint, so an item arrives already scoped to the entities and product lines it touches, with a proposed owner. The analyst is reviewing a proposal rather than starting from a blank page. This is also the only durable defence against the analyst who quits: their filtering logic becomes rules that survive them.

Problem two: an obligation register in Excel is stale the week it is written

Firms build obligation registers as one off projects, usually after a finding. A consultant reads the rulebook, produces two thousand rows, and the register is accurate for about a month. Then a rule changes and there is no mechanism connecting the change to the row.

What a custom build does: make the obligation the unit of work, versioned, with a citation to the source text and a many to many mapping to controls, policies, procedures, systems and owners. When a publication amends the source, the affected obligations are identified by citation and every control mapped to them appears on a work list automatically. The question a board asks, which controls would have to change if this rule changes, becomes a query rather than a project. That single capability is usually what justifies the budget.

Problem three: rules have states, not dates

A discussion paper becomes a consultation, becomes a final rule with a publication date, an effective date, sometimes a transition period, sometimes a phased application by firm size. Teams assess at consultation, feel productive, and then get caught by an effective date eighteen months later that nobody diarised.

What a custom build does: model the lifecycle as states with dated transitions, and generate forward dated work items from the effective date rather than the publication date. Readiness reporting then answers the useful question, which is not what happened this month but what becomes enforceable in the next two quarters and whether the implementation work is on track. Firms consistently underestimate how much value sits in this one feature, because the assessment is the visible work and the effective date is what actually catches people.

Problem four: the same theme arrives five times

Operational resilience, third party risk, consumer outcomes, financial crime controls. A firm operating across several jurisdictions will meet the same underlying theme from multiple regulators over a period of years, each with its own terminology and its own timetable. Analysts do the work five times and the firm ends up with five overlapping control sets.

What a custom build does: cluster publications by theme against your own internal taxonomy, so a new requirement surfaces alongside the obligations you already hold on that theme and the controls that already exist. The output is not less work, it is better sequencing: you find out that a control built for one jurisdiction covers eighty percent of what another now demands, and the gap analysis starts from something rather than nothing.

Where machine learning genuinely helps here

Three specific jobs, and no more. First, relevance scoring trained on your own historical dispositions, so the model learns what your firm has previously judged not applicable and why, and surfaces its confidence rather than silently discarding. Second, obligation extraction: converting a section of rule text into candidate atomic obligations for a compliance officer to accept, edit or reject, which turns days of drafting into hours of reviewing. Third, similarity matching between a new requirement and your existing obligation and control library.

All three produce drafts. None of them makes a determination. Every disposition carries a human name and, importantly, the record should store both what the model proposed and what the human decided, because that is what lets you evidence oversight of the model itself when the supervisor asks about it, which they now do.

What it costs and how long it takes

Across the 2,000 plus projects Digital Heroes has delivered, this category is one of the more predictable. A first release covering the footprint model, the versioned obligation register, mapping to controls and policies, ingestion of one or two regulatory feeds and the assessment and implementation workflow runs $60,000 to $130,000 and ships in 10 to 16 weeks. A full platform adding multiple jurisdictions with a shared theme taxonomy, lifecycle state tracking, attestation cycles, policy library integration, committee and board reporting and an examination evidence pack runs $150,000 to $350,000 across 6 to 10 months.

What moves the number: the number of jurisdictions and legal entities, because applicability logic scales with the footprint. Whether you have an existing control library in usable condition, which is frequently the real constraint. Integration with a policy management system or an existing governance platform. Languages, if you operate where rules are published in more than one. And the initial obligation register build, which is compliance work rather than engineering work and should be resourced and timetabled as such rather than assumed to be free.

When you should not build this

Do not build if you operate in one jurisdiction, hold one licence, and your compliance function is small enough that everyone already knows what is coming. A subscription, a shared register and disciplined meeting minutes is a proportionate answer and a supervisor will accept it.

Do not build the feed under any circumstances. Scraping regulators is a maintenance liability with no upside, and the commercial feeds are good.

Build when two or more of these are true. You operate across multiple jurisdictions or legal entities with different permissions. Your obligation register exists but nobody trusts it. You have had a supervisory finding or an internal audit issue on regulatory change management, which is the most common trigger by a wide margin. Your assessment trail lives in email. Or your firm is growing by acquisition, which means the footprint changes faster than any manual process can track.

How to choose a developer for regulatory change software

Ask them to draw the model: regulator, publication, lifecycle state, obligation with citation and version, footprint dimensions, control, policy, owner, assessment, implementation task, test, attestation. If they draw a document management system with a workflow on top, they have misunderstood the problem entirely.

Ask what happens to the controls mapped to an obligation when that obligation is superseded by an amended version. The answer should involve version linkage and a review work item, not a silent remap. Getting this wrong is how registers quietly rot.

Ask how they will handle a requirement that is assessed today and becomes enforceable in eighteen months. If forward dated work generation is not part of the answer, the system will help you assess and fail to help you comply.

Ask who owns the code and settle it in writing before kickoff. You should hold the repository, the infrastructure accounts and the right to hire anyone else. At Digital Heroes the client owns it from the first commit. This system is the evidence you hand a supervisor, and evidence you cannot access on your own terms is not evidence at all.