The problem isn't just translation, it's data consistency across formats

If you work in insurtech or build internal tooling for a multinational insurer, you've probably run into some version of this problem: the same regulatory figures need to exist, consistently, in a narrative document (the SFCR), a set of structured quantitative templates (QRTs), and multiple language versions, all of which have to agree with each other down to the decimal point.

A related article from M21Global covers the linguistic and regulatory side of this well: why SFCR translation requires Solvency II expertise, not just language fluency. That's the compliance angle. This post is about the engineering angle: how do you actually build a pipeline that keeps terminology, figures and structure consistent across languages and report cycles, without relying on manual cross-checking every year?

Why this is a data problem before it's a translation problem

The SFCR mixes two very different content types:

  • Structured data: SCR/MCR ratios, eligible own funds, QRT templates with EIOPA-standardized row/column labels
  • Unstructured narrative: governance descriptions, risk profile commentary, valuation methodology text

Most teams treat the whole document as unstructured text and hand it to a translation vendor as a Word or InDesign file. That's how you get the exact bugs described in the source article: a term like "technical provisions" translated inconsistently in section 3 versus section 5, or a QRT label that doesn't match the officially published EIOPA translation for that language.

The fix isn't better proofreading. It's separating the structured and unstructured parts of the pipeline and treating terminology as a controlled vocabulary, not free text.

Step 1: Pull QRT labels from EIOPA's own taxonomy

EIOPA publishes the Solvency II reporting taxonomy (XBRL-based) with standardized labels in every official EU language. If your reporting system generates QRTs programmatically, you should be pulling labels directly from this taxonomy rather than letting a translator retype them.

A minimal approach:

# Pseudocode: resolve QRT labels from the EIOPA taxonomy import requests TAXONOMY_URL = "https://eiopa.europa.eu/taxonomy/2.x.x/labels.json" def get_label(concept_id: str, lang: str) -> str: labels = requests.get(TAXONOMY_URL).json() return labels[concept_id].get(lang, labels[concept_id]["en"]) # Example get_label("s2md_met:mi362", "fr") # -> "Provisions techniques"

This guarantees your QRT labels match what the French or Spanish supervisor already expects to see, because it's the same source EIOPA uses. No translator discretion involved for this part.

Step 2: Treat narrative terminology as a glossary, not prose

For the narrative sections, build a termbase before translation starts, not after. Tools like SDL MultiTerm, Phrase TMS, or even a well-maintained spreadsheet synced to a CAT tool work fine. The key fields:

{ "term_en": "loss-absorbing capacity of deferred taxes", "term_fr": "capacité d'absorption des pertes par les impôts différés", "term_es": "capacidad de absorción de pérdidas de los impuestos diferidos", "domain": "Solvency II - Pillar 1", "source": "EIOPA glossary v2.0", "do_not_translate_as": ["capacité d'absorption fiscale"] }

If you're integrating with a translation API (DeepL API, Google Cloud Translation, Phrase), most support glossary injection. For example, with the DeepL API:

import deepl translator = deepl.Translator("YOUR_API_KEY") glossary = translator.create_glossary( "solvency-ii-fr", source_lang="EN", target_lang="FR", entries={ "technical provisions": "provisions techniques", "own funds": "fonds propres", "SCR coverage ratio": "ratio de couverture du SCR" } ) result = translator.translate_text( "The SCR coverage ratio remained above 150%.", source_lang="EN", target_lang="FR", glossary=glossary )

This won't replace a qualified actuarial translator for the final narrative, but it catches the machine-translation baseline errors before a human reviewer even sees the draft, and it enforces consistency for terms that recur hundreds of times across a 100+ page group report.

Step 3: Version-control the translation memory, not just the document

SFCRs repeat heavily year over year: boilerplate governance descriptions, standard risk disclosures, methodology notes. If your translation memory (TM) lives inside a vendor's proprietary tool with no export discipline, you lose that leverage every renewal cycle.

Practical setup:

  • Export your TM as TMX after every cycle and store it in your document repo (or a dedicated bucket), tagged by reporting year and entity
  • Diff this year's source text against last year's before sending anything out for translation, so you're only paying for and reviewing genuinely new content
  • Run a terminology consistency check automatically using a tool like checkmate or a custom script that flags any term translated two different ways within the same document set 
# crude but effective: flag inconsistent translations of a key term grep -o "technical provisions" report_en.txt | wc -l grep -o "provisions techniques" report_fr.txt | wc -l grep -o "claims provisions" report_fr.txt # should return nothing if mistranslated

Step 4: Build the cross-check between narrative and QRTs into CI

The most expensive failure mode is a narrative section that states one SCR ratio while the QRT annex states another, something that happens more often than you'd expect when narrative and quantitative teams work in parallel and translation touches both independently.

If your reporting pipeline already generates both outputs from a common data source (which it should), add a validation step that extracts key figures from both the translated narrative and the translated QRT and asserts they match:

def validate_consistency(narrative_text, qrt_data, lang): extracted_scr = extract_number_near(narrative_text, keyword_map[lang]["scr_ratio"]) qrt_scr = qrt_data["scr_coverage_ratio"] assert abs(extracted_scr - qrt_scr) < 0.01, f"Mismatch in {lang}: {extracted_scr} vs {qrt_scr}"

This is a simple regex/NLP extraction problem, not magic, but almost nobody builds it because translation is treated as a separate workstream from the data pipeline. It shouldn't be.

Where this fits with external translation vendors

None of this replaces a qualified financial/insurance translator for the final narrative text. Regulatory language still needs a human who understands Solvency II, and a second reviewer for quality assurance, which is exactly the workflow described in the source article for sensitive compliance documents.

What this pipeline does is reduce the surface area of what needs human judgment, by making sure QRT labels, recurring terminology and cross-document figures are consistent and machine-verifiable before anyone's billing hours to proofread them. For a report that runs past a hundred pages per market across three or more jurisdictions, that's the difference between a predictable annual process and a scramble every filing deadline.

If you're responsible for the reporting infrastructure side of this rather than the compliance side, it's worth treating your SFCR cycle the same way you'd treat any other data pipeline with multiple consumers: single source of truth, automated validation, and version-controlled artifacts, language included.