Enterprise platforms · Banking
Regulatory reporting system for banks
We build regulatory reporting systems for banks: governed data feeds, report definitions held as rules, validation and reconciliation to the ledger, lineage from every figure back to its source, and a review and sign-off workflow before submission. It replaces spreadsheet assembly of returns with one controlled process that can absorb new reporting requirements, and you own the code.
Requirements pack · Banking finance
Bank reporting and controlling requirements pack
A requirements pack for regulatory reporting, treasury and liquidity reporting, and management controlling systems in a bank: data, definitions, calculations, validation, lineage, close and governance.- 01Eight requirement areas shared by regulatory, treasury and controlling reporting.
- 02What to ask for on data definitions, lineage and reconciliation.
- 03Close, sign-off and change-management items auditors check.
- 04Seven questions to put to any vendor or development partner.
Free download
Get it on screen in a few seconds.
What the system does, module by module.
- 01
Regulatory data layer
A governed data store that collects balances, positions, exposures, customers and transactions from source systems with a single definition for each data element. - 02
Report definitions as rules
Each return described as data, with its cells, mappings and calculations, so a regulatory change is an edit and a test, not a rewrite. - 03
Calculation engines
Capital, liquidity, large exposure, credit risk and other calculations that the returns require, implemented once and reused across reports. - 04
Validation
Regulator validation rules, cross-report consistency checks and tolerance tests run before review, with failures listed by owner. - 05
Reconciliation to the ledger
Report totals reconciled to the general ledger and to prior submissions, with differences explained and attached. - 06
Lineage and drill-down
From any cell to the calculation, the data elements, the source system and the original records, for the reviewer and for the regulator's questions. - 07
Review and sign-off workflow
Preparer, reviewer and approver steps with comments, evidence and an immutable record of who approved what. - 08
Submission
Output in the format and channel the regulator specifies, such as the supervisory portal or XBRL where required, with acknowledgements stored. - 09
Resubmissions and change management
Handling of corrections, versioned reporting rules and a calendar of upcoming changes with the work each one needs.
Reference architecture.
Standards and interfaces
What we design against.
- BCBS 239
- The Basel Committee's principles for risk data aggregation and reporting: governance, data architecture, accuracy, completeness, timeliness and adaptability.
- Basel capital and liquidity frameworks
- The calculation rules behind capital adequacy, leverage, liquidity and large exposure returns, as implemented locally.
- Regulator reporting templates and rules
- The returns, definitions and validation rules published by the bank's supervisors, such as the HKMA in Hong Kong.
- XBRL and taxonomies
- Machine-readable reporting where regulators require it, for example the EBA reporting framework for COREP and FINREP in the European Union.
- IFRS and local GAAP
- Accounting bases that the figures and reconciliations must agree with.
- Data protection and confidentiality
- Controls on access to customer-level data used in returns and on its retention.
Data model
The core entities.
- Data element
- Business definition, source system and field, owner, quality rules and the reports that use it.
- Report and cell
- Return identifier, cell reference, definition, mapping and version.
- Calculation
- Inputs, formula or rule, output and the run that produced it.
- Validation result
- Rule, outcome, tolerance, owner and resolution.
- Reconciliation
- Report total, ledger total, difference and the explanation attached.
- Submission
- Version submitted, format, channel, time, acknowledgement and any resubmission.
- Sign-off record
- Preparer, reviewer and approver, time and evidence reviewed.
When custom development is the right call.
Controls designed in, not added later.
Controlled change to rules
Report definitions and calculations change only through reviewed, tested, versioned releases that take effect on a stated date.Immutable submissions
Every submitted return is stored exactly as filed, with its inputs, so it can be reproduced and defended.Role-based access
Preparers, reviewers and approvers are separate, and customer-level data is visible only where needed.Lineage integrity
Data movement between systems is logged, and a break in lineage is flagged before a return is submitted.Availability at deadlines
Capacity and recovery planning around submission dates, with tested failover.
From discovery to a system you run.
- 01
Return inventory and data review
We list every return, its owner, sources and manual steps, and assess data quality for the elements most used. - 02
Data layer and definition design
The data elements and the definition of each return are agreed with finance, risk and the report owners. - 03
Build returns in priority order
Returns are built from highest risk or effort, with each reconciled to the ledger and to the last submission. - 04
Parallel submission preparation
Each return is prepared in both the old and new process, and differences are explained before the first live submission. - 05
Cut over and maintain
The new process takes over return by return, and regulatory changes become planned releases.
Relevant work
Where to see our work.
Common questions.
- Does this replace our regulatory reporting product?
- It can, or it can sit beside a product and supply the data layer, local returns and the sign-off workflow. We recommend a packaged product where one fits your regulator well.
- How do you keep up with regulatory changes?
- Reports are defined as data, with versions and effective dates. A change becomes an edit to definitions, tested against past data and released with the change calendar.
- Can regulators trace a figure to its source?
- Yes. Every cell links to its calculation, its data elements and the source records, so a question can be answered from the system rather than from memory.
- Does it support XBRL?
- Yes, where a regulator requires it. The report definitions map to the taxonomy, and the output is validated against it before submission.
- Who owns the code and the rules?
- You do. The code, the report definitions and the data stay yours.