Fortnightly Credit-Data Updates: What It Really Changes

By the time the new requirement was discussed properly, the project was already marked “completed”.

Three months earlier, an RBI communication and follow-on bureau emails had landed saying that credit information should be updated at least fortnightly.

IT opened a JIRA, Ops updated the SOP, Compliance put a new row in the tracker:

·         “Fortnightly reporting – Implemented from 1st April” ✅

In the Q1 Board Risk Committee, the CRO got two lines on a slide:

“Frequency of reporting to CICs increased to fortnightly, as per guidelines.

Test files validated by all CICs. No pending issues.”

Nobody asked what that actually meant for:

·         DPD recognition

·         EWS triggers

·         Co-lending reconciliations

·         Collections sequences

·         How quickly external views would now react to missed EMIs

The quiet assumption in the room was simple:

“It’s the same file, just sent twice a month. This is an IT and Ops topic, not a risk topic.”

That belief feels harmless.

It’s also where the trouble starts.

Because what RBI and the CICs see, twice a month now, is not just more data.

It’s a faster mirror of your reality than many of your internal processes are ready to handle.

Early on, nothing looks broken:

·         The CIC acknowledgements are green

·         The compliance tracker is green

·         Headline GNPA is flat

The cost shows up later, in quieter places:

·         Back-book clean-ups because half-fixed accounts started surfacing more often

·         Co-lenders asking why their view and your view diverge mid-month

·         Inspection questions about why external data moved before internal dashboards did

·         Credibility drag when you keep explaining gaps as “timing differences” that never quite go away

None of that is visible in the fortnightly-reporting project plan.

 

The belief: “Same data, higher frequency – nothing fundamental changes”

In most institutions we speak with, the internal line sounds roughly like this:

“We were already reporting monthly. Fortnightly just means sending the same extract twice.

As long as the file is correct, it doesn’t change how risk or business work.”

It’s a reasonable reading if you stand in the hallway:

·         RBI wants more timely updates

·         CICs send test-file templates

·         IT and Ops align extract logic and scheduling

·         Compliance ticks off “regulatory requirement met”

From that distance, it really does look like:

·         One more job in the scheduler

·         One more entry in the SOP

·         The same DPD buckets and statuses, just more up-to-date

The problem is that bureau data is not just another return.

It’s a shared, externalised version of your portfolio.

When you make that version update twice as often, while your own internal risk and operations rhythm stays monthly or slower, you create new gaps:

·         External DPD and status can move before internal views do

·         Corrections and back-dated adjustments are exposed more quickly

·         Partners and other lenders see changes earlier than your own committees

Fortnightly reporting is not just a frequency change.

It is a quiet decision about how quickly the outside world sees your behaviour.

If you don’t treat it that way, you end up with:

·         More noise in disputes

·         More edge cases in reconciliations

·         More time spent explaining inconsistencies you designed into the system yourself

You are “compliant”. But you’re no longer fully in control of the story.

 

What actually changes when you move to fortnightly bureau updates

When fortnightly reporting lands in a large bank or NBFC, three shifts start happening below the surface. None of them look dramatic on day one.

1. External reality starts moving faster than internal dashboards

In one mid-sized NBFC, internal risk MIS on retail lending was still built on a month-end DPD snapshot:

·         Ageing tables as of last calendar day

·         Flow from 0–30 to 31–60 days, month-over-month

·         Vintage curves updated after the books closed

When fortnightly bureau reporting went live:

·         DPD changes mid-month started appearing in CIC reports

·         A customer who missed a payment on the 8th had their behaviour visible outside by the 15th

·         Partners and other lenders pulling reports mid-cycle saw a sharper picture than the lender’s own risk dashboard

Inside, the story of the portfolio moved monthly.

Outside, it moved twice as fast.

Nobody had planned that gap.

It came from treating frequency as a technical detail, not a design choice.

2. All the messy corners of your data suddenly get more sunlight

Most institutions carry some quiet data compromises:

·         A batch of legacy accounts where closure is tracked manually

·         A product where restructuring is captured in a free-text field

·         A co-lending pool where responsibilities for status updates are documented but fuzzy

·         Accounts where DPD corrections are done as one-offs by email between collections and Ops

Under monthly reporting, some of these differences were smoothed over:

·         By the time the file went out, operations teams had a few extra days to “clean” obvious mismatches

·         Timing differences could be absorbed into month-end adjustments

Fortnightly reporting cuts that buffer in half.

We saw one bank where:

·         A manual queue of closure and settlement adjustments was cleared “towards month-end”

·         After fortnightly reporting started, two bureau files per month went out with partial corrections

·         The same customer appeared with conflicting statuses in two consecutive cycles

Dispute volumes for “loan closed but still showing” did not explode overnight.

They rose steadily over two quarters.

The pattern wasn’t new.

The higher reporting frequency simply made it visible more often.

3. Your partners and competitors now see your behaviour at a different granularity

Fortnightly reporting doesn’t just change what the CICs see.

It changes what other lenders see when they pull a report.

That includes:

·         Co-lending banks looking at your shared portfolio

·         Competitors assessing the same customer you just restructured or rolled forward

·         ARCs and purchasers doing diligence on pools you may want to sell later

When your own internal processes, policies and MIS still think in monthly blocks, and bureau data is telling a more detailed story, you create space for:

·         Misunderstandings with partners: “Your file shows this account as X; our internal status still shows Y.”

·         Different readings of behaviour: another lender sees a fresh delinquency you still think of as “within normal bounce range”

·         External parties forming an impression of your discipline based on more frequent data than you use for your own reviews

None of that is captured in the initial project closure note.

 

Why this gap stays invisible early

If fortnightly reporting changes so much, why does it feel like a small item for so long?

Part of it is how success is measured.

The project plan was scoped too narrowly

The implementation plan for fortnightly updates usually looks like this:

·         Update extract logic ✅

·         Align file formats with CICs ✅

·         Schedule jobs and hand-offs ✅

·         Run parallel reporting for one or two cycles ✅

·         Get sign-off from CICs and Compliance ✅

Every box is checked.

The slide for the SteerCo reads:

“Fortnightly reporting implemented successfully. No tech or CIC issues.”

There is no line item that says:

·         “Align internal ageing and EWS rhythm with new external frequency”

·         “Revisit manual correction queues and timing”

·         “Change risk dashboards to show intra-month movement”

So nobody owns those outcomes.

They are assumed to “settle themselves”.

Dashboards track filing, not meaning

In Board and Management packs, the bureau section often has:

·         “Reporting to all CICs – Yes”

·         “Frequency – Fortnightly”

·         “Delayed files in last quarter – 0”

At best, there may be:

·         “Rejection rate – < X%”

·         “Customer disputes closed within SLA – > 95%”

These metrics track compliance and machine health, not risk understanding.

What’s missing is a simple view like:

·         How many accounts changed DPD between the two cycles in a month

·         How often internal and external DPD diverged and had to be corrected

·         Whether mid-month bureau signals were used in any actual decision

Without that, fortnightly reporting looks like “job done”.

Any friction is treated as operational noise.

Early pain is handled at the edges

The first cracks don’t appear in Board meetings.

They appear as:

·         An email thread between Collections and Ops:

“Why is this account still 30+ in the bureau when we have a promise-to-pay and system status updated?”

·         A partner call where a co-lender says:

“Our checks show more customers rolling than your monthly report suggested.”

·         A spike in certain dispute codes in the customer service MIS:

“DPD / Status Incorrect – up 20% in the last quarter.”

Each of these is handled in isolation:

·         One more manual correction

·         One more explanation about “cut-off dates”

·         One more note to “tighten process”

Because nobody has framed fortnightly reporting as a change in how fast your external story moves, there is no reason to connect these dots.

 

What experienced teams quietly do when reporting moves to fortnightly

The institutions that handle this shift better don’t launch big programmes.

They just refuse to see fortnightly reporting as a pure technical change.

Some patterns stand out.

They align at least one internal view to the new speed

In one lender, the CRO did something simple:

·         Monthly risk MIS remained the same

·         But a fortnightly “movement snapshot” was added only for internal use

It showed, for the main retail book:

·         Number of accounts moving from current to 1–30, and 1–30 to 31–60 between the two cycles

·         A small list of cases where bureau DPD and internal DPD did not match on the cycle date

·         A count of how many new bureau disputes landed between month-end and the mid-month file

It was a messy sheet, not a polished dashboard.

But within two quarters:

·         Collections started using it to prioritise follow-ups

·         Product heads realised that some segments behaved very differently across the month

·         The discussion around bureau updates moved from “Did we file?” to “What is the data telling us mid-cycle?”

Nobody announced this as a new initiative.

It just became part of how the team read its own footprint.

They clean up the obvious manual queues early

Another institution, after one quarter of fortnightly reporting, noticed:

·         A small pile-up of corrections that were still being done in spreadsheets and email chains

·         A recurring delay in updating closure statuses for certain loan types

·         Repeat disputes from the same branches and products

Instead of launching a grand “data quality programme”, they did three blunt things:

·         Stopped allowing branch-level emails as a valid channel for DPD corrections

·         Forced all closure changes into a single workflow with a cut-off aligned to bureau cycle dates

·         Started showing disputes per 10,000 accounts, by reason, in the risk review once a quarter

The effect was not dramatic.

Within six months, the number of messy mid-month corrections and avoidable disputes dropped, which meant fortnightly reporting stopped amplifying old weaknesses.

They treat co-lenders and partners as extra mirrors, not extra work

Where co-lending and fintech partnerships were significant, a few teams did one more thing:

·         They asked their major partners how often they pulled bureau data for shared customers

·         They looked at whether partners’ views of DPD and restructuring status matched their own across the month

Where gaps showed up, they did not default to:

“This is just a cut-off issue.”

They tried to ensure that:

·         Status changes were propagated in a way that made sense for both sides

·         Servicing arrangements reflected the fact that bureau data was now moving faster than some contracts assumed

Again, no one labelled this as “RBI compliance”.

It was treated as pure self-interest: if external mirrors are sharper, you want them to show the face you think you have.

 

A quieter way to look at fortnightly credit-data updates

If you keep the belief that:

“Fortnightly reporting is the same story, just told twice as often,”

then it will remain a technical project in IT, a row in a compliance tracker, and an item to mention once in the Board deck.

If you accept that fortnightly updates mean:

·         The external version of your credit story now moves faster than before

·         All your unresolved data compromises are visible more often

·         Partners, competitors and regulators can spot movement mid-cycle

then fortnightly reporting stops being a scheduler setting and starts becoming a question of rhythm.

At that point, the more useful question is no longer:

“Have we implemented fortnightly bureau reporting as per guidelines?”

It becomes:

“Now that the outside world sees our credit behaviour twice a month,

are we comfortable with how slowly we see it ourselves?”