Incident Management for Digital Public Infrastructure
Designed RBIH's incident management practice and the case for its tooling, so production alerts on the Unified Lending Interface (ULI) reach an accountable responder and every major incident ends with tracked follow-ups.
Background
The Unified Lending Interface (ULI) is a credit digital public infrastructure platform, conceptualised by the Reserve Bank of India and built by RBIH. Lenders use it to reach a large network of data service providers through standard APIs, for checks such as identity, income, land records, and credit history. When a platform like this degrades, the impact lands on lenders first and then on the borrowers waiting for a credit decision.
When I joined RBIH in June 2026, the detection side was already in place: dashboards, logs, alerting, and an escalation matrix. What needed work was everything after an alert fired. Escalation leaned on email and ad hoc calls, roles during an incident were not always clear, and follow-ups were hard to track to closure. Monitoring could tell us something was wrong. It could not make sure the right person was working on it.
My Role
I own the incident management practice for RBIH Engineering. I wrote the process, made the case for the tooling, and lead the rollout together with the DevOps team. Along the way I work with the CTO and engineering leadership, the partner success team that talks to lenders, and the security and compliance team that handles regulatory reporting.
Execution
- Defined what counts as an incident at RBIH, and what does not, so teams declare early instead of debating whether something is “big enough”.
- Introduced a P0 to P2 severity model based on user impact, with a deadline for closing postmortem action items at each level.
- Set out four incident roles with clear boundaries: the Incident Commander (the on-call engineer, and the only person making production changes), the Incident Lead (coordinates, removes blockers, owns the timeline), the Communication Lead (stakeholder and partner updates), and the Incident Owner (runs the postmortem and drives follow-ups).
- Designed a two-phase workflow, detection and triage first, then response, resolution, and postmortem, with one incident channel and one bridge per incident.
- Wrote a communication plan that separates internal updates, leadership escalation, partner communication, and regulatory reporting, so each audience hears from one accountable owner.
- Set up time-bound escalation paths and on-call rotations for every role, and made postmortems mandatory for P0 and P1 incidents.
- Compared three incident management platforms against RBIH’s needs and ran a live trial on real production alerts before recommending one, so the decision rested on evidence from our own systems rather than a feature checklist.
- Wrote the approval case covering the problem, options, cost, security and compliance checks, and a phased rollout: ULI first, then RBIH’s other platforms.
Where It Stands
This work is still rolling out, so these are early signals rather than final numbers.
- During the trial, a real production incident reached an acknowledged responder within minutes, with the incident channel, roles, and timeline set up automatically.
- The process gives engineering, partner success, and leadership one definition of an incident, one severity scale, and one escalation path.
- Once the ULI rollout settles, the same practice extends to RBIH’s other platforms.