Product, taxonomy, and jurisdiction support

Product version

These English articles cover SolvencyBridge product version 2026.8.1. Documentation is maintained for the current minor product line; behavior from an older deployment must be checked against its own release materials.

Taxonomy support

Support is determined by the taxonomy packages installed in the deployment. A filing pins a package version. Check its version, checksum, module/template catalog, and disclosed validation coverage. The synthetic SOLVENCY-II-PILOT-FIXTURE package is not authoritative.

For an EIOPA filing, open Export and use Taxonomy migration below the export controls. The migration control offers only installed newer releases from the same taxonomy family. Creating a successor re-runs validation and records migration evidence, but does not establish that a national profile supports the target release. Confirm the profile/release row and every required capability in the coverage catalog separately.

French national reporting from year-end 2026

For supported EIOPA 2.8.2 filings, ACPR RAN-ENS national forms use 1.8.1 from the reporting date 31 December 2026. Earlier periods retain 1.8.0. The property valuation form FR.30.01 uses NACE 2.1 for the tenant's sector in column C0170. Editing, validation and XBRL import/export use the filing's applicable national release. A filing or form pinned to the wrong release remains blocked until it uses the applicable release. For existing French filings covered by the migration below, use that migration rather than recreating the filing; it preserves the original values and requires fresh validation and approval.

RAN-ENS 1.8.1 still references EIOPA 2.8.2. It does not enable French national reporting for EIOPA 2.10.0 or establish authority acceptance.

Czech national validation update

The CNB workbook reviewed on 15 October 2026 adds 43 executable insurer rules for the installed EIOPA 2.8.2 package, including percentage limits, catastrophe calculations and cash-flow presence checks. NV147.15 now permits C0200 values up to 1.5; its separate C0220 limits remain in force. NV40.12 also checks for missing inputs. These checks help preparation but do not establish submission readiness.

The missing exception column does not establish that previous exceptions were withdrawn. The 54 historically documented exceptions remain unresolved after checking CNB's public methodology page and change notices; the DQ Report linked from that page was unavailable. On 19 October, the public DQ README was recovered from an official CNB export URL. It confirms that some rules allow justified exceptions, but does not identify which historical exceptions apply. Their text is retained for review, and the affected rules are not automatically enforced as unconditional requirements.

For EIOPA 2.8.2, 68 rules remain pending exception, context or data-point review. The coverage catalog shows Czech national validation as partial with the actual review date. Validation reports an incomplete-coverage error that blocks submission even if the executable checks pass. The EIOPA 2.10.0 compatibility catalog has 45 of the new rules and 69 pending rules; this technical compatibility work is not proof that CNB has published or accepted that national rule package for 2.10.0.

NV178 and NV179 now check that each non-zero reported line of business in S.05 has corresponding non-life or health underwriting detail in S.26. The line-of-business identities come from the pinned taxonomy dimensions. Reported zero in the corresponding S.26 detail counts as present.

Annual and quarterly Czech balance sheets

NV168 compares the presence of reported cells in the annual AES and quarterly QES balance sheets at the same 31 December. It does not require equal amounts; a reported zero counts as present. Annual-only statutory accounting cells are excluded from the comparison.

NV168 runs on the annual filing using the Q4 filing as its dependency. The Q4 filing does not need an annual filing to exist and does not consume later annual changes. Quarterly reporting is due earlier than annual reporting.

Keep one annual and one quarterly supervisory solo filing for the same organization, reporting entity, taxonomy release, business type and year-end. Include the applicable balance sheet in each filing. Missing balance sheets or multiple matching counterpart filings block the check; resolve duplicate filing records by deleting the unwanted duplicate before retrying; there is no archive or cancellation status that excludes it. Changes to the Q4 filing, including changes that make it no longer match, invalidate the annual validation result and schedule a fresh check.

Czech supervisory solo filings use the ECB-extended AES/QES modules. For an existing filing, review its template selection and rerun validation after the update; previously prepared standard ARS/QRS data does not establish complete AES/QES coverage. Group and public-disclosure modules are unchanged. The other national coverage and submission evidence requirements still apply.

National authority reviews

The 2027 filing setup notice shows a National authority review date, finding and official-source link. The public coverage page keeps this research detail out of country summaries. Findings distinguish published transition guidance, preparatory material, implementation not established by the review, and sources found through search whose direct verification remains incomplete. An inconclusive review does not mean that no implementing law exists.

The review date records when the national website research was assessed. It does not replace the Legal evidence observation date or refresh deadline. A recent review does not prove official notification, complete transposition, or submission readiness. Export and authority packaging remain blocked until their legal and authority evidence requirements are met. EEA incorporation observations remain separate from these EU national website findings.

Jurisdiction support

The product contains authority profiles for multiple European jurisdictions, but capabilities vary by profile and release. A profile can have any combination of identity fields, forms, validations, export formats, readiness evidence, receipt recording, or portal-status interpretation.

On the public coverage page, select your country under Country and authority to see the current reporting release, common EIOPA workflow, national workflow availability, and submission readiness. Select All jurisdictions to compare countries again. The selector updates immediately.

Open View technical coverage details for the status of individual capabilities, including native export, authority packaging, signing, and transport. The separate 2027 notice explains the preparation and export boundary for the next release; it does not establish submission readiness.

Internal review deadlines, evidence refresh dates, and maintenance blockers are omitted from the country summaries. Specialists can still use Download technical coverage data for the complete evidence catalog. A partial transport or acceptance capability does not downgrade an independently verified taxonomy capability. The Ready for submission state always requires verified taxonomy, validation, native export, and package evidence. A profile can declare an additional pre-submission requirement when the pinned authority workflow requires it. Slovakia NBS and Czech CNB currently also require verified signing evidence. Submission testing, receipt, and authority acceptance remain later lifecycle evidence and cannot be used as readiness prerequisites. The downloadable catalog also exposes the exact taxonomy checksum, complete form-code inventory, common validation-rule count, national validation status, package state, known limitations, and source freshness for every profile and release.

Catalog schema version 2 adds a solvencyIIReview2027 record for every jurisdiction profile. For EU profiles it distinguishes not observed, no notified measures listed, and official measures notified. For Iceland, Liechtenstein, and Norway it separately records EEA incorporation and national implementation. Official notification is an operational evidence gate; it is not a claim that transposition is complete, correct, legally sufficient, or verified by the European Commission.

A 2.10.0 filing may be created for preparation after an explicit, checksum-bound confirmation when national evidence is incomplete. That confirmation never satisfies taxonomy, validation, native-export, package, signing, transport, submission-test, receipt, or authority-acceptance evidence. Export and authority-package generation continue to fail closed until the current legal and authority gates pass.

The public profile inventory is pinned to a dated baseline. Adding a profile after that baseline fails closed until a partner-approved representative filing dossier and checksum-bound, passed regression evidence cover the new profile. Synthetic samples can verify the gate itself but cannot qualify a profile for publication. Every baseline profile/release row also exposes its publication-evidence backfill state. A baseline exemption preserves an existing row; it is not representative-filing evidence. Missing, unbound, or stale dossier regression evidence remains an explicit blocker and is preferred as the row's next evidence action.

Commercial commitments for the Slovakia and Czechia anchors are recorded separately from implementation status. An absent commitment is not presented as a promise. A recorded commitment names exact capabilities and cannot pass the coverage verifier unless each capability is independently verified for the exact profile and release. A non-empty commitment ledger must not postdate the coverage assessment, and an overdue review blocks publication until the promise is reconfirmed or removed.

Jurisdiction status measures whether everything officially published and applicable at the evidence date is implemented and verified. It is separate from successor-release availability. The downloadable coverage catalog records the latest supported release, successor status, evidence date, refresh deadline, national-form state, and export state. A successor marked not_published, partially_published, or authority_unavailable is never reported as implemented merely because the common EIOPA taxonomy is bundled. An export is partial when a published national form or authority-native artifact is not fully implemented, and not_available when the authority has not made the release applicable.

For every partial jurisdiction, the catalog includes an implementation blocker with the exact published requirement, missing authority artifact or safe tool, evidence date, refresh deadline, and reopening trigger. A partial state without that blocker record is rejected by the coverage verifier.

Export completeness is independent of jurisdiction-taxonomy completion. A taxonomy-complete profile can therefore have exportState: partial when an authority-native filename, binding set, signing artifact, or packaging contract is unavailable. The catalog includes an exportBlocker for every such state; common EIOPA export availability is not presented as proof that every required national artifact can be produced. NBS and FMA Austria currently identify the missing authority-artifact publication as partially_published; this does not make their implemented jurisdiction taxonomy partial.

For Poland, KNF-02 national form selection follows the reporting year. The 2026 and 2027 releases have separate retained source checksums and review evidence. Both support structured preparation and an internal JSON audit snapshot; neither provides an authority-native SNU package.

How to verify support

1. Select the exact reporting entity, period, taxonomy, and jurisdiction.
2. Read the controls and limitations shown for that filing.
3. Inspect the installed release provenance and validation coverage.
4. Obtain current authority instructions and approved downstream acceptance evidence.
5. For 2027 periods, inspect solvencyIIReview2027, including its legal path, evidence date, refresh deadline, source checksum, and blockers.
6. Treat an absent capability or evidence record as unsupported, not implied.

Boundary

Profile presence is not authority endorsement. Support for preparation does not automatically include authority-native export, transport, or acceptance verification.

Existing French filings: RAN-ENS 1.8.1 migration

Existing unexported French filings dated 31 December 2026 or later migrate from RAN-ENS 1.8.0 to 1.8.1 during the database upgrade. They return to draft and must pass validation and approval again. The migration retains the complete original form values, including excluded forms, for reference; it does not alter exported filings or immutable snapshots. Reopening an exported filing for these periods migrates its working forms to 1.8.1 in the same operation and requires fresh validation and approval. Its exported snapshot remains unchanged. Earlier periods remain pinned to 1.8.0.

FR.30.01 C0170 tenant NACE values cannot be converted automatically from NACE 2 to NACE 2.1. Their original facts are retained in the migration record and removed from the active facts. A blank NACE 2.1 field preserves each tenant row, even when it contained only the old NACE value. Enter a reviewed NACE 2.1 value in the national form, or import a corrected 1.8.1 instance. You can delete a row that no longer belongs in the return or correct its identifier. Every remaining tenant row, including renamed rows, still requires a valid NACE 2.1 selection. A missing or invalid replacement continues to block review and export, even if the old and new code would have been spelled the same. Other incompatible facts remain available and are reported by the normal national-form validation checks.

Form selection and the editor use the filing's pinned release. If a deployment has not applied the migration yet, the filing remains blocked for release mismatch; recreating the filing is not required. Administrators can inspect the preserved source values through the national form's payload diagnostics. The audit history records the release change and previous filing state.

Dutch VNS validation

VNS 3.1.0 validation resolves omitted dimensions to the defaults declared by the installed dictionary and preserves separate Formula evaluation groups. Rerun validation on existing Dutch filings: amounts previously overlooked by these checks may now produce findings. An assertion that cannot be evaluated remains blocking. Official sample instances are compatibility examples and do not establish representative filing conformance or full national support.