Product, taxonomy, and jurisdiction support - SolvencyBridge Help
Questo articolo manca, è obsoleto o non è ancora stato verificato in italiano. Viene mostrata la fonte inglese autorevole.
Riferimenti
Product, taxonomy, and jurisdiction support
Determine support from the installed package and filing controls instead of assuming uniform coverage.
Versione 2026.8.1Amministratore · Preparatore · RevisoreVerificato 2026-08-12
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.
The filing 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. Existing forms are not silently converted: a filing or form pinned to the wrong release is blocked and must be recreated with the applicable release.
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 linked DQ Report could not be retrieved. Their text is retained for review, and the affected rules are not automatically enforced as unconditional requirements.
For EIOPA 2.8.2, 71 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 42 of the new rules and 72 pending rules; this technical compatibility work is not proof that CNB has published or accepted that national rule package for 2.10.0.
National authority reviews
The public coverage page and the 2027 filing setup notice show a separate National authority review date, finding and official-source link. 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.
The public coverage page expands each profile into separate taxonomy, validation, native-export, package, transport, signing, submission-test, receipt, and authority-acceptance rows. Each row shows its own status, explicit blocker when evidence is missing, and evidence refresh date. A partial transport or acceptance row does not downgrade an independently verified taxonomy row. 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
Select the exact reporting entity, period, taxonomy, and jurisdiction.
Read the controls and limitations shown for that filing.
Inspect the installed release provenance and validation coverage.
Obtain current authority instructions and approved downstream acceptance evidence.
For 2027 periods, inspect solvencyIIReview2027, including its legal path, evidence date, refresh deadline, source checksum, and blockers.
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.