This deep dive expands on the Loop Asia conversation with Abhijit Dey, VP of API Banking at Axis Bank.

Most conversations about API governance happen too early or too late. Too early, it's process for its own sake — a tax on teams trying to ship. Too late, it's archaeology on an estate nobody understands, working out which endpoints are load-bearing. Abhijit Dey, VP of API Banking at Axis Bank, flagged the second scenario as what he's most worried about in Indian banking — not a hypothetical, but the direct consequence of everything else going right.

Sprawl isn't a failure mode. It's a success mode that went unmanaged. Dey's framing: "the more digitized our ecosystems are getting, the more we are building APIs and sometimes... we cannot blame anyone practically. Because there are always, you know, time to market, go to market pressure." Every API gets built for a defensible reason — a team ships, a partner needs an integration, a channel needs a feature. None of that looks wrong alone — it shows up only in aggregate: which of these still do anything, and for whom?

The metric that actually matters

Dey's answer isn't a governance committee or an approval gate — it's a different unit of measurement. Most organisations track how many APIs they've published as a proxy for platform maturity. Dey argues that's backwards: his benchmark is the ratio between APIs, the products built from them, and the use cases those products serve. Four APIs, orchestrated into five products, covering ten use cases, is a strong result. Ten thousand APIs supporting seven thousand use cases is not, however the board deck spins it.

This is a reuse argument too. A balance inquiry API gets orchestrated with a payment inquiry API, a transfer API, an account statement API — a small set of composable primitives, not a new endpoint for every requirement. Sprawl is what happens when nobody protects that discipline.

Why this is a technical champion's problem, not a compliance one

It's tempting to file this under security or compliance — rate limiting, auth scopes, gateway policy. Those controls matter, but the real problem sits higher, where architecture gets decided under delivery pressure. Fixing it is a CTO or Head of Architecture job: a live inventory of what exists, an honest audit of what's consuming each API, and, harder still, the willingness to deprecate something that shipped fine but never found its use case. Deprecation has no champion inside engineering organisations; shipping new things does. Dey's ratio works as a forcing function here — fewer APIs, more use cases, makes consolidation the visible win, not a chore for later.

None of this is unique to banking or India. Any organisation externalising services fast enough to get excited about its own API platform hits the same wall a year or two later. Blue Connector's version: not counting APIs, but auditing which ones a product or use case depends on, before the estate is too large to ask honestly.