This week we open-sourced the regulatory data ontology we’ve been refining internally for the last three years. It maps the operative rules from Chile’s CMF, the UAF, Peru’s SBS and Europe’s MiFID II to a shared schema of portfolio events. JSON-Schema, CC-licensed. The repository link is in the footer of every page on this site from today.
A handful of people have asked the obvious question: why give that away?
The short version
For the same reason we give away every other piece of infrastructure we build that isn’t a moat. Because regulatory mappings shouldn’t be a moat. Because the work compounds when more people use it. And because, as we’ve said elsewhere on this site, open beats clever over any timeframe longer than two years.
But the longer version is more interesting.
What the ontology actually is
It’s a JSON-Schema with three top-level entities and a handful of relationships:
- Regulatory rule — an atom of regulation, identified by jurisdiction, regulator, circular and clause. Has a category (operational, reporting, KYC, fitness-and-propriety, etc.), an applicability (which kinds of vehicles, which thresholds), and an effective-from / effective-until window.
- Portfolio event — an atom of operational reality. A trade, a position change, an investor onboarding, a NAV calculation, a regulatory submission. Each event has a strict event-type taxonomy and a payload schema.
- Mapping — the bridge. A rule maps to one or more event types, with a “decision” field that determines what the rule expects (record / submit / verify / approve / block).
There are also a few connective entities — operator attribution, evidence references, supersession links between rules — but those three are the spine.
Why “ontology” and not “library”
The choice of word matters. A library implements behavior; an ontology defines vocabulary. We didn’t open-source the implementation that runs against this schema (that’s our compliance engine, and it’s still proprietary). We open-sourced the vocabulary — the shared way of describing the relationship between a regulatory rule and an operational event.
This distinction is everything. If everyone has the same vocabulary, libraries can compete on implementation. If everyone has different vocabularies, every integration is a translation problem.
The economic value of the ontology comes from being shared. The economic value of the implementation comes from being good. We can keep the implementation closed without making the vocabulary closed.
What the schema gives you
If you adopt the ontology, the immediate practical benefits are:
- Vendor portability. Compliance tooling that consumes the ontology can be swapped without re-mapping rules. Your rule library is yours.
- Audit-trail consistency. Different systems describing the same event use the same vocabulary. The inspector sees one record, not seven.
- Cross-jurisdictional comparison. Because every rule is attached to a jurisdiction and a category, comparing the operational impact of CMF vs SBS vs MiFID II across your firm becomes straightforward.
We’ve seen all three of these become operational concerns at the managers we work with. They’re the kind of concerns where the right answer wasn’t a feature — it was a shared vocabulary.
What the schema does not give you
It’s deliberately scoped. Three things we’ve explicitly excluded:
- Risk models. The ontology covers regulatory and operational events. It doesn’t try to model market or counterparty risk. Risk vocabularies are well-served by existing standards.
- Cross-asset taxonomies for instruments. We use FIGI / ISIN / standard market identifiers and don’t reinvent.
- Workflow definitions. How a rule routes through your firm is implementation. We describe what the rule expects; we don’t prescribe how you fulfil it.
If you’re hoping for a complete compliance-in-a-box, this isn’t that. If you’re hoping for a foundation other people can build on, it is.
What we want from contributions
The repository is public. Issues and PRs are open. We’ve already loaded:
- CMF Chile — NCG 207, NCG 264, NCG 507 and a handful of operational circulars
- UAF Chile — N°49, N°55, N°62
- SBS Peru — the AGF and SAFI mandate framework
- MiFID II — the subset that affects EU-domiciled funds with LatAm investors
What we want from the community: more jurisdictions. We don’t have the right people on staff to authoritatively map Brazil’s CVM rules, Colombia’s Superfinanciera, or Mexico’s CNBV — but we’ve had every one of those mappings asked for in the last twelve months. If you have the local expertise, the schema is yours to extend.
The honest commercial answer
There’s also a commercial reason we open-sourced this, and we should be transparent about it. Asset managers we work with have been asking for guarantees of vendor portability for years. The ontology is, in part, our answer.
A manager who runs on our Backbone service or portfolio module gets the implementation that consumes this ontology. But because the ontology is open, they could also leave us — taking their rule library to a different vendor — without the kind of forced re-mapping cost that has historically locked managers into infrastructure they’d long outgrown.
That’s a feature, not a bug. We earn the contract every quarter, or we lose it. The ontology makes that real.
Elena Mora leads finnerve’s open-innovation work. The repository is at github.com/finnerve/regulatory-ontology (placeholder pending public launch). Issues and PRs welcome.