A compliance rules engine, in investment management, is the module of the order and portfolio management system that tests each order before it goes to the trading desk and every portfolio after the close against coded investment rules, then warns, asks for a comment, routes for approval or blocks. It is fast, consistent and auditable, and it knows nothing about where its rules came from. The engine cannot read an investment management agreement, a prospectus or a German side letter; someone must turn each clause into parameters, and someone else must prove the parameters mean what the clause means. That is the gap Botminds' Compliance Rule Coding fills: its agents draft every rule with each element cited to its clause, a second agent reads the clause again without seeing the draft, a third tests both readings on real holdings, and people decide, check and release before anything reaches your engine.
The regulator findings on this page are linked where they appear. Product screens show the solution's fictional sample firm.
What an investment compliance engine looks like at five managers
5 of 5
managers inspected configure their limits in a module of the order or portfolio management system
4
severity levels for a pre-trade rule, from an after-the-fact alert to a block that cannot be overridden
20–64%
of each manager’s ratios came ready-made from the tool’s publisher; the rest were built in-house
75%
of active ratios at one manager carry an early-warning level before the limit
What is a compliance rules engine?
A compliance rules engine is software that evaluates transactions and positions against a library of coded rules and records the result. In investment compliance it usually sits inside the order management system, so that the same positions the portfolio manager sees are the ones the rule tests. The French market regulator found exactly that set-up at the five managers it inspected: the limits are configured "in a dedicated OMS/PMS module", bought from a vendor at four of them and built in-house at the fifth (AMF SPOT summary, section 4.1.2).
Each rule in the engine is a small program: a scope (which portfolios and which holdings), a numerator and a denominator, a data field that classifies each holding, a limit with a comparison, a warning level, and a timing. The engine is very good at evaluating that program thousands of times a day. It has no view on whether the program is the right one.
Rules engine compliance check: pre-trade, post-trade and the second line
The engine checks at two moments, and the checks catch different failures. Before the trade, it tests the order's effect on the portfolio; after the close, it tests the portfolio as valued. The AMF describes a chain of up to seven controls: the manager's own simulation, an automatic check when the order goes to the desk, at two managers a second automatic check before the desk sends it to brokers, the risk team's daily post-trade review, a manual check by managers at two firms, the fund valuer's check at each net asset value, and the depositary's (AMF SPOT summary, section 4.3.3).
Post-trade checks catch what pre-trade cannot. One manager named three causes of excesses found only after the trade, besides configuration errors: prices moving between order and execution, management fee accruals reaching the order system a day after the accounts, and differences in what the manager and the valuer could see of the orders. All three are reasons a pre-trade pass is not proof a rule is right; none of them is a reason to trust a rule nobody has tested.
Rules engine compliance policy: what a rule does when it fires
The policy side of an engine is the severity each rule carries. Four of the five French managers wrote down four levels, of increasing severity: the order goes through and risk control is alerted afterwards; the manager may proceed but must comment; the manager must comment and risk control must approve before the desk receives it; or the system blocks the order "with no possibility of overriding it" (AMF SPOT summary, section 4.2.1). The AMF noted that the top level "is used sparingly", and one manager explained why: blocking everything would inflate alerts and slow every order, because the order system's view of cash and positions differs from the accounting view during the day.
One manager added an early-warning level, configured for 75% of its active ratios, that tells the manager before the order that the portfolio will sit close to a threshold afterwards. That is a coding decision as much as a policy one: every rule needs its warning level set, and the level should be a deliberate fraction of the limit, not a default.
What the engine cannot do: read the documents
An engine starts from a library, not from your clients' documents. The AMF asked the five managers how many of their ratios came ready-made from the tool's publisher; the answers were 22%, 54%, 20% and 64% at the four that could say, and "the other ratios had to be developed separately". It added that the publisher "provides no guarantee that the ratios proposed are exhaustive, or that they comply with the latest regulatory developments" (AMF SPOT summary, section 4.3.1). Even the regulatory rules need checking, and every client and fund rule needs writing.
The written rules are where the errors live. At one inspected manager, nine of the ten excesses that led to compensation payments traced back to a pre-trade control that was missing or set up wrongly, such as a ban on exchange-traded commodities (section 4.3.5). A missing rule and a wrong rule look the same from the engine's side: silence.
Compliance rule testing tool: why the writer must not be the tester
A compliance rule testing tool is only as independent as the person, or agent, who decides what it tests. Whoever coded a rule tests it with the reading already in their head: they build the cases they thought of while coding and confirm the rule does what they meant. The cases that matter are the ones they did not think of. That is why separating the person who configures a limit from the person who verifies it is the minimum, and why the AMF listed creating or changing ratios without a four-eyes check among its poor practices (AMF SPOT summary, section 4.3.6); who checks coded rules covers what the checker should see.
Agents make a stronger separation affordable. A second reader can read every clause from scratch, on a different model, without access to the first draft, and write its own rule. Where the two rules agree, a person still checks; where they differ, the difference is the most useful output of the whole exercise, because it marks exactly the clauses with two plausible meanings.
Three ways to get rules into the engine
Coded by hand, checked by a colleague: The analyst, once; the checker usually sees the rule, not the clause
Drafted and read twice by agents, decided and signed by people: Two agents independently, on different models; the analyst and the checker see the clause, both readings and the citations
Coded by hand, checked by a colleague: Whoever happens to notice it
Drafted and read twice by agents, decided and signed by people: The disagreement between the two readings, put to the analyst side by side
Coded by hand, checked by a colleague: The coder, if time allows, often on today’s portfolio only
Drafted and read twice by agents, decided and signed by people: A separate tester: at least six edge cases from the clause’s own words and a 12-month back-test of each reading
Coded by hand, checked by a colleague: The coder, implicitly, by what they type
Drafted and read twice by agents, decided and signed by people: The analyst, explicitly, with a reason code; the agent never resolves a disagreement
Coded by hand, checked by a colleague: A checker; release rules vary
Drafted and read twice by agents, decided and signed by people: A senior officer who did not code or decide the rule; the Head of Investment Compliance for packages over 25 rules
Coded by hand, checked by a colleague: Spreadsheet, emails and the engine’s change log
Drafted and read twice by agents, decided and signed by people: One audit trail with every step, decision and signature, exportable with a hash manifest
How do you test a compliance rule before it goes live?
Test it three ways before it touches production: against cases built from the clause's own words, against a year of real holdings, and in the engine's test environment against what is already live. Each catches a different error. Edge cases catch a wrong boundary or a missed exception; the back-test catches a wrong reading by showing the days each reading would have fired; the dry-run catches a rule that compiles differently in the engine from how it reads on paper, or that collides with a rule already in production.
Three tests before a rule loads, and what each one catches
| Test | What it runs | What it catches | Example from the sample mandate |
|---|---|---|---|
| Edge cases | Small portfolios built from the clause’s words: exactly at the limit, just over, each exception, each defined term | Wrong operator, missing carve-out, a term mapped to the wrong data field | Emerging weight exactly 10.00% allowed ("nicht überschreiten"); a Cayman-incorporated issuer with China as country of risk must count |
| Back-test | Twelve months of holdings under each reading | A reading that would have fired on days the client never considered breaches, or stayed silent on real ones | The literal reading: three days over 10% in March 2026; the defined term: none |
| Dry-run and comparison | The package compiled in the engine’s test environment, run on the current portfolio and compared with production | Compilation differences, collisions with live rules, unexpected warnings | 40 engine rules and one manual control; 0 breaches; one warning at 8.7% against an 8.5% warning level; 41 new, 0 changed |
The checker sees the clause, the decision and the tests before signing
Can AI code compliance rules?
It can draft them, read them a second time and test them; whether a firm should let it decide or load them is a different question, and the regulators' answer is that the obligations do not change with the tool. The SEC's examiners report that firms already apply what they call "super intelligence (SI)" to coding and compliance monitoring, and their priorities hold a rule coded with such a tool to the same duties as one coded by hand (SEC Division of Examinations, Fiscal Year 2027 priorities, October 23, 2026). FINRA has said the same of its own rules, which it intends to be technologically neutral (FINRA Regulatory Notice 24-09).
For rule coding the obligation is concrete: written procedures "reasonably designed to prevent violation" and an annual review of their effectiveness (Rule 206(4)-7). A design in which an agent's reading becomes a live rule without a person deciding and another person checking is hard to defend under that standard. A design in which agents do the reading, drafting and testing, and every interpretation, signature and release stays with named people, is easier to defend than coding by hand, because each step leaves evidence that hand-coding rarely keeps.
Writer, reader, tester, decider, checker: one rule through Compliance Rule Coding
Agent
Coding agent (writer)Drafts the rule in plain English and engine parameters, every element cited to its clause, with its confidence.
Never: Loads a rule or resolves a disagreement
Agent
Reading agent (second reader)Reads the clause again on a different model family with no access to the draft, and writes its own rule.
Never: Sees the writer’s draft
Agent
Tester agentBuilds edge cases from the clause’s words and back-tests each reading over 12 months of holdings.
Never: Marks a rule tested with fewer than six edge cases
A person decides
Rule analyst (decider)Chooses or edits a reading where the readers differ, with a reason code; sends agreed, passing rules to the checker.
A person decides
Senior compliance officer (checker)Checks clause, decision and tests against a four-point checklist; signs or returns with a reason.
Agent
Load agentBuilds the package, dry-runs it in the engine’s test environment, compares it with production, loads after release and verifies the first checks.
Never: Loads without a checker’s signature and a release
What is maker-checker in compliance?
Maker-checker means one person makes a change and a different person checks it before it takes effect, so no single person can alter a control unseen. In rule coding the maker codes or decides the rule and the checker signs it; good practice adds that the checker sees the source clause, not only the coded result, and that the system, not goodwill, prevents a maker from checking their own work.
The AMF's findings show both halves. It praised separating the people who configure limits from those who monitor compliance with them, and an automatic audit trail of every creation or change in the control tool; it flagged one manager where the same person configured the limits and supervised the results (AMF SPOT summary, sections 4.1 and 4.3).
Where Compliance Rule Coding fits, and where it does not
The solution sits in front of the compliance engine you already run, not in place of it. It reads the documents, drafts and tests the rules, gathers the decisions and signatures, and hands a package to the engine's test environment, then to production after release. The engine keeps doing what it does well: checking every order and every portfolio, every day.
It is not the right purchase in three situations. If your engine has no test environment or no way to load a package, the dry-run and comparison steps lose most of their value. If your mandates are few, short and standard, with no side letters or foreign-language documents, the reading problem the agents solve is small. And if the pain is investigating alerts rather than coding rules, the work belongs to post-trade compliance software, or, for questions before an order, to a pre-trade compliance solution.
A package's path to production: compiled, dry-run, compared, signed, released
Questions to ask of any compliance rule coding or testing tool
- Does every rule element cite its clause?
Scope, numerator, denominator, data field and limit, each to the words they came from, in the original language.
- Is the second reading independent?
A different reader, without the first draft; ideally a different model for agents.
- Who resolves a disagreement?
It should always be a named person with a reason, never the tool.
- What does "tested" mean, in numbers?
Minimum edge cases, back-test window, and whether both readings are run.
- Can the maker check their own rule?
The system should block it, not a policy document.
- Does it dry-run in your engine and compare with production?
A rule that reads right can still compile differently.
- What evidence can it export, and can it prove nothing changed?
One rule or one mandate end to end, with a manifest.
- How are its own versions controlled?
Which agent and model drafted each rule, and what has to pass before a new version goes live.
How to read the back-test that sits at the centre of the testing step is the subject of backtesting compliance rules; how to run a pilot that tells you whether a tool earns your coders' trust is investment compliance testing tools. To see the writer, reader and tester at work on sample mandates, start from Compliance Rule Coding.
Questions people ask
Is a compliance rules engine the same as an order management system?
Usually it is a module of one. All five managers the AMF inspected configured their limits in a dedicated module of the order or portfolio management system, so that pre-trade checks run on the positions the portfolio manager sees. Some firms run a separate post-trade engine fed by the accounting system.
Should every compliance rule block the trade?
No. Managers set a severity per rule, from an after-the-fact alert to a hard block, and the AMF found the hard block used sparingly because intraday positions in the order system differ from the accounting view. The severity should follow the limit's kind: a fundamental policy or a client exclusion list deserves a block; an internal soft limit may only warn.
What is an early-warning level in a compliance rule?
A threshold below the limit at which the engine warns before a breach. One AMF-inspected manager set one on 75% of its active ratios; the solution's sample settings warn at 85% of each limit, so a 10% cap warns at 8.5%.
How many edge cases should a coded rule be tested with?
Enough to exercise the boundary, each exception and each defined term; no regulator sets a number. The solution's sample settings require at least six before a rule counts as tested, and its sample emerging-markets rule carried eight.
Who is responsible if a rule an agent drafted is wrong?
The firm, as with any rule. That is why the agent's draft is never the rule of record: the analyst decides each interpretation, a different officer signs, and the audit trail shows which agent version drafted it, who chose the reading and who signed.