Chapter 083: From Source Data to Regulatory Return

Section 17: Regulatory Reporting Foundations and Delivery · Chapter 083 of 100

A regulatory return is a controlled view of bank records. Its values must be complete for the required perimeter, calculated under the right rule version and reproducible from retained inputs. A filed number that happens to look reasonable is insufficient if nobody can explain how it was produced.

1. Chapter opening

The process starts with an obligation, not a template. Identify the reporting entity, consolidation perimeter, reference date, measurement basis, currency, required data points and remittance deadline. Then capture accounting and contract records, reconcile them, calculate required measures and generate the filing. Submitting the file adds receipt and acceptance checks; it does not prove the underlying records were correct.

2. Learning objectives

1. Trace a fact from transaction and contract through subledger, general ledger, reporting data and submission.
2. Distinguish a source-data correction, ledger journal, prudential calculation and reporting adjustment.
3. Reconcile accounting balances to prudential exposures without assuming they equal RWA.
4. Preserve versions, adjustments and evidence for a complete rerun.
5. Handle missing records, late feeds and rejected submissions without hiding exceptions.

3. Business context

A loan system knows the contract, borrower, schedule and collateral. The general ledger records recognised balances by account. Risk engines add default, exposure and capital attributes. None alone supplies every reporting field. Reporting integrates these sources under common identifiers and dates, while accounting and risk owners remain accountable for the inputs they supply.

A one-to-many join can multiply a loan when it has several collateral records. A left join can silently discard a counterparty classification. An adjusted GL balance can disagree with a frozen loan extract. These are production defects, not differences that a reporting team may erase by changing a total.

4. Finance and accounting view

4.1 A loan from booking to return (fictional, millions)

A bank originates a loan of 10 and credits the borrower's deposit account: Dr loan asset 10 / Cr customer deposit liability 10. If the customer pays an external beneficiary, settlement is Dr customer deposit liability 10 / Cr settlement cash 10. The loan booking and external settlement are separate balanced entries; a customer instruction or network acknowledgement is not cash settlement.

An IFRS 9 ECL assessment produces an allowance of 0.3: Dr impairment expense 0.3 / Cr loan-loss allowance 0.3. The gross loan is 10 and net accounting value 9.7. The credit system, GL and reporting mart must preserve both measures. A reporting classification does not independently create the allowance journal.

For a deliberately simple standardised prudential illustration, assume exposure value after relevant specific provisions is 9.7 and the applicable risk weight is 100%, with no eligible mitigation or other adjustment. RWA =9.7. This is not an additional loan asset and has no separate GL posting. At an assumed 8% total capital minimum, the exposure contributes 0.776 to a capital requirement before buffers and other applicable requirements; that is a capital amount, not an annual expense or funding interest saving.

4.2 Off-balance-sheet and mitigation records

An undrawn commitment needs a separate register even when no principal loan asset exists. A nominal commitment of 5 with an explicitly assumed applicable 40% credit conversion factor produces 2 of exposure before risk weighting. The factor is a rule classification, not a bank-selected default probability. Guarantees and collateral require eligibility, legal certainty, value, maturity and currency records. Do not apply both protection methods to the same protected amount or confuse the simple collateral substitution method with the comprehensive haircut method.

Expected loss under a simplified PD × LGD × EAD estimate is also not RWA. Under internal ratings-based capital treatment, use the prescribed capital function and adjustments. The return receives each measure in its intended data point.

4.3 Reporting adjustments

A source correction repairs the underlying record. A journal changes recognised accounting balances. A prudential adjustment changes the regulatory measure according to its rule. A reporting-only adjustment repairs a mapping or classification without creating a transaction. Record type, reason, amount, author, approver, affected facts and reversal or remediation plan for each adjustment. Reconcile ledger-affecting adjustments to the close and all dependent reports.

5. Product and customer impact

Capture reporting-critical fields at origination: borrower sector, legal entity, product, currency, maturity, reset terms, commitment status and collateral linkage. The customer should not have to supply the same facts repeatedly because internal identifiers fail to join. Apply access and confidentiality controls to granular records and use only authorised reporting channels.

6. Regulatory and supervisory view

Local reporting law and instructions define enforceable scope, frequencies and measurements. Basel standards provide an international prudential framework rather than one universal return. For European granular credit data, the ECB distinguishes the binding AnaCredit regulation from its explanatory manual and Q&As. Technical validation success is not an opinion that the bank's legal interpretation or source accounting is correct.

7. Systems and data view

Retain a run manifest containing reference date, entity hierarchy, source extract identifiers, record counts and totals, rulebook version, engine version, mapping version, technical taxonomy, validation rules and adjustment register. Trace each material reported fact back to its contributing records and transformations. Preserve rejected records and explicit exclusions so the audit can test completeness, not merely recreate the accepted rows.

8. End to end process

1. Confirm the obligation and required scope.
2. Capture immutable source extracts and verify completeness against registers.
3. Reconcile subledgers to GL, including suspense, accrued interest, allowance and settlement timing.
4. Apply classifications, exposure rules and derived calculations with pinned versions.
5. Aggregate by the prescribed dimensions and reconcile to source control totals.
6. Generate the required filing format and validate structural, arithmetic and plausibility checks.
7. Resolve errors and document warnings; obtain accountable approval.
8. Transmit, confirm receipt and final acceptance, then retain the exact filed artefact.
9. Investigate queries and corrections across affected periods and return families.

9. Controls and risks

10. Practical examples

Missing collateral linkage (fictional). The reporting mart cannot join 100 loan records to their collateral register. Keep the exposure population complete, apply the applicable conservative treatment if protection is unproven, escalate the data break and repair the linkage. Never discard the loans to make the join pass.

Late ECL journal (fictional). Finance posts a 2m top-up after the first snapshot. Create an approved new close version, reconcile the allowance and retained earnings effect and rerun all dependent facts. Do not update one financial template while leaving the capital bridge on the earlier allowance.

11. Diagrams

Figure 1. Source data to regulatory return. Figure 2. Regulatory lineage: record to cell. Figure 3. Regulatory return correction control.

12. Tables

13. Illustrative banking case study

A correct total with wrong lineage (fictional). A mapping duplicates collateral records and overstates secured exposure. A manual cell adjustment restores the expected RWA total but obscures the defect. Independent review re-performs the join at exposure identifier level, fixes allocation and reruns past dates. A matched final total cannot validate an incorrect calculation chain.

14. BA, developer, tester and operations guidance

• BA: Specify input fields, grain, joins, legal definitions, adjustments and reconciliation equations.
• Developer: Enforce stable identifiers, explicit exclusions and deterministic versioned runs.
• Tester: Use hand-worked balanced transactions, duplicate joins, missing attributes and reruns after approved journals.
• Operations: Own exceptions, deadlines, approval evidence and acceptance confirmation.

15. Common mistakes

1. Using a template as the only specification.
2. Treating RWA or a capital requirement as an accounting asset or annual expense.
3. Calling PD × LGD × EAD an IRB RWA calculation.
4. Double-counting eligible protection or dropping unmatched exposures.
5. Fixing a return cell without fixing and rerunning the source chain.
6. Assuming receipt means final acceptance.

16. Key takeaways

A source-to-return process needs completeness, reconciliation, rule-correct measurement and retained lineage. Accounting entries and prudential calculations serve different purposes. Reproducing the filed result is necessary; independently testing its definitions and inputs is equally necessary.

17. References and verification notes

• Basel credit-risk framework: exposure, credit conversion and mitigation concepts; local law determines applicable treatment.
• ECB AnaCredit: binding regulation, manual, validation and plausibility roles.
• IFRS 9: impairment and financial-instrument accounting.
• All transactions, factors chosen for examples and internal workflows are training illustrations.