Skip to Content

The Loop Asia

Insights

Analysis and commentary from The Loop Asia — AI, APIs, and technology leadership across Asia-Pacific.

Thanks for subscribing!

No spam. Unsubscribe any time.

How do you justify an API that doesn't charge for anything

A payments API sells itself. A balance inquiry API doesn't. Abhijit Dey's two-metric framework — adoption plus downstream commercial signal — for defending the ones that don't have an obvious revenue line.
June 17, 2024 by
How do you justify an API that doesn't charge for anything
Jon Scheele

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


Every finance conversation about a payments API is short — the answer's already in the transaction. Every finance conversation about a balance inquiry API is longer: there's no fee to point to. Abhijit Dey, VP of API Banking at Axis Bank, has spent a decade building both kinds, and how he talks about the second is a useful template for defending an investment that doesn't generate revenue on its own line. He doesn't pretend the problem away: "if that technology doesn't give you a revenue, doesn't give you a business number, that technology is of no use." That's a harder line than most technologists take in public — exactly why his method for the non-transactional case matters.

Two metrics, not one

Dey's framework rests on two measurements: adoption, and revenue. Adoption is table stakes — how often the API is called, and what proportion of calls succeed; if it fails half the time, that's a reliability problem, fixed fast. Revenue is where the real judgment sits. For a payment API it's obvious. For a balance inquiry API, Dey looks past the API to what it correlates with — customers who use it keeping higher balances, or showing up more in cross-sell conversations. His analogy is deliberately outside banking: a supermarket visit where you walk out having bought nothing. If the experience was good, you come back — and eventually buy something. The API isn't the revenue event; it's evidence the relationship is active enough to produce one, and proving that takes different data: engagement and retention, not transaction logs.

Why this belongs in the business owner's language, not the CTO's

This is a business owner's problem, not a technical one. A CEO, COO, or Head of Professional Services doesn't need to understand how the balance inquiry API is built — they need to defend its budget in a boardroom asking what it returns. Dey's approach gives them that without inventing a revenue number that doesn't exist: adoption as the leading indicator, the downstream commercial signal — balance growth, cross-sell, retention — as the lagging one. Report both, honestly, as the business case.

It generalises beyond banking too. Dey notes that large FMCG and e-commerce firms now publish APIs for the same reason — not as a product line, but as infrastructure for a customer experience that shows up in numbers the business already tracks. Any organisation with an AI or integration mandate and no ROI case faces the same translation problem Dey solved for balance inquiry: find the specific downstream number the technology actually moves, instead of inventing a revenue line it was never going to produce. That's the exercise Blue Connector runs with clients before the boardroom conversation, not after.


Defending an API investment that doesn't have an obvious revenue line?

This is the exact translation exercise I run with clients before the boardroom conversation, not after.

See how I help financial services leaders →