Investment Compliance Rules Engine Software: How Do You Turn a Negotiated IMA Into a Rule That Blocks the Order?

The breach nobody sees until settlement

A portfolio manager stages a block across 40 accounts at 10:15am. The order passes because the check ran on yesterday's positions. Overnight, a corporate action converted a holding in eleven of those accounts, and one client's investment management agreement caps a single issuer at 5 percent of market value including securities convertible into that issuer. On paper the account is now at 5.4 percent. Nobody knows until the post trade sweep runs at 7pm, and by then the trade is done. The remediation conversation with the client starts with an apology and frequently ends with the manager making the client whole for the loss.

That is what this software is for. Not reporting, not dashboards. Stopping an order that should not go, and proving afterwards that everything else that went was allowed.

The reason compliance heads treat this as strategic spend is that guideline coverage is now a condition of winning institutional mandates. Consultants ask about it during due diligence. Clients ask for evidence in operational reviews. A firm that cannot demonstrate pre trade coverage of the guidelines it signed is not competing for the same money.

Why guidelines resist automation

An investment management agreement is a negotiated document. The limits inside it were argued over. One client says no more than 10 percent in any single issuer. Another says the same thing but measures at trade date rather than settlement date, excludes cash and cash equivalents from the denominator, and treats government 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. A fourth includes an exclusion list of companies by revenue threshold in a business activity, which requires third party data and a classification decision you have to be able to defend.

Every one of those is a different rule even though they read like the same rule. Multiply by every mandate you win. 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 rule library becomes the firm's institutional knowledge, and it is usually stored inside a vendor platform in a form nobody can read outside that platform.

What the incumbents actually do well, and where they stop

Charles River IMS, BlackRock Aladdin, SS and C Eze, Bloomberg AIM and SimCorp all ship credible compliance modules. Charles River in particular has one of the most complete rule libraries in the market and if you already run it as your order management system, using its compliance module is often the correct call. Aladdin's strength is the risk and analytics stack around it. These are serious products.

Where they stop is threefold. First, rule expression. Each platform has its own rule syntax and its own model of an instrument, an account and a limit, and guidelines that do not map cleanly get expressed as an approximation plus a manual procedure. The approximation is where breaches hide. Second, look through. Derivative exposure, fund of fund holdings and structured products need to be decomposed into underlying exposure before a limit is meaningful, and the decomposition depends on your data and your policy, not the vendor's. Third, portability. Your rule library is your intellectual property and your evidence of control, and inside a vendor platform it is neither readable nor movable. Firms discover this when they change order management systems and are quoted a rewrite of the entire library.

Problem one: pre trade has to be fast and correct at the same time

A pre trade check that takes eight seconds gets bypassed. A check that runs on stale positions gives false comfort. The engineering requirement is a check against a live position view that includes today's executions, pending allocations, and known corporate actions, evaluated across every affected account in the block within the time a trader will tolerate, which is well under a second.

That is achievable and it is a design decision, not a tuning exercise. The pattern that works is an in memory position and exposure state kept current from the order management system and the accounting feed, with rules compiled rather than interpreted, and per account evaluation parallelised across the block. Firms that build this get something the vendor modules rarely give them: a pre trade result that shows which specific accounts fail, by how much, and what order size would pass. Traders use that. A binary block is a wall, a number is a decision.

Problem two: rules need version history and an owner

When a client asks why their portfolio held a position that appears to breach their guideline in April, the answer requires knowing what the rule was in April, who approved it, and what the exception state was. Most firms cannot answer that quickly because rules are edited in place.

A build has to treat every rule as versioned with an effective date, an approver, a link to the clause in the source document it implements, and a full history of evaluations. That last item matters more than firms expect: storing every pre trade decision, pass and fail, means an operational due diligence review becomes an export rather than a fire drill. It also lets you answer a question nobody can currently answer, which is how often a given rule actually fires and whether it is doing anything.

Problem three: look through, and the limits that need outside data

A total return swap on an index is not one position. A limit on financial sector exposure has to see through it. The same goes for 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 what the guideline says. The fund derivative rules under Rule 18f-4 changed how registered funds handle leverage risk, and a UCITS mandate carries its own concentration structure that is measured differently again.

The look through logic and the choice of exposure measure per rule is manager specific policy, which is precisely why this is hard to buy. A custom engine models exposure as a computed function per rule rather than a single number on a position, so the same holding contributes different amounts to a notional limit and a market value limit without anyone maintaining two position sets.

What a first release must contain

• A rule authoring surface that a compliance analyst can use without a developer, with rules versioned, effective dated and linked to the source clause.
• Pre trade evaluation against live positions including today's activity, returning per account results with headroom, not just pass or fail.
• Post trade end of day sweeps with passive breach detection, so a limit crossed by market movement rather than by a trade is identified and classified correctly.
• A breach workflow with severity, ownership, remediation plan, deadline and sign off, retained immutably.
• Exposure computation with look through for derivatives and funds, configurable per rule.
• A what if mode so a portfolio manager can test a hypothetical order before staging it.
• Client reporting and attestation output generated from the same evidence store.

Cost, timeline and what drives them

A first release with authoring, pre trade, post trade and breach workflow runs $90,000 to $200,000 over 14 to 20 weeks. The full platform with look through, what if, attestation and regulatory limits reaches $250,000 to $600,000 across 9 to 15 months.

What increases cost: instrument coverage, and specifically derivatives, because each instrument type needs an exposure model. Number of data dependencies, since rules referencing credit ratings, benchmark weights, sector classifications or business involvement screens each require a vendor feed and a fallback policy for missing data, which is a surprisingly large design conversation. Latency requirements, since sub second evaluation across a thousand account block is a different architecture from a five second one. And migration of an existing rule library, which is not a data import but a re expression exercise, because the old syntax encoded assumptions nobody wrote down.

What reduces it: starting with your top rule categories by frequency rather than by client. In most firms concentration, liquidity, credit quality and restricted list rules cover the large majority of active limits, and proving those first lets everything else follow the same pattern.

When buying is the right call

Use the module you already have if you run a single strategy with near identical mandates, if your instrument universe is cash equities and government bonds, and if your order management system's compliance module already expresses most of your rules without manual supplements. That describes a lot of firms and there is no shame in it.

Build when your rule library is genuinely bespoke and growing with every mandate, when you supplement the vendor module with manual procedures because rules do not map cleanly, when derivative or fund look through matters to your limits, when you run multiple order management systems and need one consistent compliance view across them, or when you intend to change order management system and do not want your rule library held hostage.

How to choose a developer

Give them one of your real guideline clauses, ideally an awkward one with an exclusion and a measurement basis, and ask them to express it. A developer who has done this will ask what the denominator is, whether it is trade date or settlement date, and what happens when a rating is missing. A developer who says it is a simple percentage check has not built this before.

Ask how they handle missing data. Every rules engine eventually evaluates a rule where one input is unavailable, and the policy for that, fail open, fail closed, or flag for review, has to be explicit per rule and defensible to a client.

Ask how a rule evaluation is stored and whether every pass is retained, not just failures. Firms that only store breaches cannot prove coverage.

Ask what they have integrated on the order side, because a Charles River order feed, an Eze staging interface and a Bloomberg AIM connection are three different projects. Ask for the named system.

And settle ownership before kickoff. Your rule library is your 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 a vendor lock on your own rules is the exact problem you are trying to escape.