Surviving a framework release — the upgrade playbook

A framework release is a change project with a fixed, externally set deadline and no option to descope — and most firms treat it as an IT upgrade. The European Banking Authority publishes each release as a package: the data point model, the XBRL taxonomy, the validation rules and the annotated templates. Releases are numbered sequentially, and each specifies module-level applicability dates rather than one date for the whole package. That last detail is the one that catches people.

1. Applicability is per module

“We are on version X” is not a complete answer to “what applies to this submission”. A single release can change one module from one reference date and another from a later one, so two returns due in the same week can legitimately be built against different specifications.

2. The six steps

Step 2 is where the risk actually lives, and it is the step teams skip. Added and removed data points are visible — a build fails or a cell is empty. Redefined data points are invisible: the file builds, the rules pass, and the number now means something different from what it meant last quarter. Only a deliberate diff against the model catches those.

3. Validation rules move separately

The rule set is a moving target inside a stable framework version. Updated or small validation-rule packages are published on a quarterly basis, independently of the framework release itself — which means a submission can fail this quarter with no change to your data and no change to your framework version.

Two habits follow. Re-run the previous period’s accepted file against the current rule package before building the new one; that single test separates “our data changed” from “the rules changed”, and it costs almost nothing. And track deactivated rules as carefully as new ones, because an internal control built around a rule that has been withdrawn is a control that silently stopped working.

4. Rehearsal is the whole safety margin

Framework releases are published in advance precisely so that mapping changes can be made before the first affected reference date. A rehearsal — building a period you have already filed against the new specification and comparing — converts that lead time into information.

What a rehearsal tells you that nothing else does:

• which figures change under the new specification, and whether the change is explicable;
• which mapping entries now produce nothing;
• whether any new data point requires source data you do not hold — which is the finding with the longest lead time and the only one that cannot be solved inside the reporting team.

5. A worked case

Facts: a release changes the dimensional breakdown on a counterparty attribute in one module, effective from a reference date two quarters out. The reporting team upgrades its tooling to the new taxonomy immediately.

What goes wrong: the module whose applicability date has not yet arrived is now being built against a specification that does not yet apply to it. The file may be rejected outright, or — worse — accepted with figures on the wrong basis.

What the practitioner does: keeps both specifications available and selects by reference date and module rather than by “current version”. The pipeline holds the framework version as an attribute of the submission, not as a global setting — which is the same discipline that makes corrections to historical periods possible at all, since a correction is built against the framework applicable to the reference date being corrected.

FAQ

Related: XBRL taxonomies · Validation rules · Mapping source data to a template