Chapter 085: Submission Governance
Section 17: Regulatory Reporting Foundations and Delivery · Chapter 085 of 100
Filed Friday, queried Monday, corrected Wednesday, queried again Friday — the query spiral that consumes reporting teams. Submission governance ends the FINREP block where control meets the outside world: validation discipline, approval authority, regulator-query handling, and corrections that fix lineage instead of cells. This chapter runs submission as production with SLAs.
1. Chapter opening
Governance covers: pre-submission validation (taxonomy rules + internal plausibility + cross-return), approval tiers (preparer → reviewer → attestor with materiality thresholds), filing mechanics (channels, receipts, deadlines), query management (log, triage, root-cause, respond within SLA), and corrections/resubmissions (impact analysis, approval, re-filing with disclosure where material). Each step evidenced; each deadline owned with deputies.
The significance of submission governance extends far beyond the act of filing a return. A bank that files consistently on time, with clean data and minimal subsequent corrections, builds supervisory trust that compounds over time. This trust manifests as more efficient supervisory engagement, clearer evidence and more efficient handling of queries; it does not entitle the bank to fewer requests or relaxed accounting/legal standards. Conversely, a bank that files late, is queried frequently, and corrects repeatedly attracts exactly the opposite — deeper scrutiny, more frequent examinations, and scepticism about management quality. The PRA's approach to data-quality enforcement is illustrative: persistent data-quality issues can result in s 166 skilled-person reviews (the bank pays for an independent review of its data infrastructure), Pillar 2 capital add-ons, and restrictions on business activities.
Use the exact reference date and remittance date from the applicable return instructions. A generic 20-30 business-day FINREP deadline is unsafe: EU reporting schedules specify dates and template-specific frequencies, while national gateways may have additional requirements. Store holidays, time zone, scope, reporting frequency and receipt criteria in the obligation register. If a deadline is at risk, escalate early and follow the authority's contact procedure; internal approval cannot extend it.
2. Learning objectives
- Operate validation gates (no pass, no submit) with override governance.
- Apply approval tiers by materiality and return criticality.
- Manage regulator queries (acknowledge, investigate, respond, remediate).
- Execute corrections with cross-family impact analysis and re-approval.
- Report submission health (timeliness, queries, revisions) to governance forums.
- Understand the supervisory consequences of persistent data-quality failures.
3. Business context
Submission reputation compounds: clean filers get efficient supervision; chronic correctors attract reviews, skilled persons and Pillar 2 attention. Query analytics (themes, root causes, repeat rates) direct remediation investment better than any audit. Deadline culture (early internal cut-offs with buffers) separates calm filers from all-nighters — and all-nighters file errors.
Set internal milestones backwards from the actual regulatory remittance date, allowing time for review, rejection and correction. The buffer depends on return complexity, system reliability and calendar constraints; neither 60–70% of the window nor 5–10 business days early is a universal requirement. Test deputy coverage, gateway availability and cut-off time zones, and escalate a forecast delay while options remain.
The staffing model matters too. Many banks operate their regulatory reporting function with a small core team supplemented by temporary contractors during peak periods. This model is fragile — contractors do not carry institutional knowledge, and the core team is overwhelmed during the peaks. A more resilient model invests in a larger core team with deep knowledge of the bank's data infrastructure, supplemented by automation that handles the routine validation and reconciliation work. The cost of the larger core team is offset by the reduced risk of errors, late filings, and supervisory findings.
| Stage | SLA style | Owner |
|---|---|---|
| Validation | Applicable active-rule results, evidenced warning/exception treatment and plausibility review | Preparer + reviewer |
| Approval | Tiered by materiality, pre-deadline buffer | Attestor |
| Filing | Channel receipt same-day | Operations |
| Query response | Acknowledge days, resolve weeks | Query owner |
4. Finance and accounting view
4.1 Validation and approval mechanics
Taxonomy validations (blocking errors vs warnings with documented disposition — warnings need rationale, not silence); internal plausibility (period moves, ratio checks, cross-return bridges); materiality-tiered approvals (analyst/head/CFO thresholds — illustrative: <1m/auto-checks, <50m/head, above/CFO-committee). Filing receipt reconciled to submission (hash/counts); late-filing protocol (notify, explain, expedite — never silent delay).
The validation layer is the bank's first line of defence against incorrect filings. Taxonomy validations catch structural errors — incorrect cell references, missing mandatory fields, inconsistent cross-cell calculations. Internal plausibility checks catch data-quality errors — values that have moved materially without explanation, ratios that are outside historical norms, cross-return inconsistencies. The combination of taxonomy and plausibility checks should catch the vast majority of errors before the filing reaches the regulator.
The disposition of validation warnings is a critical control point. Every warning requires a documented rationale for proceeding — "timing difference", "known data lag with documented root cause", "modelled estimate within approved tolerance". The rationale must be supported by evidence, not assertion. A warning disposition that says "management judgement — no issue" is not acceptable; it must explain what the judgement is, why it is reasonable, and what evidence supports it. The disposition should be reviewed by the reviewer (not the preparer) before filing, and the review should be evidenced with a dated sign-off.
Materiality thresholds for approvals should be calibrated to the bank's size, risk profile, and supervisory expectations. A large bank with 2 trillion in total assets may set the CFO-approval threshold at 50 million; a smaller bank with 200 billion may set it at 10 million. The threshold should also consider the sensitivity of the specific return — a correction to a capital ratio may be material even at a low absolute value if it changes the ratio by more than a few basis points. The key principle is that the threshold is not a bright line that avoids scrutiny below it — it is a trigger for escalating scrutiny above it.
4.2 Query and correction workflow
Queries logged (source, question, owner, deadline, response, remediation); triage (data vs interpretation vs error); investigation with lineage evidence; response drafted, reviewed, sent; remediation tracked (fix lineage, regression-test, monitor). Corrections: impact analysis across families (across the return families in The Regulatory Reporting Landscape), re-approval at original tier+, resubmission with change log; material corrections disclosed per policy with audit-committee visibility.
The authority's request controls the response deadline. Internal acknowledgement and investigation targets may be two and ten business days in a training workflow, but they are not universal supervisory SLAs. Acknowledging a query does not reset its deadline; obtain an explicit extension if needed. Share a reviewed interim response when necessary, identify remaining evidence and preserve the final submission record.
The triage step is where the bank determines whether the query is a data issue (wrong number, missing data), an interpretation issue (the bank and supervisor disagree on how a rule applies), or an error (the bank's data or methodology is wrong). Each category requires a different response. Data issues can be resolved by correcting the data and explaining the root cause. Interpretation issues require a technical analysis with references to the applicable rules and guidance, and may require escalation to the bank's legal or regulatory affairs function. Errors require immediate correction, impact analysis across all affected returns, and a root-cause analysis that addresses both the specific error and the systemic weakness that allowed it.
4.3 Deep dive: query-theme analytics and warning-disposition governance
Query-theme analytics convert supervisory questions into prevention budgets: code every query (taxonomy area, root cause, family scope), trend themes quarterly (rising forbearance queries → fix flagging; rising mapping queries → fix governance), measure repeat rate (repeated themes prompt investigation of actual recurring causes and remediation effectiveness), and benchmark response quality (accepted-first-time rate, follow-up rate, escalation rate). Present analytics to the Board with remediation ROI (prevention spend vs query-handling + finding-risk cost) — data-quality investment wins budgets when queries are priced. Cross-bank intelligence (industry query themes from supervisory publications) anticipates next quarter's questions — prepare answers before they're asked.
The analytics framework should track several dimensions for each query. First, the taxonomy area — which part of the FINREP return was queried? If 60% of queries relate to a single taxonomy area (say, loan staging or fair-value measurement), that area is the priority for remediation. Second, the root cause — was the query caused by a data error, a methodology issue, a system limitation, or an interpretation difference? Root-cause analysis determines the fix. Third, the scope — does the query affect a single line item or multiple returns? A query that affects FINREP, COREP, and Pillar 3 returns has a wider impact than one that affects a single return. Fourth, the response quality — was the response accepted on first submission, or did the supervisor require follow-up? Accepted-first-time responses indicate strong initial analysis; follow-up responses indicate gaps in the bank's understanding.
Warning-disposition governance (validation warnings are queries in advance): every warning needs disposition (accept with evidence, fix with ticket, escalate as finding) recorded pre-filing — never waved verbally. Disposition quality sampled (plausible evidence vs hand-waving), repeat warnings root-caused (recurring warnings assessed for source defects versus continuing valid conditions; remediation follows the actual finding), and override analytics published (who overrode what, with what evidence — patterns reviewed by control owners). The §10 case (waved variance → triple resubmission) illustrates an avoidable evidence failure, without asserting an industry ranking: warnings cost minutes pre-filing and weeks post-query.
Choose independent warning-review coverage based on risk, volumes, recurring themes and control history. A fixed 10% sample is not guaranteed sufficient. Material unresolved warnings and exceptions need explicit evidence, accountable disposition and follow-up; a genuine error cannot be accepted merely because it is below a sampling threshold.
5. Product and customer impact
Submission failures rarely touch customers directly — until findings restrict business (capital add-ons rationing credit) or restatements shake confidence (deposit sensitivity). Product data quality (attributes at origination) is the upstream fix for most query themes; query analytics should feed product-data backlogs.
The connection between submission quality and product design is underappreciated. Many FINREP queries relate to data that originates in the bank's product systems — loan staging data, fair-value measurements, fee recognition, and expected credit loss calculations. If the product system captures the wrong data at origination (wrong loan purpose code, missing forbearance flag, incorrect collateral value), the FINREP return will contain errors that are expensive to correct post-filing. The fix is to improve data quality at the source — the product system — rather than correcting it in the reporting system. Query analytics should therefore be fed back to the product-data owners, with a mandate to fix the root cause in the source system.
The feedback loop is straightforward in principle but challenging in practice. The reporting team identifies a query theme (say, inconsistent forbearance-flag data). The root cause is traced to the loan origination system, which does not capture all the information needed for the forbearance-flag calculation. The fix requires a change to the origination system, which requires a business case, development resources, testing, and deployment — a process that typically takes 3–6 months. In the meantime, the reporting team must continue to work around the data gap with manual adjustments. The key is to track the fix through to completion, not to accept the manual adjustment as a permanent solution.
6. Regulatory and supervisory view
Filing obligations, validation regimes, query powers and correction duties per framework (EBA/ECB, PRA/BoE, Fed, RBI — verify channels, SLAs and penalty regimes locally). Analyse revision history using Finance Data Governance and BCBS 239; repeated corrections can prompt questions or remediation depending on cause, materiality and the applicable powers. Material-error disclosure duties vary — legal review before external correction statements.
The supervisory framework for data quality has evolved significantly since the financial crisis. Pre-crisis, supervisors were tolerant of data-quality issues — queries were treated as routine, and corrections were accepted without significant consequences. Post-crisis, the recognition that poor data quality undermined supervisory oversight led to a much stricter approach. The ECB's framework for assessing data quality, introduced as part of the Single Supervisory Mechanism (SSM), explicitly links data quality to supervisory outcomes. Banks with persistent data-quality issues may face: increased supervisory attention (more frequent on-site inspections, more detailed questionnaires), operational restrictions (limits on business activities until data quality is remediated), and capital consequences (Pillar 2 add-ons for operational risk arising from data-quality weaknesses).
Supervisor powers vary by jurisdiction and legal basis. UK skilled-person reviews under section 166, US supervisory findings and EU remedial or enforcement measures have their own conditions. A correction does not automatically result in an identical capital add-on or restriction. Record the relevant request or decision and its deadlines rather than using unsupported labels such as 'Enhanced Following'.
7. Systems and data view
Submission platform: validation engine (taxonomy + custom rules), approval workflow (tiered, timestamped, deputy-aware), filing gateway (multi-channel, receipt matching), query/correction tracker (SLA timers, root-cause coding), resubmission manager (versioned returns, change logs), archive (everything, retention-enforced). Controls: gate enforcement for applicable active blocking rules, with only the authority’s permitted exception/deactivated-rule treatment, approval completeness checks, SLA escalation.
The submission platform is not just a filing tool — it is a governance framework embedded in technology. Every validation rule, every approval step, every query response, and every correction must be recorded, timestamped, and auditable. The platform must enforce the governance framework — for example, apply the actual active blocking-rule gates and any authority-defined exception/deactivation process; an internal approval cannot waive a binding error, and a return without the required approvals should be blocked from the filing gateway. The audit trail must be complete enough to reconstruct the entire history of each return: who prepared it, what validations were run, what warnings were dispositioned, who approved it, when it was filed, what queries were received, and how they were resolved.
The archive function is often overlooked but is critical. Regulatory returns, supporting documentation, query responses, and correction histories must be retained for the period required by the applicable rules — as specified in the applicable legal and approved retention schedule. The archive must be searchable and retrievable — an archive that stores documents but makes them difficult to find is not a control. The archive should also be linked to the bank's document management system, so that supporting evidence (spreadsheets, data extracts, approval emails) can be retrieved alongside the return itself.
8. End to end process
- Validate to green (or governed warning disposition). 2. Approve at tier with evidence. 3. File; reconcile receipt. 4. Log and triage queries. 5. Investigate with lineage. 6. Correct with impact analysis + re-approval. 7. Archive; analyse themes; fix lineage.
The end-to-end process is not linear — it is cyclical. The query received in step 4 may reveal a data-quality issue that requires a fix in the source system, which affects the next period's filing. The theme analysis in step 7 identifies patterns that inform the validation rules for the next cycle. The process is therefore a continuous improvement loop, with each cycle informing the next.
The quality of step 5 (investigation with lineage) is often the differentiator between a strong and weak submission governance framework. Lineage means tracing the queried value from the FINREP cell back through the reporting system, through the data warehouse, through the source system, to the original transaction. Without lineage, the bank cannot determine whether the error is a data issue (the source data is wrong), a transformation issue (the data is correct in the source but transformed incorrectly), or an interpretation issue (the data is correct but the bank's application of the rule is wrong). Each root cause requires a different fix, and the fix must be validated through the same lineage chain to confirm that it resolves the issue.
9. Controls and risks
| Risk | Control | Evidence |
|---|---|---|
| Filing on red | Technical submission blockers | Blocker logs |
| Warning waving | Warning-disposition rationale requirement | Disposition records |
| Query ageing | SLA timers + escalation | Age compliance |
| Cell-fix corrections | Lineage-fix mandate | Fix-type analytics |
| Receipt mismatch | Hash/counts reconciliation | Receipt logs |
| Repeat queries | Theme analysis and root-cause tracking | Repeat-rate reports |
10. Practical examples
A: Warning ignored (fictional): 3m variance warning waved as "timing" without evidence; query arrives; investigation finds mapping error affecting 3 families; triple resubmission. The warning had been flagged by the validation engine as a variance between the current period's value and the prior period's value, with no corresponding explanation in the source data. The preparer dismissed it as a timing difference without checking the source data. The investigation revealed that a mapping change in the loan origination system had caused 300 million of exposures to be classified incorrectly across three FINREP templates. The correction required resubmission of all three returns, with an impact analysis showing the effect on key metrics (NPE ratio, provision coverage, staged exposures). The query-response timeline was 15 business days under an explicitly assumed agreed20-business-day query deadline for this fictional case, but the root cause was entirely avoidable. Lesson: warnings are queries in advance — evidence each one.
B: Receipt mismatch (fictional): filed file ≠ confirmed receipt (truncated upload); deadline missed technically; escalation protocol + refile + supervisor notice within hours limits damage. The bank's filing gateway accepted the file but the upload was truncated during transmission, resulting in a partial return being received by the supervisor. The bank's internal reconciliation identified the mismatch within two hours — the filing identifier, reported template set and acceptance status did not match the intended submission; a checksum is compared only if the gateway provides one. The escalation protocol was activated immediately: the supervisor was notified, the file was re-transmitted, and the correct receipt was confirmed within four hours. Prompt disclosure supports handling the incident, but does not guarantee waiver of consequences. The lesson: receipt reconciliation is not optional — it is the final control before the regulatory deadline.
10.3 Worked example: correcting source classification (fictional)
A reviewer identifies 300m of modified loans with incomplete forbearance flags. Trace the contractual concession, borrower financial difficulty, non-performing criteria and IFRS 9 credit-risk change separately. Forbearance does not automatically mean NPE or Stage 2, and COREP does not universally report IFRS stage. The impact assessment identifies the actually affected returns and periods.
Suppose independent credit assessment determines an additional 12m ECL under IFRS 9: Dr impairment expense 12m / Cr loan-loss allowance 12m. Net loans and retained earnings decline 12m before tax; gross principal is unchanged. The allowance increase is not produced by changing a reporting flag alone. Reconcile the revised allowance to the GL, remap relevant FINREP and disclosure facts, apply any prudential adjustment under its own rules, reapprove and resubmit as required. The query response includes the root cause, calculations, affected periods, corrective action and future monitoring.
11. Diagrams
Figure 1. Submission governance.
Figure 2. Supervisory query types.
Figure 3. Controlled correction.
12. Tables
Table 1 — Approval tiers (illustrative)
| Change/return | Approver |
|---|---|
| Routine return, green validation | Head of reporting |
| Material judgement/overlay | CFO + committee |
| Correction (immaterial) | Head with impact note |
| Correction (material) | CFO + audit committee visibility |
| Late filing | CFO + supervisory notification |
Table 2 — Query SLA extract (illustrative)
| Step | Target |
|---|---|
| Acknowledge | 2 business days |
| Investigate + respond | 10 business days |
| Remediate lineage | Dated plan ≤ 90 days |
| Root-cause fix | Track to completion, verified in next cycle |
13. Illustrative banking case study
The cell-fix habit (fictional). An analyst repeatedly overwrites queried totals, making the return agree while leaving incorrect source mappings. The repair preserves the original and revised submissions, rebuilds the mapping, reprocesses relevant periods, independently reconciles results and follows the correction instructions. Fast query closure is not evidence of a durable fix.
14. BA, developer, tester and operations guidance
- BA: Specify validation rules, approval tiers, query SLAs and correction workflows per return family. Ensure that validation rules cover both taxonomy-level checks (structural correctness) and plausibility checks (data-quality reasonableness).
- Developer: Enforce applicable active-rule gates and permitted authority exception treatment; timestamp approvals; track queries with timers; version resubmissions. Build the query-tracking system with SLA timers that cannot be reset without authority.
- Tester: Blocker enforcement, deputy-approval paths, resubmission integrity, archive retrieval. Test that the system blocks submission when validation errors are present, and that the archive can retrieve any historical return with its full supporting documentation.
- Operations: Run submission like production (buffers, deputies, receipts); analyse query themes quarterly. Maintain a filing calendar with reminders at T-30, T-15, T-7, and T-1 before the regulatory deadline.
15. Common mistakes
- Filing on red under deadline pressure.
- Waving warnings without evidence.
- Cell-fixing queries instead of lineage-fixing.
- Missing receipt reconciliation (filed ≠ received).
- Query responses without remediation tracking.
- Celebrating fast query closure without tracking root-cause fixes.
- Setting internal deadlines too close to the regulatory deadline.
16. Key takeaways
- Validate green, approve tiered, file with receipt — every cycle.
- Queries are free consultancy — log, triage, remediate lineage.
- corrections need cross-family impact analysis and re-approval.
- Submission health metrics (timeliness, queries, revisions) govern the factory.
- Submission governance connects reconciled facts, controlled validation, accountable approval, filing receipts and evidence-based correction.
17. References and verification notes
- EBA reporting frameworks: applicable technical artefacts; remittance dates and national submission instructions must be taken from the governing return.
- ECB SREP methodology: supervisory assessment and measures.
- IFRS 9: credit-risk assessment and ECL, distinct from regulatory reporting flags.
- ECB SSM data-quality framework, PRA data-quality expectations, Fed FR Y-14 submission requirements, and RBI regulatory reporting guidelines provide jurisdiction-specific requirements.
- SLAs and tiers are illustrative training parameters; adopt approved policies.