Building a Terminology Pipeline for MiCA White Paper Translations (A Dev's Guide)

If you're building tooling for a crypto issuer going through MiCA notification, there's a good chance translation workflow ends up on your plate. Legal and compliance will own the final sign-off, but someone needs to build the pipeline that keeps terminology consistent across languages, versions, and document types. That someone is often an engineer, not a translator.

The source article on MiCA white paper translation requirements covers the regulatory side well: Article 6 requirements, why risk factors are sensitive, why machine translation alone is risky for this document class. This post picks up where that leaves off — how to actually build the infrastructure around it.

Why this isn't a translate-and-ship problem

A MiCA white paper isn't a single file. It's a document that has to stay in sync with:

• the website
• terms and conditions
• tokenomics annexes
• marketing materials
• any technical blockchain paper referenced in the white paper

If "staking" gets translated as one term in the white paper and a different term on the website, that's a terminology gap a regulator like CMVM can flag during review. This is a consistency problem, and consistency problems are exactly the kind of thing you can build tooling for.

Step 1: Build a terminology database before translation starts

Don't let translation begin without a locked glossary. This is standard practice in localization engineering, but crypto projects often skip it because the team is moving fast and english-only.

A minimal structure:

{
  "term": "smart contract",
  "domain": "blockchain",
  "translations": {
    "pt-PT": "contrato inteligente",
    "de-DE": "Smart Contract",
    "fr-FR": "contrat intelligent"
  },
  "do_not_translate": false,
  "notes": "Keep untranslated in DE per legal review, 2024-03"
}

Store this in something queryable, not a spreadsheet buried in a shared drive. A lightweight approach:

• JSON or YAML files in a git repo, one per domain (legal, technical, financial)
• A CI check that fails the build if a new term appears in source text without a corresponding glossary entry
• A simple script that diffs the glossary against the latest source document to catch drift

import re, json

def find_ungglossaried_terms(source_text, glossary_terms, candidate_terms):
    missing = [t for t in candidate_terms if t.lower() not in glossary_terms]
    return missing

# candidate_terms would come from an NER pass or a manually
# maintained list of domain terms you expect to see

This isn't about automating translation. It's about making sure the humans doing the translation (and the reviewers checking it) are working from the same vocabulary, every time.

Step 2: Treat the white paper like versioned source code

Teams often iterate on the white paper in Google Docs or Word, then hand off a static snapshot for translation. That snapshot immediately goes stale when compliance makes another round of edits.

Better approach: keep the source document in a format that diffs cleanly.

• Markdown or AsciiDoc source of truth, rendered to PDF/DOCX for submission
• Git history gives you a real audit trail: who changed the risk factors section, and when
• Translation updates become PRs against specific sections, not full re-translations

git diff v1.2..v1.3 -- sections/risk-factors.md

If your legal team insists on Word, you can still version it: commit the .docx binary and use a tool like pandoc to extract text for diffing.

pandoc risk-factors-v1.2.docx -t markdown > v1.2.md
pandoc risk-factors-v1.3.docx -t markdown > v1.3.md
diff v1.2.md v1.3.md

This matters because the source article notes that any softening introduced in translation can read as an omission of material information to a regulator. If you can't tell exactly what changed between source versions, you can't verify the translated version reflects those changes accurately either.

Step 3: Automate the consistency check across documents, not just within one

The white paper, the website, and the T&Cs are usually maintained by different teams, in different tools (CMS, static site generator, Word). This is where inconsistency creeps in.

A basic cross-document terminology checker:

import yaml

def load_glossary(path):
    with open(path) as f:
        return yaml.safe_load(f)

def check_document(doc_text, glossary, locale):
    issues = []
    for term, data in glossary.items():
        expected = data["translations"].get(locale)
        if expected and expected not in doc_text:
            # term might legitimately not appear, but worth flagging
            # for manual review rather than silent drift
            issues.append((term, expected))
    return issues

Run this against the website's localized strings, the exported white paper text, and the T&Cs, per locale, as a scheduled CI job. It won't catch everything, but it catches the obvious drift before a reviewer at CMVM does.

Step 4: Don't let machine translation touch risk factors unsupervised

It's tempting to run a draft through DeepL or GPT to speed up the first pass. That's fine for internal review drafts. It's a bad idea for anything going to a human translator as a "pre-translated" base for the risk factors or rights-and-obligations sections, because MT tends to normalize legal hedging language that was written deliberately.

If you do use MT as a first pass:

• Flag MT-origin segments explicitly in the file (a custom XLIFF attribute or a comment) so the human reviewer knows which sentences need extra scrutiny
• Never let MT output go directly into a submission-ready document without a second-linguist review pass
• Keep MT entirely out of the glossary-locked terms; feed the glossary into the MT engine's custom terminology feature instead, if you use one, to at least reduce obvious inconsistency

Where this fits with the actual translation vendor

None of this replaces a qualified linguist team, especially for a regulatory document where financial translation accuracy has legal weight. What it does is make the vendor's job easier and faster: hand them a locked glossary, a clean diffable source, and a known set of cross-document consistency checks, and you cut down the back-and-forth that otherwise eats into timeline.

If you're the engineer supporting a MiCA notification, building this pipeline before you request a translation quote will save real time, and it gives your compliance team a much better answer than "we'll check manually" when the regulator asks how terminology consistency is maintained across documents.