Chief Information Officer / India
What changed when we followed the officer
- Branches supported
- 88
- Four northeastern Indian states; March 2026
- Technology colleagues
- 42
- Led through four functional heads
- Technology envelope
- ₹28 Cr
- ₹22 crore operating plus ₹6 crore capital expenditure
Decisions & consequences
01Preserving the receipt when the upload had to be repeated
During a 2024 field-application review, operations reported that officers could not always tell whether a receipt had reached the central service after a connection failed. Reopening the task sometimes produced a second transmission with a new technical reference. A hurried interpretation would have treated the retry as a second payment instruction. We examined 18,420 receipt records and identified 1,146 repeated transmissions associated with interrupted connections. That count described messages, not confirmed instances of borrowers paying twice.
I brought application engineers, branch operations and finance together around the original receipt identity. We changed the retry path so it retained that identity and could not create a new posting request merely because acknowledgement had been delayed. The device displayed the pending state and the officer's next permitted action. Finance remained responsible for reconciliation and any account correction; technology did not delete ambiguous records to make a synchronisation report appear complete. We tested the path by interrupting the connection before and after central acceptance, which produced different situations despite a similar experience on the handset.
Thirty-seven records still needed supporting evidence at the review date. A project sponsor wanted the release report to say the payment issue was closed because the software change had passed its tests. I separated release completion from the remaining reconciliation work. Operations assigned owners to the thirty-seven records, with finance reviewing the account consequences. We also gave branch staff a way to explain a pending confirmation without telling the borrower to make another payment solely because the upload had not been acknowledged.
The change reduced a route by which retries could become new requests, but it did not establish that every historical receipt was correct. That limitation remained in the report. I accepted additional reconciliation work and a less decisive closure statement because a customer-account claim requires evidence beyond a successful software test. The case changed how we specified offline actions: their identity and meaning had to survive transmission failure, rather than be reconstructed from whichever message arrived last.
Removing most borrower records from the travelling device
Six field handsets were reported lost over a 2025 review period. The incident process exposed an architectural choice that had become routine: an officer could download up to 720 borrower records for possible use across a wider branch area. The volume made reassignment convenient, but most records were unnecessary for the officer's next route. We did not know that all six devices had disclosed data, and I did not describe the incident as a proven breach of every downloaded record. We did know that the potential exposure exceeded what the daily task required.
Security colleagues assessed the devices and the evidence available. I asked the applications team to redesign the route package around assigned work, limiting it to at most 42 borrower records for a day and removing identity-document images from that local package. Necessary customer identity verification continued through the authorised process; we did not eliminate it to reduce storage. Access controls, encryption and the incident response remained separate responsibilities. A smaller download was an additional protection, not a replacement for them.
Operations objected that an officer covering an absent colleague might now need an authorised reassignment and a connection before receiving the additional route. I accepted that inconvenience and worked with the COO on a practical reassignment process. The former arrangement put a large reserve of customer data on a travelling device for occasional convenience. The revised process made the exceptional need visible rather than giving every officer broad access in advance.
We also changed the incident report to distinguish a remote-wipe instruction from confirmation that the device had executed it. A handset that remained offline could not receive a fresh command. Management needed to understand that limit when assessing the incident and the action required. The result was a smaller routine local-data footprint and a more accurate statement of device-control evidence. It was not a claim that a lost device had become harmless or that the company could stop examining what happened to it.
Holding four translated prompts after the second field test
A language update for the field application contained 23 revised prompts used by officers navigating repayment and service tasks. Reviewers had checked the translated text, and the project was scheduled for a single release. During a rehearsal I noticed that agreement on a phrase did not always produce agreement on the action it requested. An officer might interpret a prompt as confirmation that a record had been accepted when it only asked whether the officer wanted to submit it. The underlying lending terms were unchanged, but the interface could still mislead a user about the process.
We asked 44 officers to complete 128 simulated tasks without coaching. Reviewers recorded the next action chosen and the explanation the officer gave. The first round produced seventeen incorrect next actions. Developers, language reviewers and operations colleagues then separated wording problems from workflow problems and revised the relevant screens. In the second round four incorrect actions remained. We retained the same task definitions so that the comparison would not improve merely because the second exercise was easier.
I authorised release of nineteen prompts and held four for further work. The release manager argued that a split would complicate support and make the delivery look incomplete. That was a real cost, but releasing text that still produced an avoidable wrong action would pass the inconvenience to staff and potentially to customers. Operations agreed the temporary support guidance. Compliance retained approval of any wording that affected the explanation of customer obligations; the technology team did not change loan terms through a translation exercise.
The result was a partial release with a documented reason for the remaining work. The rehearsal involved simulations, so I did not claim a measured reduction in live customer errors. We used the findings to improve the release decision and planned observation after deployment. The case gave our language reviewers a more concrete role: they could test whether a phrase helped a person complete the intended action, while preserving the distinction between clearer navigation and a different financial commitment.
Replacing the unsupported group before replacing the whole fleet
The procurement proposal covered 210 field handsets for ₹41 lakh, including the planned enrolment and support arrangement. The devices in use varied in physical condition and remaining software support. Eighty-four could no longer receive the operating-system security updates required by our supported application configuration. Others remained within the supported configuration and had usable batteries. Treating the fleet as one age group would have hidden the reason some devices needed to leave field use sooner than others.
I asked technology operations and security to verify the support position device by device, while branch managers checked whether the proposed replacements could handle the actual workday. We rejected a temporary suggestion to keep the unsupported group running by relaxing the application's security requirement. That would have converted a procurement delay into an unapproved change in protection. Instead, finance approved a first stage of 84 replacements costing ₹16.4 lakh, with the remaining 126 devices subject to a scheduled support and condition review.
The staged purchase required more coordination than a single fleet swap. Staff needed enrolment appointments, a record of equipment handed back and a supported device available before resuming the relevant field task. We included the handling of returned equipment in the plan and kept customer records out of casual transfer between handsets. Operations managed the route disruption; my team managed configuration and support. The company retained the later expenditure as a planning assumption rather than recording the difference between ₹41 lakh and ₹16.4 lakh as a permanent saving.
The first stage removed the 84 unsupported handsets from the assigned field use. It did not certify that the remaining fleet would stay suitable indefinitely. We reported the support assumptions and the next review date alongside the spend. I wanted directors to see why the phased approach was responsible at that point and what would cause the company to accelerate the next stage. A lower immediate invoice was a consequence of the decision, not its sole justification.