All insights

Regulation

From prospectus to code: turning investment limits into testable compliance rules

Investment compliance systems such as SimCorp Dimension™, Charles River or MIG21 can only check what has been coded. Between a legal text or fund prospectus and a working rule lie interpretation, data mapping and testing — and most compliance gaps start in these steps, not in the system itself.

1. Build a complete rule inventory

Collect every source of restrictions: the applicable regulation, the fund prospectus or articles, the investment management agreement, internal risk limits and client-specific exclusions. Each rule gets a unique ID, the exact source reference and an owner.

2. Interpret each rule precisely

Legal wording has to become an unambiguous specification. A classic example is the UCITS diversification rule: a fund may invest no more than 10% of its assets in securities of a single issuer, and holdings in issuers above 5% may not exceed 40% in total. To code this correctly you must define the issuer level (legal entity or group), which instruments count, how derivatives and cash are treated and which exemptions apply — for example for government bonds.

Swiss pension funds face a similar exercise with BVV2: category limits such as 50% for equities, 30% for real estate, 15% for alternative investments and 30% for foreign currencies without hedging, plus a 10% limit per debtor. Swiss securities funds follow the investment restrictions of the KKV, which are largely aligned with UCITS. Under AIFMD, managers calculate leverage using both the gross and the commitment method and must stay within the maximum levels disclosed to investors.

3. Map the data each rule needs

A rule is only as good as its data. Issuer hierarchies, security classifications, country and currency attributes, look-through data for target funds and derivative exposures all have to be available and mapped consistently. Missing or wrongly classified data is the most common reason for false alerts — and for real breaches that go unnoticed.

4. Test with positive, negative and boundary cases

  • Positive cases — portfolios that must pass.
  • Negative cases — portfolios that must trigger a breach.
  • Boundary values — exactly at the limit, just below and just above.
  • Parallel runs — old and new systems checked on the same positions before go-live.

5. Analyse breaches and document decisions

Distinguish active breaches caused by a trade from passive breaches caused by market movements, subscriptions or redemptions. Each type has its own remediation timeframe and reporting obligations. A documented breach analysis protects both the fund and the people responsible for it.

Where projects go wrong: rules coded from summaries instead of source documents · unclear issuer definitions · missing look-through data for target funds · no regression tests after system upgrades.

Treat rules as a living library

Prospectuses change, regulations are amended and systems are upgraded. Managing the rule set as a versioned library — with sources, specifications, test cases and change history — keeps compliance consistent through every migration. This is the core of our compliance rules engine.

This article is for general information only and does not constitute legal, regulatory or investment advice. Always refer to the applicable legal texts and fund documentation.

Planning a migration or a new mandate?

We code, map and test your investment rules so compliance stays consistent from day one.