Chief Data Officer / India
A more limited answer can be more useful
- Bank branches
- 86
- Three central Indian states
- Data colleagues
- 32
- Four managers; March 2026
- Annual function expense
- ₹8.4 Cr
- Data office; no credit or treasury delegation
Decisions & consequences
01Withholding a credit prototype that had learnt from later events
A credit-model prototype used 12,000 completed loan histories and reported an AUROC of 0.91 on a random split. The development team regarded that as strong evidence for a controlled release. My data review asked when each input became available. Two groups of fields described collection contacts and overdue activity recorded after the point at which the proposed model would support a decision. The historical table contained useful knowledge that the live decision would not yet have.
I asked the developers and source owners to remove those fields and examine other inputs for indirect traces of later events. Risk validation also required an evaluation on a later time period, rather than relying on the original random split. The revised prototype achieved 0.71 on that temporal holdout. We did not attribute the whole difference to the removed fields, because the feature set and evaluation design had both changed. The revised result was evidence about a different, more relevant test.
The business sponsor objected that withholding release would delay a programme already presented as a productivity improvement. I supported the delay and asked the team to describe what additional development and validation were needed. The data office did not approve the model for credit use or change any customer's lending outcome. We documented the timing of inputs and gave risk and business owners a clearer basis for their separate decisions. The attractive original score was retained in the review record with its limitations, rather than quietly replaced.
The consequence was a withheld release and further work, with no claimed improvement in live defaults or approval quality. The case changed how prototypes entered review: developers had to explain not only what a field meant but when it could be known. I wanted a model's apparent intelligence to be tested against the actual decision it was meant to support. A lower score under a credible design could guide further development; a high score built partly from later events could not justify putting the prototype into a live process.
Restating a regional growth comparison after service areas moved
A management dashboard showed 43% account growth for a region after twelve service-area codes were reassigned across nine branches. The operating records were current and the arithmetic was correct. The comparison nevertheless combined two different populations. Accounts transferred into the region appeared as growth even though the customers' underlying relationships had not been newly acquired. Regional management was preparing to use the figure in a discussion of branch performance and the next year's staffing.
My team reconstructed the comparison on a consistent geographic basis, working with the operations owners who could explain the boundary changes. The restated growth rate was 8% for the defined population. We kept the current organisational view and the comparable-population view distinct, with their purposes stated. We did not alter customer balances, account opening dates or branch records to make the result agree. The repair concerned the analytical comparison, not the operational truth of where the accounts were now served.
Some regional colleagues felt the restatement diminished work done during a difficult transfer. I agreed that the transfer created real operational effort and should be recognised through suitable evidence. It was still different from acquiring new accounts. We separated the service workload from the growth measure so the staffing discussion could consider both. The dashboard owner approved the revised presentation after reviewing the population definition and the treatment of the reassigned codes.
Management withdrew the 43% figure as evidence of organic account growth and used the two views for their respective questions. The 8% result was not a new universal growth rate for every bank report; it applied to the stated geography and period. The practical lesson was to preserve the event that changed a population before asking analysts to explain its trend. A familiar regional label can conceal a different group of accounts, and a correct calculation cannot repair that meaning on its own.
Removing a zero that the historical source had never observed
An analytical migration brought 58,200 records into a new reporting view. Of those, 7,300 lacked the earlier-period observation required for a trend comparison. A display default converted the absent value to zero, allowing every record to appear in the chart. The result suggested changes that had not been observed. The migration reconciliation confirmed the number of records moved, but that did not establish the completeness of the historical measurements attached to each one.
I asked the source owners to distinguish unavailable history from an observed zero and from records requiring investigation. We introduced an explicit missing-history state in the analytical view and restricted the supported comparison population. The reporting team also added a coverage explanation so users could see how many records contributed to the trend. We did not invent earlier values, change the underlying customer balances or infer that an absent observation meant an account had no activity. Each state retained the meaning the available evidence could support.
The dashboard sponsor objected that the revised output looked less complete and would require explanation in management meetings. I accepted that cost. A full chart built from a default was not a better account of the business. We retained a separate worklist for history that could be recovered from authorised sources, with corrections reviewed by the responsible owners. The absence of immediate recovery did not justify treating all gaps as equivalent or presenting an unsupported numerical answer while investigation continued.
The repaired view had narrower coverage and a more truthful trend. Users could distinguish the population analysed from the records held in the system. We did not claim that every historical gap had been resolved. The case led us to include semantic coverage in migration reviews alongside row counts and technical reconciliation. Moving a record successfully is only one part of preserving its usefulness. The bank also needs to know which observations exist, which do not and what evidence would be required before a missing value could responsibly become a number.
Restricting a dashboard whose small groups revealed too much
A proposed management dashboard grouped customer activity across 84 village clusters and allowed combinations of occupation, product and location filters. Names and account numbers were absent. During review, twenty-three resulting cells described fewer than five people. In some locations, a reader with ordinary local knowledge could narrow the likely individuals further. The absence of direct identifiers did not settle whether the proposed detail was appropriate for the broad audience planned for the dashboard.
I brought privacy, security and business owners into a review of the decisions the dashboard was meant to support. We broadened some groupings, restricted combinations of filters and moved requests for finer detail into a controlled process. The team also examined whether users could infer a small group by comparing successive totals. A simple rule that hid only the most obvious small cell would not address every inference available from related views. We tested representative combinations before permitting the revised audience access.
Regional managers objected that broader groups would make local patterns harder to investigate. That concern was real: the revised dashboard gave up some convenience and immediate detail. We preserved a route for authorised, purpose-specific analysis through the responsible team rather than distribute the detailed view to everyone. I did not describe the change as proof of anonymity or legal compliance. The relevant owners determined the permitted use, and the data office implemented and tested the agreed analytical controls.
The broad rollout proceeded only with the restricted view. More detailed enquiries required additional review and therefore took longer. The case demonstrated that aggregation is a design choice with consequences, not a universal privacy solution. I wanted our analysts to examine what a reader could infer from the available combinations and surrounding context. The useful outcome was a report better matched to its audience and purpose, together with a clear process for legitimate questions that needed more detail than the general dashboard should expose.