← All articles
Build in public September 2026 10 min read

Building a structured MiCA library — 26 cited obligations across four pillars

Markets in Crypto-Assets Regulation (MiCA — Regulation (EU) 2023/1114) came into full application in December 2024. Nearly two years later, no one has published a machine-readable structured library of MiCA obligations that a compliance platform, RegTech vendor, or LLM-based tool can consume with paragraph-level citations. We're building that library, and we're partway through — this is a diary of the sprint we're in the middle of.

The gap

MiCA is a big regulation. Nine Titles, ~150 primary Articles, plus a growing pile of Level 2 measures (RTS and ITS from ESMA and EBA) that fill in the operational detail. It creates three regulatory relationships:

If you're building a compliance stack around any of that, you need to know: what obligations attach to which entity type, when they apply, whether transitional relief modifies them, which RTS operationalises them, and where the primary source citation lives so a reviewer can check it two years later.

Today the answer is mostly PDF. EUR-Lex serves the Regulation text; ESMA and EBA publish RTS/ITS as they land. Nobody has stitched all of it into a queryable schema with cross-references to the related regulations — DORA, the Transfer of Funds Regulation Recast, MAR, EMD — that a MiCA-scope firm has to comply with simultaneously.

That's the vertical we're building.

Why MiCA over other candidates

We considered three depth candidates for this quarter's build:

MiCA (chose). Greenfield regime in force since 2024–25. Thomson Reuters, LexisNexis, and Wolters Kluwer cover MiCA at title-level in their subscription products but have not yet built structured MiCA-as-API at meaningful depth. The consumers we're building for — compliance platforms (Chainalysis, Elliptic, Notabene, TRM), RegTech vendors, LLM-based advisory tools — need a citable authority layer for MiCA queries. Same B2B2B distribution pattern that worked for our AASB-S2 climate disclosure vertical.

UK MLRO / Financial Crime (skipped). Wolters Kluwer and JMLSG have covered this segment for decades and sell to those buyers already. No wedge, no underserved niche, no reason for anyone to switch.

NZ Immigration Advisers (deferred). Would work as a direct parallel to our Australian Migration Act vertical, but the market is small and the wedge is one we already know. Better as our next-onboarded engineer's first substantive vertical than the flagship for this quarter.

The criteria we applied are the same ones that worked for our AU verticals: captive, regulated, findable audience with a standing obligation to maintain a current library; underserved by incumbents; narrow enough to be niche, broad enough to sell into.

The schema — three tables, six triggers

We mirrored the schema that shipped for AASB-S2 last year:

SQL — three tables, abbreviated
CREATE TABLE mica_entity_types (
  id INTEGER PRIMARY KEY,
  code TEXT UNIQUE NOT NULL,           -- 'CASP_CUSTODY', 'ART_ISSUER', ...
  category TEXT NOT NULL,              -- 'CASP' | 'ART' | 'EMT' | 'OTHER_CRYPTO'
  subcategory TEXT,                    -- for CASPs: 'custody', 'trading_platform', ...
  primary_regulation_article TEXT,     -- 'Art 3(1)(16)'
  significance_thresholds TEXT          -- JSON
);

CREATE TABLE mica_requirements (
  id INTEGER PRIMARY KEY,
  entity_type_id INTEGER REFERENCES mica_entity_types(id),
  pillar TEXT NOT NULL,                -- 'AUTHORIZATION' | 'CONDUCT' | 'MARKET_INTEGRITY' | 'CONSUMER'
  category_code TEXT NOT NULL,         -- 'MICA-AUTH-OWN-FUNDS'
  obligation_text TEXT NOT NULL,       -- paraphrased per copyright practice
  mica_article_ref TEXT NOT NULL,      -- 'Art 67(1)'
  applicable_from DATE NOT NULL,
  national_transitional_end DATE,
  measurement_categories TEXT DEFAULT '[]',
  methodology_references TEXT DEFAULT '[]',
  notification_inputs_required TEXT DEFAULT '[]',
  reporting_templates TEXT DEFAULT '[]'
);

CREATE TABLE mica_applicability (
  id INTEGER PRIMARY KEY,
  requirement_id INTEGER REFERENCES mica_requirements(id),
  member_state TEXT,                   -- ISO-2 or NULL for EU-wide
  applicability_type TEXT NOT NULL,    -- 'STANDARD' | 'EXEMPTION' | 'DEROGATION' | 'STRICTER'
  effective_from DATE,
  applicability_note TEXT
);

Three main tables, three shadow history tables, and six BEFORE UPDATE/DELETE triggers that snapshot to history on every change. The history pattern is the boring-but-important part: a moat around a change-and-evidence layer accumulates from day one. Even before the first RTS updates land, the fact that we captured a specific-obligation state on a specific date is what a reviewer can point to two years later. Day-one of accumulation matters more than which features ship in month one.

The four annotation fields on mica_requirements — measurement_categories, methodology_references, notification_inputs_required, reporting_templates — are what makes the data useful downstream. Those are the primitives the raw regulation doesn't spell out but every consumer synthesises independently. Providing them once, cited to source, saves each downstream vendor from re-doing the same synthesis work.

Four pillars, 26 obligations

We settled on four pillars mapped to MiCA's structure:

Here's what a single row looks like when it lands via the API:

GET /v1/mica/obligations — single result
{
  "category_code": "MICA-AUTH-OWN-FUNDS",
  "short_title": "Prudential own funds requirements",
  "obligation_text": "A CASP shall at all times hold own funds at least equal to the higher of: (a) the minimum amount specified in Annex IV for its CASP class, or (b) one quarter of its fixed overheads of the preceding year...",
  "mica_article_ref": "Art 67(1)",
  "pillar": "AUTHORIZATION",
  "applicable_from": "2024-12-30",
  "measurement_categories": ["own_funds_eur", "fixed_overheads_prior_year_eur", "casp_class"],
  "methodology_references": [
    "EBA RTS on own funds calculation (Art 67(6))",
    "Regulation (EU) No 575/2013 for CET1 definition"
  ],
  "notification_inputs_required": ["own_funds_report", "regulatory_capital_composition"],
  "source_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32023R1114"
}

That's the shape a compliance-platform integration consumes. The obligation text is paraphrased — under 15 words per quoted phrase per copyright practice — but the article reference and source URL let a reviewer verify against the primary text in two clicks.

Verification — three tiers, we're using two

MiCA is publicly available and paraphrasable. The risk is misstating a specific obligation and having a downstream consumer act on it. We chose a three-tier framework and, for Phase 1, are using two:

Tier 1 — operator-compiled source document + disclaimers. Paragraph-level citations to CELEX:32023R1114, copyright-conscious paraphrasing, self-flagged residual uncertainties (particularly where RTS is still in drafting). Same posture our existing 457 records take across other jurisdictions.

Tier 2 — optional paid narrow-scope lawyer review. Scoped to the MiCA entry gate (Art 3 definitions), significance thresholds (Art 43, Art 56), and national transposition for the six covered Member States. Targeting late October if a paying customer commits.

Tier 3 — formal legal sign-off. Not for Phase 1. Would trigger only if a paying customer requests liability-shifting on their integration.

We're deliberately not pretending Tier 3 is on the roadmap for now. Compliance platforms consuming this data are supposed to apply their own review; RegIntel is the authority layer, not the regulatory approval.

What we deliberately didn't ship

Every launch post has this section because it's the most useful signal we can give consumers. In v1 we're not shipping:

Non-EU MiCA-analogous regimes. UK's FSMA 2000 crypto amendments are a separate vertical. Same for the US GENIUS Act (if enacted) and Hong Kong's VASP framework. Phase 2 or later.

Calculator functionality. We're the authority layer beneath compliance platforms, not a compliance calculator ourselves. Chainalysis, Elliptic, Notabene, and TRM are the calculation surfaces. We give them the structured obligations plus annotation primitives; they compute against a customer's actual data.

National transposition for 21 smaller Member States. We're covering Germany, France, Ireland, Malta, Luxembourg, and Netherlands in Phase 1 — six most crypto-active jurisdictions. The other 21 EU Member States follow in Phase 2, driven by customer demand.

Real-time RTS publication tracking as a primitive. Right now RTS get picked up by our weekly research loop and land in batches. Real-time push is a Phase 2 candidate — the SQL is trivial, but the interesting question is which shape of filter downstream consumers actually want. Better to hold it back than ship a filter shape we'll have to break later.

Multilingual support. English only in v1. MiCA is authoritative in all 24 EU official languages; downstream users citing MiCA to French, German, or Italian regulators may need cross-references to the equivalent-language CELEX version.

What's next

Timeline for the rest of Phase 1:

If you're building against MiCA and any of the above shape looks useful — or if there's a specific pillar we haven't cut fine enough — we'd genuinely like to hear what would make it more useful before we lock the schema in. There's still time in the sprint to bend toward real consumer feedback. Reply to this post via the contact form on regintelapi.com, or reach out via the weekly digest.

See also
How we shipped regulation-change webhooks — the push side of a regulatory data API →

The previous build log — how RegIntel push-notifies you within 30 seconds of a regulation change, and the three things we deliberately didn't ship.

Building against MiCA?

Get an API key now — MiCA obligations join in October, but our AASB-S2, Migration, NDIS depth verticals are live today.

Get API key →