Roughly one payment in four was failing.

Not failing dramatically. Failing in the ordinary way payments fail: an authorisation request goes out, something declines it, and the person on the other end sees a message they cannot act on. Inside the company that number lived on an engineering dashboard as an authorisation rate. Outside it, it was a customer who had decided to pay for something and had been prevented from doing so.

Which of those two descriptions a company uses turns out to determine what it builds.

Vamshi Krishna Dassaraju has spent his career at that boundary, working in product roles across payments, marketplace risk and banking modernisation. His argument is that most financial products are still designed from the institution's side of it, and that the shift worth making is not technical.

"Traditional financial products are often designed around institutional processes," he says, "whereas agile financial products should increasingly be designed around the customer's complete financial journey."

The authorisation problem is his clearest illustration. Working at a major payments company on a consumer payments app, he was part of a cross-functional product and technology effort that raised authorisation performance from roughly 76 percent to around 94 percent. He is careful about the attribution, describing it as the outcome of that combined effort rather than as his own result, and the figures are his own account rather than independently audited.

What makes it interesting is not the improvement but the reframing that produced it. An authorisation failure sitting in an engineering metric is a system behaving as configured. The same failure understood as a customer outcome is a product defect, and product defects get prioritised differently.

That reclassification is the whole of his thesis, and he states it plainly: "Customers do not necessarily value a loan, payment, account, or rewards program simply because the product exists; they value how effectively it helps them accomplish a financial objective."

The measurement follows from that. He argues teams should judge themselves on ease of access, transaction completion, speed, transparency, trust and long-term engagement, rather than on whether the thing shipped. Shipping is the easy part to measure and the least informative.

A second strand of his work applies the same logic upstream, to who can use a product at all. At a large financial institution he contributed to expanding eligibility for a buy-now-pay-later product from approximately 2.2 million to 23 million customers. He is precise that this is eligibility rather than adoption, describing it as an increase in potentially eligible customers, which is a distinction most people in his position would let slide.

Expanding access is a different kind of problem from improving experience, and a harder one organisationally. It required coordinating product, technology, banking infrastructure and operational dependencies simultaneously, because eligibility is not a setting. It is the downstream consequence of every system agreeing that a given customer can be offered a given thing.

Alongside it he delivered credit-bureau reporting for the same product, which is the least glamorous item in his record and arguably the most telling. Reporting a short-term credit product to the bureaus is the plumbing of responsible lending. It benefits the customer in ways they will never notice and slows the product down in ways the business does notice.

He puts the general principle this way: "innovation should not come at the expense of trust." The products that succeed will balance speed, personalisation, security, regulatory responsibility and transparency, and the balance is the difficult part, because each of those pulls against the others.

His earlier work at a large online marketplace came at customer experience from the opposite direction. Analysing transaction patterns and building detection approaches and investigation processes, he helped prevent more than 60,000 fraudulent returns a year, and automation of one investigation workflow raised throughput from 18 to 32 cases an hour. Both figures are his own.

Fraud prevention is usually framed as protecting the business. He frames it as marketplace integrity, which is the same work seen from the customer's side, and consistent with everything else in his account.

Where he expects this to go is toward products that stop being static. Real-time behavioural and transactional insight, in his view, will let institutions personalise experiences, anticipate needs and identify friction continuously rather than in quarterly review cycles, turning financial products "from static offerings into continuously evolving services."

That is a common enough prediction. The less common part is his definition of what agility would then have to mean.

"Agility in financial services should mean more than delivering features faster," he says. "It should mean creating an organizational capability to identify changing customer needs, respond responsibly, learn from real-world outcomes, and continuously improve the financial experience."

Faster feature delivery is what most institutions bought when they bought agile. What he is describing is an organisation that can notice it was wrong and change, which is a considerably more expensive thing to build and cannot be procured.

The authorisation number is a reasonable place to end. Somebody had to decide that a declined payment was a product problem rather than an infrastructure statistic. Everything else followed from that decision.