How Often Data Really Gets Updated (Not When You Think It Does)

The conversation usually goes off-track on a slide that looks perfectly harmless.

It’s a collections strategy review.

On the screen: a bureau-based roll-rate chart, neatly labelled:

“Portfolio snapshot – December 2025, retail unsecured”

Someone in the room asks what sounds like a minor clarification:

“This is as of December-end… meaning what, exactly? Month-end closing? First week of January? Latest pulls?”

The analytics lead says:

“Bureau data is updated fortnightly, so this is effectively current. We’re using the latest available file.”

The CRO pushes one step further:

“Latest available as of when? Right now, or as of when we extracted it? And how far behind the customer reality are we in this view?”

There’s a pause.

Then three different answers surface:

·         From Collections: “Operationally we work as if it’s T+15 at worst.”

·         From Risk Analytics: “The bureau says they process files and make them available within their service window.”

·         From IT: “Our warehouse refreshes this mart once a month. This cut is from the last scheduled load.”

None of those sentences is wrong.

None of them really answers the question either:

“For a typical customer in this segment, when we look at ‘today’s’ bureau view, what day of their life are we actually seeing?”

The slide stays on the screen.

Someone suggests parking the detail and returning to the main agenda.

Three months later, during an internal model validation and a regulatory interaction, the same question comes back, in less friendly language:

“Can you explain, for your bureau-based models and monitoring,

what the effective lag is between an event in the customer’s life and its appearance in the data you use?”

At that point, “fortnightly updates” is no longer an adequate answer.

 

The belief: “Fortnightly / regular bureau updates mean our data is basically current”

If you strip away the formal language, the working belief inside many lenders sounds like this:

“Bureaus now get data frequently.

RBI has pushed for timely reporting.

Our own systems pull fresh data regularly.

For all practical purposes, the credit data we see is up to date.”

You hear this belief embedded in everyday phrases:

·         “Bureau is fairly real-time now; the lag is not a big issue.”

·         “We are compliant on RBI timelines, so the ecosystem is in sync.”

·         “Our dashboards use the latest available bureau view.”

It feels reasonable, because:

·         Regulatory circulars talk about fortnightly or better reporting.

·         Vendors talk about near real-time rails.

·         Internal teams don’t have the appetite to debate “two weeks vs three weeks” in every meeting.

So the organisation behaves as if:

·         There is one concept called “current data”.

·         “Latest available” is an adequate description.

·         Any residual lag is a rounding error.

What actually happens between a customer missing an EMI and that behaviour showing up in the data you use is a chain of events:

·         Operational posting

·         Internal systems

·         Outbound bureau files

·         Bureau processing

·         Your inbound usage

Every part of that chain has its own cadence and exceptions.

The gap between “what the regulation intends”, “what the contracts promise”, and “what we actually analyse with” is larger (and more uneven) than most slide decks suggest.

 

What “how often data gets updated” looks like in reality

If you follow one missed EMI all the way through, the story is less clean than “fortnightly updates”.

Imagine a salaried customer missing a personal loan EMI on 5 January.

Here’s a simplified, but not unrealistic, path.

1. Posting and internal recognition: not instantaneous

·         The EMI due on 5 January is missed.

·         Depending on your core banking or LOS setup, the system may:

– Flag the account as overdue on the due date,

– Or reflect it after an overnight batch.

·         Internal collections may start dialler activity within a few days.

So inside your own house:

·         Operationally, you “know” about the delinquency within T+1 to T+3.

·         It shows up in internal DPD reports quickly.

But nothing has left your perimeter yet.

2. Inclusion in the next bureau reporting file: batched, not per-event

Most institutions send bureau updates in batches, not per account.

A common pattern:

·         Monthly or fortnightly flat files generated from the core or a staging mart.

·         Cut-off dates aligned to month-end or a recurring cycle (e.g., 1st & 16th).

If your bureau reporting job is scheduled for:

·         The 15th and 30th/31st of the month,

·         And the cut-off for the mid-month file is “position as of 14th”,

then:

·         A 5 January missed EMI will be captured in the file for 14/15 January (if your extraction logic is tight).

·         Any operational delays, reconciliation issues, or failed jobs can push it further.

In real process reviews, you often find:

·         At least one missed or partially failed file in the last 12 months.

·         Ad hoc re-runs that are not fully documented.

·         Corner cases (e.g., restructures, charge-offs) that get included in later cycles.

So the first time that missed EMI is eligible to appear in a bureau’s system might be 7–14 days after the event.

3. Bureau processing and availability: a service window, not a stopwatch

Bureaus themselves have:

·         Ingestion, validation and reconciliation processes.

·         Quality checks.

·         Occasional rejections back to the lender for errors.

Contracts and service descriptions talk about processing within X hours or Y days.

In normal times, bureau updates are reasonably fast.

But in aggregated practice:

·         A file sent on 15 January may be fully processed and visible in bureau systems by, say, 17–20 January.

·         Any data-quality queries raised by the bureau can push specific records into exception queues.

From the lender’s point of view:

·         “We reported this in the 15 January cycle” feels like the end of the story.

·         The question “when was it visible to others?” is rarely tracked.

4. Your own pull and internal warehouse refresh: another lag

Now think about how you use bureau data:

·         For decisions: fresh pulls at the point of application.

·         For monitoring: periodic extracts or APIs into your data warehouse.

·         For analytics: versions stored in marts refreshed on a schedule.

For monitoring and analytics, common patterns are:

·         Monthly or fortnightly bureau snapshots pulled for your portfolio.

·         Internal data marts refreshed on T+3 to T+10 after receiving the bureau file.

So when your analytics team presents:

“Portfolio snapshot – December 2025”

on a slide in mid-January, the underlying reality may be:

·         Bureau data position as of 31 December.

·         Extracted and processed into your warehouse by 10–12 January.

·         Combined with internal data and frozen into a cube that then feeds MIS.

By the time the slide is shown in late January:

·         You might be looking at a bureau view that is effectively 20–30 days behind certain events.

·         Internal data is fresher; external view isn’t.

No single step feels irresponsible.

Together, they mean that “how often data is updated” is a layered answer, not “fortnightly”.

 

Why this stays invisible (and why “fortnightly” survives as a comfort phrase)

If the lags are this real, why doesn’t the belief collapse?

Because the way we talk about time in meetings hides the detail.

Dashboards rarely force you to confront “as-of” dates

In many institutions, risk and portfolio MIS has:

·         Titles like “December Portfolio Snapshot”

·         Small “as of” footnotes:

– “Data as of 31-12-2025”

– “Source: warehouse mart refreshed 10-01-2026”

In busy meetings:

·         People look at the title and the shape of the chart.

·         Almost nobody actively asks, “And today is what date?”

So the mental shortcut becomes:

“We’re looking at last month. That’s fine.”

The difference between:

·         “December data we extracted on 2 January” and

·         “December data we extracted on 20 January”

never surfaces explicitly.

The as-of discipline that exists in trading or ALM discussions tends not to apply with the same rigor to credit information.

Regulatory timelines are treated as operational SLAs

RBI’s expectations on timeliness of credit data reporting are often interpreted internally as:

·         “If we are compliant with reporting timelines, the system is synced enough.”

So the logic becomes:

·         “We report by the required cut-off.”

·         “Bureaus are supposed to update within their timelines.”

·         “Therefore, data refreshes are not a material uncertainty.”

It’s a short step from:

·         “We meet the minimum expectations.”

to:

·         “The data is current for all practical purposes.”

That last step tends not to be examined closely, because it would open up questions about internal cadences that are harder to answer.

Nobody owns “data freshness” as a risk variable

You can find owners for:

·         Data quality.

·         Regulatory reporting correctness.

·         Model performance.

It’s harder to name someone whose job description clearly says:

“You are responsible for making sure we know, for key decisions and monitoring views, how old the data actually is relative to customer reality.”

So the topic lives in gaps:

·         IT and data teams know batch schedules.

·         Risk teams know which data sources models use.

·         Operations knows when files go out.

Putting that together into:

·         “Effective lag distribution for this portfolio is X–Y days”

requires someone to care enough to join the dots.

Usually that only happens after:

·         A model fails for reasons nobody can explain,

·         Or a regulator asks a pointed question about recency.

 

How more experienced teams think about “how often” without getting lost in technicalities

The institutions that handle this quietly better don’t try to make data real-time everywhere.

They do a few practical things.

They define “data currency” in plain language for key use-cases

Instead of saying “fortnightly” and stopping there, they write down things like:

·         “For bureau data in retail origination, we assume:

– Decision view at application time reflects events up to T–7 to T–21 days earlier for most customers.”

·         “For bureau-enriched portfolio monitoring dashboards, we assume:

– Views are one full month behind operational reality by design.”

They don’t pretend this is precise.

They use it as a working statement.

This allows them to be honest when someone asks:

“Could this behaviour have changed materially since the data point we’re looking at?”

Instead of:

·         “Data is updated regularly, it should be fine,”

they can say:

·         “Our best view is as of [date]; for this segment, a lot can change in 30 days, so we treat that as a limitation.”

That sounds simple. It isn’t common.

They track freshness as a small but explicit metric

In one bank’s internal risk report, a new line appeared in the annexure for each key data source:

·         “Average lag between event and availability in analytics mart:

– Internal DPD: T+1 to T+2

– Bureau DPD: T+14 to T+30

– AA cashflows: T+0 to T+3 (once consent given)”

The numbers weren’t perfect.

But they existed.

Every quarter, the data team updated them based on:

·         Batch logs.

·         File-transmission timestamps.

·         Mart refresh times.

No one pretended this was front-page content.

It was a small piece of hygiene.

But when a senior leader, or later a regulator, asked “how often does this data actually get updated?”, the answer was more than “fortnightly”.

They align decision design with realistic data cadence

Rather than wish for real-time everywhere, they accept trade-offs.

For example:

·         For pre-delinquency and EWS, they rely more on internal behavioural data, where lags are shorter and fully under their control.

·         For structural risk assessment (e.g., total leverage, multi-lender behaviour), they use bureau views and clearly label them as “position as of [month]”.

·         For daily performance dashboards, they avoid mixing sources with very different lags into a single “current” view that gives a false sense of precision.

In one NBFC, after mapping real cadences, they made a small but important decision:

·         Portfolio reviews would stop using phrases like “as of today” for bureau-enriched charts.

·         All bureau-based charts would carry a visible “as of” date in the title.

·         Decision memos relying on such charts had to include one explicit line on the timeliness limitation.

It didn’t change the data.

It changed how people talked about it.

They treat “how often” as something that can be improved, but not solved once

Rather than a one-time “we’ve upgraded to fortnightly reporting” story, more experienced teams view cadence as ongoing work.

Examples:

·         Moving from monthly to bi-monthly or weekly bureau reporting where operationally feasible.

·         Reducing internal warehouse lags from T+10 to T+3 for critical marts.

·         Setting up simple monitors that flag when a scheduled bureau file or mart refresh has not happened on time.

None of this sounds strategic.

But when data stops being refreshed and nobody notices for weeks, strategic conversations are built on stale foundations.

 

A quieter way to hold the question “How often does our data get updated?”

It’s tempting to keep repeating:

“Bureaus are updating data regularly now.

RBI has pushed for timeliness.

We pull the latest available view.

For all practical purposes, our data is current.”

If you stay with that, you’ll continue to:

·         Use phrases like “as of today” on slides that are effectively referring to last month.

·         Assume that model performance issues are primarily about inputs and design, not about staleness.

·         Discover your real data lags only when someone outside the institution forces the issue.

If you accept that:

·         Every step from customer event → your core → outbound file → bureau → inbound view → warehouse → deck introduces its own delay,

·         Different portfolios have different effective cadences,

·         And that “fortnightly” is a regulatory minimum, not a description of your analytical reality,

then the question changes.

It stops being:

“Are we compliant and connected to bureaus frequently enough?”

and becomes something more grounded:

“For the decisions and views that matter most to us,

what day in the borrower’s life are we actually looking at when we say ‘today’ –

and are we comfortable with that gap, knowing we chose not to see the rest?”

For many teams, the first honest answer is “we’re not sure”.

The work is not to chase real-time everywhere.

It’s to make sure “we’re not sure” doesn’t stay the permanent state of affairs.