Accountability Must Guide Automation, Not Just Efficiency

Look, Rishi Chhabra is right where it counts: automation can’t eat accountability. Say that inside a payments company and everyone nods. But his Express Computer piece stops just short of the uncomfortable part — naming who actually holds the bag when automated systems make bad calls, and which concrete levers turn “trust” from slogan into infrastructure.

Trust isn't a checkbox — it's a workflow

You can’t bolt an ethics statement onto an API and call it accountable. Chhabra’s core claim — that automation must preserve accountability — is necessary, but not sufficient. Accountability only exists when you can answer five boring questions, every time something goes wrong: Who decided? Based on what? When? With which model or rule set? And what remedy followed?

That sounds basic until money is on the line.

Visa India is the obvious backdrop. Payment rails can’t rely on “we’ll review it if something breaks”; they need deterministic handoffs. When a fraud engine blocks a transaction, the real problem isn’t just model accuracy — it’s ownership. Who owns the appeal path? Is liability sitting with the team that trained the model, the team that deployed it, or the vendor that supplied it?

Here’s what nobody tells you: if you don’t pre-assign that ownership, automation becomes a blame-shifting machine. The logs exist, but they don’t map to a person or a team with both authority and obligation to fix things. That’s how “embedded trust” turns into “embedded ambiguity”.

Where the argument trips up

Chhabra frames trust as an architectural concern. Fine. But architecture is only half the story; governance and incentives are the rest.

You can design immaculate audit trails and still get ugly outcomes if leadership rewards speed over checks or keeps buying black-box models on the promise of quick wins. Technical controls can become a security blanket — a CEO points at an audit trail and assumes that absolves operational risk. It doesn’t. It just documents it.

I’ve seen this in large operations: teams build careful monitoring, leadership quietly sidelines alerts to hit growth targets, and when the system fails, those beautiful logs show up in regulatory inquiries instead of in post-mortems. Architecture wasn’t the issue. Misaligned incentives were.

So when Visa India says “trust must be embedded,” the translation can’t stop at system diagrams. It has to show up as board-level metrics and compensation tied to accountable outcomes, not just throughput or uptime.

How to make "trust" measurable

Trust gets fuzzy fast if you don’t break it into smaller, observable parts.

Start with data: who touched it, where it came from, how it was altered. That’s provenance. Then models: how they were trained, how often they’re retrained, and what their behavior looks like in production versus in testing. That’s the basis for explainability, even if you’re not doing full white-box analysis.

Then timing: after an automated decision hits a customer or merchant, how long until a human can review it? If there’s no defined path — no SLA, no queue ownership — you don’t have accountability, you have a helpdesk lottery. And for every error class — false fraud block, KYC failure, mispriced fee — you need a standard remediation path and entitlement: refund, restore, escalate, or compensate.

These aren’t nice-to-haves. They form the “primitives” regulators and partners can actually verify. They also surface the real trade-offs: faster decisions usually reduce explainability; squeezing false positives often raises the odds of missed fraud. Make those trade-offs explicit and you stop hiding behind words like “trustworthy” and “responsible”.

A counter-argument — and why it’s not enough

Someone will argue that automation often improves outcomes even when accountability is fuzzy. Fraud gets caught earlier. Onboarding gets cheaper and more inclusive. Manual review teams shrink. Why load all that down with governance?

Give me a break.

That’s like saying seatbelts slow you down so let’s skip them because most drives end fine. Yes, automation usually boosts efficiency and, done right, safety. That’s not a case for weaker accountability; it’s a case for smarter accountability.

You don’t slow systems to human speed. You design escalation thresholds: small, reversible decisions get auto-approved; bigger, harder-to-undo ones get flagged sooner and more often for human review. You build rollback capability into releases. You write contracts with third-party vendors that preserve traceability instead of hiding it behind “proprietary algorithms”.

The goal isn’t to second-guess every step. It’s to ensure that when someone downstream needs to intervene, they have the levers and the paper trail to do it fast — and to explain why they did or didn’t act.

What Visa India and peers should actually do

Start simple: define the unit of accountability for each automated decision type. Not “the data team” or “the risk function” — an actual role with a name attached in internal systems. Put that in your architecture docs and your runbooks.

Second, tie those responsibilities to measurable outcomes and real consequences. If a model repeatedly harms the wrong customers, and the accountable owner keeps approving it without mitigation, that needs to show up somewhere more serious than a retro slide. Otherwise, all the architecture talk is theater.

Third, standardize a minimal “audit kit” you’re willing to expose to partners and regulators: who triggered the change, what version of which model or rule set was active, when it was last validated, why it was approved, and what remedy was applied when it misfired. Not a glossy manifesto — a checklist.

There’s a useful historical echo here. When double-entry bookkeeping spread through commerce, it didn’t just make ledgers cleaner; it changed who could be trusted to run a business. Firms that kept consistent books got cheaper credit and better partners. Payments automation is going through the same kind of sorting: players who can prove accountability in code, contracts, and culture will win trust; the rest will rely on marketing.

Wake up — saying “trust matters” is PR. The players who treat Chhabra’s line not as a slogan but as a specification are the ones whose systems will still be trusted after the next big fraud scandal or outage shakes the market.