Granular regulatory reporting: the next filing is a record, not a return

From returns to records

For decades, banks reported totals. The regulator saw the number, and the bank kept the detail behind it.

That arrangement is changing. Supervisors increasingly want the underlying data, as at the reporting date:

• each loan and each borrower
• each guarantor and each piece of collateral
• each exposure, with its status and history

With that, they build the aggregates themselves.

Regulators say as much in their own plans. The HKMA’s April 2026 letter on granular data reporting sets out a principle of “Report Once, Use Multiple”. A December 2020 BIS study of ten supervisors found that most were standardising their data or asking for more granular data.

Much of the industry conversation centres on data dictionaries and file formats. They are necessary, but anyone who has run a granular submission knows the harder work lies elsewhere. We frame it as the Record-Level Contract:

• Four things the regulator expects of every record: Code, Check, Trace and Tie.
• Three loads the bank carries that no specification mentions: Identity, Concurrency and Confidentiality.

It is the second list that most programmes underestimate.

Where granular regulatory reporting is live, or coming

Granular collection is no longer confined to Europe. Supervisors sit at three broad stages:

• Live: the Philippines (COCREE 2.0), Hong Kong (HKMA), the euro area (AnaCredit), Austria (OeNB), the United States (FR Y-14), India (CRILC and the CIMS warehouse) and Thailand (RDT). Canada and the UK already gather loan-level mortgage data, and Australia’s RBA takes loan-level securitisation data.
• Building: Canada’s new collection platform rolls out from August 2026. The ECB’s integrated framework is planned for 2031, subject to adoption of its regulation. Malaysia is modernising collection through Project STREAM.
• Early or undecided: the IMF has advised Uzbekistan’s central bank to start a SupTech programme. In the UK, the PRA is weighing broader granular collection against its cost.

Delivery models differ too. Most regulators receive record-level files from banks. Austria derives returns from a granular data model its banks share. Rwanda’s central bank pulls data directly from larger banks’ systems. Whichever model applies, the bank still owns the data and the corrections.

A country-by-country table is in the FAQ at the end of this article.

What regulators expect of every record: Code, Check, Trace, Tie

Four expectations recur across specifications. COCREE 2.0 spells out each one.

1. Code: the regulator’s language

• Values come from the regulator’s code lists. COCREE treats anything outside its List of Domains as an exception.
• Identifiers must be unique and stable over time. AnaCredit wants an LEI where one exists.
• The internal-to-regulatory mapping becomes owned, versioned reference data.

2. Check: validate before the regulator does

• Rules run on every record: field, record, cross-record and file. Typical examples:
  • “The format of this date should be YYYYMMDD.”
  • “This field shall be filled if IDType2 is provided.”
  • “At least one ID is mandatory if TIN is unavailable.”
• In COCREE, header counts must match the records sent.
• The regulator validates after filing. Anything missed comes back as an exception.

3. Trace: evidence for every change

• Every change needs an owner, a reason and a timestamp.
• COCREE signatories certify records and totals through a Control Prooflist. BSP Circular 1231 (March 2026) raised the bar on board oversight and penalties.

4. Tie: reconcile to what you still file

• Granular data and aggregate returns must agree. COCREE’s Appendix LI-1 ties exposures to selected FRP accounts.
• The HKMA proposes two to three periods of reconciliation before retiring a template. The ECB plans a year of parallel running for IReF.

Separate pipelines for COCREE and FRP mean monthly reconciliation breaks.

Hidden load 1 · Identity: the submission is a conversation

A template return is largely finished once it is filed. A granular submission starts an exchange with the regulator that can last for months.

A typical cycle:

1. The bank submits the file.
2. The regulator validates it and returns its exceptions.
3. Some records are rejected. Others are queried.
4. The bank corrects and resubmits the affected records.
5. Months later, the bank may be asked to revise a period it has already filed.

The rules of that exchange operate at record level:

• In COCREE, a correction (Submission Type 1) resends the full record for that subject and record type and replaces the earlier one. A field left blank in the correction becomes blank in the BSP’s data.
• In Luxembourg, AnaCredit formal errors have to be fixed within three working days of feedback, and the BCL can request corrections up to 24 months after the last error notification.
• In Germany, each affected reference date needs its own AnaCredit resubmission.
• For mortgage data, the FCA expects an account to keep the same transaction reference in every report.

That leaves four questions the reporting team must be able to answer for any record:

• Which version did we send, in which file, on which date?
• Was it accepted, rejected or queried, and with which error code?
• What changed in the correction, and who made the change?
• If we revise March today, what did March look like when we first filed it?

This is where a conventional reporting database falls short:

• It holds the current state of each record and overwrites it on every update.
• The regulator’s questions concern past states: as submitted, as rejected, as corrected.
• Those states multiply. Every submission, rejection, correction batch and revision creates a new version of the data, across every table, every period, for years.
• Teams fall back on full snapshots or hand-built history tables. Neither tells you who changed which record, or why.

The database knows where a record stands today. The regulator wants to know where it stood on filing day, and who has moved it since.

Hidden load 2 · Concurrency: many hands on one file

A template return usually has one owner and one workbook. A granular submission has many owners.

In a normal month:

• Credit operations fixes collateral and product codes.
• Finance corrects outstanding balances.
• Branches fill in missing borrower details.
• Compliance reviews the exceptions.
• A checker approves each table before the file is generated.

Often they are in the same tables at the same time, close to the deadline.

Spreadsheets and shared folders break down under that load:

• The last person to save wins.
• A half-applied batch of fixes leaves the file inconsistent.
• Nobody can say for certain which version went to the regulator.

A careful team can manage a few dozen template cells this way. Hundreds of thousands of records are another matter.

The work needs four guarantees, known to database engineers as ACID:

ACID belongs in the control framework, next to maker-checker. It keeps every correction whole and every edit isolated. On its own, though, it does not prove that the approved version is the one that was filed. That takes one more step, covered below.

Hidden load 3 · Confidentiality: personal data by design

An aggregate return contains no customer. A granular file contains all of them:

• names and tax identification numbers
• dates of birth and addresses
• links between borrowers, guarantors and directors

COCREE’s subject records carry exactly this information for every borrower. The reporting environment has quietly become one of the largest stores of personal data in the bank.

Regulators and lawmakers are clear about the stakes:

• The ECB says it takes every precaution with personal data in AnaCredit, and treats company names and addresses as confidential.
• COCREE files must be encrypted under the BSP’s Encryption Guide before they leave the bank.
• The Philippines’ Data Privacy Act requires organisational, physical and technical safeguards, and breach notification.
• India’s DPDP Act allows penalties of up to ₹250 crore for failing to take reasonable security safeguards.

Protection needs three layers:

1. At rest. All stored data is encrypted, with keys the bank controls.
2. In transit. Every hop is encrypted: source to platform, platform to user, file to regulator.
3. At column level. An analyst fixing a product code sees the loan with the tax ID masked; compliance sees both. The most sensitive columns can carry their own encryption keys.

One tension needs an early decision. The Identity load says keep every version; privacy law says keep personal data only as long as needed. Retention, access to old versions and physical deletion have to be designed together, because platform defaults will not get this right.

What the Record-Level Contract asks of technology

Taken together, the seven terms describe a specification:

• every state of every record kept, and retrievable exactly as it was (how our storage does this)
• an audit trail at record level: who changed what, when and why
• safe editing on the same data that validations and returns read
• a provable link between what was approved and what was filed
• access control and encryption down to the column

The building blocks exist, and they are open:

• Apache Parquet is an open, columnar file format. It compresses well and supports encryption by column, with separate keys.
• Open table formats such as Delta Lake and Apache Iceberg add a transaction log on top of Parquet files. That brings ACID commits, versioning and schema checks to low-cost object storage.
• Governed catalogs such as Unity Catalog add column-level access control, PII tags, lineage and audit history. Several of these features sit in managed editions, not the open-source release.

Combined, they form what is often called a governed lakehouse. The product matters less than the properties it gives you, and five of them carry most of the weight.

1. Versions: many, cheap and queryable

Every submission, correction and revision creates a new version of every table, each period, kept for years. Databases that update in place overwrite the filed state. Temporal tables help but are set up table by table, so teams fall back on full snapshots. Table formats version every commit and rewrite only the files that changed.

2. Auditability at record level

Regulators ask about records, not tables. Commit history logs who did what, and a change feed shows each row before and after. With one commit per correction batch, the audit trail lives in the data, not in email.

3. One governed copy

Many people making small edits near a deadline is a transactional workload. A relational database handles it better, because table formats detect conflicts per file or commit, not per row. The practical design pairs the two: a relational store for interactive corrections and maker-checker, and versioned tables for filed snapshots, history and lineage. The gap to close is the export-to-Excel loop.

4. Proof that what you filed is what you approved

ACID keeps each change whole. To prove what went to the regulator, link the file to the exact data behind it:

1. At approval, record the table versions or tag them by name.
2. Generate the file from those versions, never from the live tables.
3. Keep the file’s hash with the version numbers in the filing record.
4. Set version cleanup by policy. It is configurable, so align retention with your record-keeping rules and never remove a version a filing points to.

5. Access down to the column

Tag-driven masks let one table serve analysts and compliance. Parquet adds separate keys for the most sensitive columns.

Not every bank needs to move at once. Where volumes are modest and few people edit, temporal tables, a strict no-export rule and a disciplined filing log can cover much of the contract. The test is the same either way: can you produce any record as filed, with its history, on request?

BCBS 239 adds weight. Its principles asked for accurate, complete, timely and adaptable risk data more than a decade ago. In the Basel Committee’s November 2023 progress report, only two of the 31 banks assessed were fully compliant with all the principles. Granular reporting turns those principles into something supervisors test every period, record by record.

The record is the new return

For thirty years, the reporting team's job was to get the number right. In the granular era, the job is to keep every record right:

• through every version
• while many people work on it
• while it carries personal data

Banks that treat COCREE, GDR or AnaCredit as a new file format will meet the Record-Level Contract one rejection at a time. Banks that treat it as a new foundation will find their aggregate returns, audits and privacy obligations get easier too.

Three questions are worth asking now, wherever your regulator sits on the map:

1. Can we show any record exactly as it was on the day we filed it, and who has changed it since?
2. Can we prove that the file we sent was built from the version we approved?
3. Who in the bank can see a borrower's tax ID today, and why?