Regulatory reporting is often described as the production of returns. That description understates the work. A reliable return depends on an agreed regulatory interpretation, a complete source population, controlled transformations, meaningful reconciliation and a review process that can challenge the result. Submission is the final operational step in a much longer chain.
For a bank or NBFC, a reporting error can arise even when the spreadsheet formula is correct. The wrong entity may be included, a product may be mapped to an outdated category, a late source may be omitted or a correction may reach one return but not another. These are process and data-governance problems as much as calculation problems.
A controlled reporting model therefore begins by asking what each figure represents and ends by retaining evidence of what was actually submitted. The following framework explains how to build that connection.
Establish the applicable reporting population
Create a catalogue of returns applicable to each legal entity and business scope. Record the authority, reporting period, reference date, frequency, submission channel and current instructions. Include ad hoc requests and material changes to existing returns. Do not assume a return is applicable merely because another lender files it.
RBI's 2026 supervisory-return directions separately address commercial banks and NBFCs. They provide the relevant starting points for scope, governance and filing requirements. [2] [3] Other institution categories and specialised activities may require different directions or additional reporting obligations.
Within each return, document whether the scope is standalone, consolidated, domestic, overseas or another defined perimeter. These distinctions affect source selection and eliminations. A group-wide data warehouse does not remove the need to explain which entities and transactions a particular report includes.
Convert instructions into a reporting specification
A reporting specification connects each required field with its meaning and source. Include definitions, units, currencies, sign conventions, reference dates, aggregation rules and exclusions. Record the treatment of missing or conflicting information. The specification should be understandable to both reporting specialists and source-system owners.
Identify fields requiring judgement. Examples include regulatory classification, related-party identification or the treatment of unusual transactions. State who owns that judgement, what evidence supports it and when it needs independent review. An undocumented assumption should not become a permanent mapping simply because it was used last quarter.
Version the specification. When a definition changes, identify the reporting periods affected and whether historical data needs restatement. Keep the previous version so an earlier return can still be reconstructed under the instructions used at that time.
Treat source delivery as a controlled handoff
Every source delivery should carry a period, extraction time, source-system identifier and responsible owner. Preserve the original extract before transformations. Record row counts, key financial totals and any known limitations. These controls make it possible to distinguish an incomplete delivery from an error introduced later.
Check whether the delivery contains the expected population. A valid file can still exclude a branch, product or late-booked transaction. Compare coverage with independent inventory or accounting information where possible. A file-format check alone establishes very little about completeness.
Define replacement rules. If a source owner sends a revised file, the reporting team should know which version is authoritative and which downstream calculations must be rerun. Keeping both files without a clear supersession relationship invites inconsistent results.
Reconcile at more than one level
Reconciliation should compare figures that are expected to agree on a defined basis. Start with financial totals, then examine important dimensions such as product, branch, currency and asset classification. A total can match while substantial errors offset within its components.
Explain legitimate differences. Reporting instructions may use a basis that differs from the general ledger, for example because of scope, timing or presentation. A reconciliation bridge should identify these differences and show their amounts. “Regulatory adjustment” is too vague to support independent review.
The RBI reporting directions address reconciliation, source records and data quality. [2] [3] An effective implementation makes the reconciliation evidence available with the return, rather than leaving it in an unrelated working folder. Unresolved material differences should remain visible to the approver.
Separate preparation, checking and approval
The preparer assembles sources, performs calculations and explains exceptions. The checker challenges the basis, tests material transformations and assesses whether the evidence supports the result. The approver decides whether the reviewed version is ready for submission within the institution's authority framework.
These responsibilities should be reflected in access controls and actual practice. A nominal checker who can only see the final PDF cannot meaningfully inspect the source-to-report chain. Equally, a checker editing the final output without a recorded return to the preparer can obscure responsibility for changes.
Use a review record that identifies the exact version examined, questions raised, responses received and unresolved matters. A generic “checked” label is insufficient when the output may have changed afterwards. Material revisions should trigger proportionate re-review.
A worked example: a portfolio reconciliation difference
Suppose a hypothetical regulatory return reports a loan portfolio of 980 units, while the relevant accounting control total is 1,000 units. The team initially assumes the difference relates to accrued interest. A more detailed reconciliation shows 12 units of legitimate presentation differences and eight units of accounts omitted from an operational extract.
The correct response separates the two causes. The 12-unit difference receives a documented bridge supported by the approved reporting definition. The missing accounts require a corrected extract, rerun calculations and a review of other returns using the same source.
A manual addition of 20 units would make the headline total agree but could misstate product, classification and maturity breakdowns. Reconciliation should resolve the cause of a difference, not merely eliminate the visible mismatch.
Control manual adjustments and spreadsheet logic
Manual adjustments are sometimes necessary, particularly during transitions or when source systems lack a required attribute. Each adjustment needs a reason, amount, affected fields, supporting evidence and approval. Record whether it is a one-time correction or a recurring dependency requiring a permanent fix.
Protect calculation logic from accidental edits. Maintain a controlled template, identify input and formula areas, and compare material changes between versions. For important calculations, independently recompute selected results rather than checking only that formulas exist.
Avoid treating automation as proof of correctness. Automated mappings can apply the same wrong rule consistently across thousands of records. Validation should address the business meaning of the rule, the source attributes it uses and the treatment of boundaries and exceptions.
Keep filing evidence distinct from internal approval
An internally approved working paper is not the same object as a submitted return. Preserve the actual submitted file or payload, submission time, submitting user and available portal evidence. If a portal transforms or validates the data, retain relevant responses and error messages.
Distinguish receipt, validation, rejection and acceptance according to the actual submission process. A receipt may confirm transmission without confirming every substantive check. Use precise status descriptions rather than one broad “filed” label.
When correcting a return, retain the original submission and explain why a revised version was necessary. Identify linked returns or disclosures that may also be affected. A correction should improve the current record while preserving the institution's ability to explain the earlier one.
Prepare for exceptional reporting conditions
Reporting processes need to work when a key employee is unavailable, a source is delayed or a submission channel is disrupted. Maintain deputies, documented instructions and appropriately controlled access. Rehearse recovery from a failed extraction or an unusable working file.
Any alternative submission arrangement must follow the relevant authority's instructions. An internal email sent before the deadline does not automatically satisfy an external filing requirement. Preserve communications and the basis for any contingency action taken.
The Basel risk-data principles emphasise reliable aggregation and reporting, including under stress. Their formal scope should not be assumed to cover every NBFC, but they provide useful background for thinking about resilient reporting processes. [1]
Check cross-return consistency
Some figures appear in several returns with different presentation or scope. Maintain a small set of cross-return checks for important shared measures, and explain expected differences. This can reveal a correction applied to one output but omitted from another.
Assign ownership for investigating mismatches across teams. A finance return and a risk return should not each be approved on the assumption that the other team has resolved the difference. Retain the agreed explanation with both reporting records.
Use reporting incidents to improve the system
Track late sources, reconciliation differences, review findings, portal rejections and post-submission corrections. Classify root causes rather than counting incidents alone. Repeated mapping errors suggest a different remedy from recurring failures in owner availability or data extraction.
Review the consequences across the reporting catalogue. A defective customer classification may affect several returns, management reports and capital calculations. Closing the incident after fixing one file leaves the wider problem unresolved.
A strong reporting process can answer four questions for every material figure: what does it mean, where did it come from, how was it changed and who accepted the evidence? When those answers are available, the institution can investigate differences faster and explain its submissions with greater confidence.
PRIMARY REFERENCES
Sources & further reading
Primary-source references checked on 12 October 2026. Follow the relevant authority’s current text for applicability, amendments and commencement dates. International standards provide context and are not automatically identical to domestic requirements.