Investment Compliance Rules Engine Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does the size of the rule library get underestimated so badly?

Every project of this kind starts with a number that is wrong. Somebody counts the mandates, multiplies by an assumed number of limits per mandate, and produces a figure that feels manageable. The figure is wrong because guidelines that read like the same rule are different rules.

One client caps a single issuer at 10 percent. Another writes the same sentence but measures at trade date rather than settlement date, excludes cash and cash equivalents from the denominator, and treats agency paper differently from sovereign debt. A third writes their limit against a benchmark weight plus a band, which means the rule needs a live benchmark feed and a policy for what happens when the index rebalances. A fourth adds an exclusion list defined by a revenue threshold in a business activity, which requires third party data and a classification decision you have to be able to defend to that client. Four rules, one sentence.

In our experience mid sized institutional managers accumulate hundreds to low thousands of active rules and nobody in the firm can list them from memory. The scope failure is not that the number is large, it is that the count is done from mandate documents rather than from the distinct evaluations required.

The fix is to scope by rule category by frequency, not by client. In most firms concentration, liquidity, credit quality and restricted list rules cover the large majority of active limits. Build those four categories properly, prove the pattern against live orders, and let everything else follow the same shape. A project scoped as all mandates by a date will slip. A project scoped as the four categories that carry most of the risk will ship and then absorb the tail.

What goes wrong when you migrate an existing rule library?

Treating rule migration as a data import is the single most reliable way to carry old errors into a new system with a fresh coat of confidence. The old syntax encodes assumptions nobody wrote down: which denominator was used, whether the measurement was trade date or settlement date, what happened when a rating was missing, whether a rule was suspended years ago and never removed.

Copy those across mechanically and you get a library that evaluates cleanly and is wrong in exactly the places the old one was wrong, with the added problem that nobody now remembers which rules were approximations supplemented by a manual procedure. Those approximations are where breaches hide, and a migration is the one opportunity you get to surface them.

The fix is re-expression with parallel running. Re-write each rule from the source clause in the investment management agreement, not from the old system's syntax, and link the new rule to that clause. Then run both engines against live orders for several weeks and investigate every disagreement. Each disagreement is either a defect in the new rule or an undocumented assumption in the old one, and both are findings worth having. Expect the parallel period to take longer than the migration itself, and treat any pressure to shorten it as a risk decision rather than a schedule decision.

One related trap: firms frequently discover during this exercise that a meaningful share of their library is dead, either rules for terminated mandates or duplicated rules created for accounts that no longer exist. Clean that up during re-expression rather than migrating it, because every dead rule is future evaluation cost and future confusion.

Why do order and market data integrations break after launch?

A compliance engine is only as current as its inputs, and it has more inputs than most systems. Positions and today's executions from the order management system, pending allocations, corporate actions, prices, credit ratings, sector and industry classifications, benchmark constituents and weights, and whatever business involvement screens your clients have specified.

These break quietly rather than loudly. A ratings provider changes a code value and rules referencing that rating stop matching. A benchmark provider changes a file layout at a rebalance. A corporate action feed misses an event type. An order management system upgrade alters the staging interface, and the pre trade check starts evaluating against a position view missing today's fills. In every case the engine keeps returning results, which is worse than failing, because a confident pass is trusted.

The fix is to treat every input as a monitored contract. Freshness checks with alerts, expected record counts, and a match rate on identifiers measured on every run. Then make coverage explicit: if a rule references data that did not arrive, the evaluation must say so rather than proceeding on the last known value. Store every evaluation with the version of each input it used, so a question three months later about how an order passed can be answered from the record instead of reconstructed. And when scoping, name the systems: a Charles River order feed, an Eze staging interface and a Bloomberg AIM connection are three different projects, not one line item.

What happens when missing data and look through are not covered?

Two gaps account for most of the breaches that get through a system that is otherwise working.

The first is missing data policy. Every engine eventually evaluates a rule where one input is unavailable. A rating is not yet published for a new issue, a classification is absent for a recently listed name, a benchmark weight has not arrived. The dangerous default is silently passing, because it produces no signal and no record. The policy has to be explicit per rule, one of fail open, fail closed, or flag for review before release, and it has to be defensible to the client whose guideline it implements. It also has to be recorded: the evaluation ran, this input was missing, this policy applied.

The second is look through. A total return swap on an index is not one position, and a sector limit has to see through it. The same applies to exchange traded fund holdings, fund of fund structures and derivative overlays, where notional, delta adjusted and market value exposure give three different answers depending on the wording of the specific guideline. Fund derivative rules under Rule 18f-4 changed how registered funds must address the risk arising from derivatives use, and a UCITS mandate carries its own concentration structure measured differently again.

The fix is to compute exposure per rule rather than storing one number per position. The same holding then contributes different amounts to a notional limit and a market value limit without anyone maintaining two position sets. The choice of exposure measure per rule is your policy, documented and versioned, which is also the answer you give when a client asks how their limit is measured.

Should you build custom or configure what you already own?

Plenty of firms should not build this. If you run a single strategy with near identical mandates, your instrument universe is cash equities and government bonds, and the compliance module in the order management system you already pay for expresses most of your rules without manual supplements, configure that and spend the money elsewhere. That describes a lot of managers and there is nothing embarrassing about it.

Charles River has one of the most complete rule libraries in the market, and if you already run it as your order management system its compliance module is often the correct call. Aladdin's strength is the risk and analytics stack it sits inside. SS and C Eze, Bloomberg AIM and SimCorp all ship credible compliance capability. These are serious products and the honest recommendation for many readers is to use one properly rather than to build.

The test that decides it is not a feature comparison. It is this: count how many of your active guidelines are expressed in your current module as an approximation plus a manual procedure. If that number is small, configure. If it is material, you are already running a partly manual compliance function while paying for an automated one, and the approximations are where your breaches will come from.

Build when your rule library is genuinely bespoke and growing with every mandate, when derivative or fund look through matters to your limits, when you run more than one order management system and need a single consistent compliance view, or when you intend to change order management system and do not want your rule library held inside the one you are leaving.

How do hidden costs get into the quote?

• Instrument coverage. Each derivative type needs its own exposure model. A quote written for cash equities and bonds is not a quote for a book with swaps and options.
• Data dependencies. Every rule referencing credit ratings, benchmark weights, sector classifications or business involvement screens requires a feed, a licence and a missing data policy. This is a surprisingly large design conversation and it is regularly priced as if it were plumbing.
• Latency. Sub second evaluation across a block spanning hundreds or thousands of accounts is a different architecture from a five second one. Decide the number before design, because it cannot be tuned in afterwards.
• Rule library migration. Re-expression plus parallel running, not an import. Frequently the largest single line and frequently the one omitted.
• Order side integration. Named per system. Three order management systems means three integration projects.

The fix is a paid discovery on your own material. Hand over three real guideline clauses, one of them awkward, plus a list of your instrument types and your current data feeds, and price the build against what comes back. A developer who has done this will ask what the denominator is, whether measurement is trade date or settlement date, and what happens when a rating is missing. One who calls it a simple percentage check has not built this before.

What separates a build that works from one that fails here?

Four habits show up in every engine that survives an operational due diligence review.

The first is speed treated as a correctness requirement. A check that takes several seconds gets routed around, and a bypassed control is worse than no control because it creates a record suggesting coverage that did not happen. The pattern that works is an in memory position and exposure state kept current with today's executions and pending allocations, rules compiled rather than interpreted, and per account evaluation run in parallel across the block.

The second is returning headroom rather than a verdict. A pre trade result showing which specific accounts fail, by how much, and what order size would pass is something a trader can act on. A binary block is a wall, and walls get climbed.

The third is retaining every evaluation, passes included. Firms that store only breaches can prove they caught problems and cannot prove coverage, and coverage is what consultants ask about. Full retention also answers a question most firms cannot answer today, which is how often a given rule actually fires and whether it is doing anything.

The fourth is versioning with an owner. Every rule needs an effective date, an approver, a link to the source clause, and a full evaluation history, so that when a client asks why their portfolio held a position in April, you can state what the rule was in April, who approved it and what the exception state was.

Finally, settle ownership before kickoff. The rule library is the codified version of what you promised clients in their investment management agreements, so it is both intellectual property and the evidence of your control environment. You should own the repository, the infrastructure accounts and the right to hire anyone else. At Digital Heroes the client owns the code from the first commit, and in this category being locked out of your own rules is usually the problem that started the conversation.