Fast Credit, Slow Accountability: Shashwat Kumar Talks About The Hidden Risk in Digital Banking

A credit decision can now happen in seconds. Explaining the same decision may take months.

That gap is where a bank discovers whether its decision systems were built only to perform, or also to explain, correct, and carry the outcome. Over the last decade, financial institutions have invested heavily in digital rails, analytics teams, automated workflows, customer intelligence systems, and faster risk engines. The promise is real: quicker credit, sharper fraud detection, better frontline productivity, more relevant customer conversations, and lower cost of execution.

The pressure is just as real. A banking decision may affect a borrower’s access to credit, a customer’s financial dignity, a relationship manager’s next action, an auditor’s review, a regulator’s question, or the balance sheet itself.

Shashwat Kumar’s vantage point is unusually close to this pressure. As Head of Business Intelligence and Analytics at DCB Bank, he works at the intersection of customer signals, credit behavior, risk patterns, fraud intelligence, business priorities, and frontline execution. His work spans multiple business verticals and functions within the bank, connecting analytics with customer acquisition, retention, credit, collections, employee lifecycle, and decision intelligence.

The views in this piece reflect Shashwat’s personal perspectives on industry trends, decision systems, and the evolving role of intelligence in financial services, rather than commentary on any specific institution’s internal practices.

The Distance Between Signal and Decision

Shashwat’s career has moved through technology, telecom, insurance, lending, NBFCs, and banking. The industries changed, yet the underlying problem kept returning in different forms: institutions gather signals faster than they convert them into mature decisions.

One of the early shifts came at Vodafone, where analytics in India was being built for value creation, with cost advantage serving as only one part of the story. That distinction mattered because it moved analytics from a support function into the territory of business capability. Later, in insurance and lending, the question became sharper: could analytics affect the top line, the bottom line, and the balance sheet while still operating within risk controls? By the time Shashwat moved into banking, the problem had become even more demanding. Intelligence had to reach the last mile, survive scrutiny, and be owned by business teams after deployment.

“Information is just a signal,” he says.

A signal has to be validated. It has to be tested across time, seasons, customer segments, and changing external conditions. It has to be explained in a language business teams can believe and use. It needs funding from someone with authority. It must enter workflows where people are willing to act on it. At the end of the chain, a named person or function must carry the outcome.

Many analytics initiatives lose force somewhere inside this chain. The model performs, the dashboard looks useful, the pilot impresses senior stakeholders, and daily behavior inside the institution continues along familiar lines. Old habits remain. Frontline teams find workarounds. Risk teams raise questions after design choices have hardened. Business owners hesitate to carry the result.

For professionals building careers in analytics, Shashwat’s lesson is direct. Technical output is only the starting point. Impact begins when a business changes the way it decides.

Accountability Has to Concentrate

Modern banking decisions involve many actors: data providers, bureaus, vendors, models, internal policies, analytics teams, frontline staff, infrastructure partners, approval layers, and regulators. Complexity can easily become a shelter for unclear responsibility.

Shashwat’s view is firm.

Do not try to scale accountability. Rather, concentrate it.

From a regulator’s perspective, the institution makes the decision. If a customer is rejected, delayed, mispriced, flagged incorrectly, or treated unfairly, the bank carries the responsibility.

Shashwat maps accountability by layer. Data providers own lineage, accuracy, and recency. Analytics teams own model performance and drift. Vendors own service commitments. Business teams own usage and outcomes. Each layer needs a named owner because vague ownership creates a chain where everyone contributed and no one answers.

He uses a medical analogy to describe the failure mode: all the doctors did their work, each performed well, and the patient died.

In ecosystem-led banking, this is difficult work. A bureau may provide data within its stated process. A vendor may operate within its service agreement. A model may perform within tolerance. A frontline team may follow policy. Yet the customer experiences one outcome.

That is why accountability concentration matters. In a distributed decision system, accountability cannot spread so widely that no one can answer for the outcome. It has to be designed into the system before the customer, auditor, or regulator asks the question.

A score also needs careful handling. A system may indicate risk, likelihood, or propensity, but the institution decides what action follows. The ability to produce a score is valuable. The ability to understand what action the score should trigger is more valuable. The ability to own the consequence of that action is rarer still.

Speed With Consequence

Banking carries a tension many industries face in softer form. Speed can improve access and increase exposure at the same time. A faster loan approval may help a small business at the right moment. A faster weak approval may create credit risk. A faster fraud signal may protect a customer. A faster false flag may block a genuine transaction.

Shashwat’s rule is precise.

Speed should track reversibility, not ambition.

Before accelerating a decision, the institution should ask whether a mistake can be reversed within one operating cycle. If correction is quick, exposure is limited, and financial impact is manageable, speed can create business value. If correction is expensive, customer exposure is large, or regulatory consequence is high, the decision needs friction.

A credit decision may be made in seconds. A dispute, audit, internal review, or regulatory question may surface months later.

“You cannot defend after the fact what you did not instrument before the fact,” he says.

If a decision may need explanation later, evidence must be built into the design from the beginning. The institution should know which data was used, which threshold was applied, which policy logic shaped the outcome, which exception rules were considered, and who owned the final decision.

A decision touching a customer or balance sheet needs an evidence trail from day one.

The Customer Opportunity in the Front Line

Shashwat sees one opportunity in banking that deserves more attention: relationship management at scale.

Credit access has received years of attention. Risk detection attracts serious investment. New product creation generates easy excitement. The frontline still works with fragmented customer understanding.

A relationship manager often sees customers through pieces: transactions, product holdings, service history, income behavior, risk markers, and conversations. Intelligent systems can bring those pieces together and help frontline teams approach customers with better timing, context, and relevance.

Used with care, such intelligence can improve the customer’s financial experience. A bank can remind a customer before an EMI issue damages their credit record. It can identify a genuine need earlier. It can support a relationship manager with context buried inside systems. It can make service feel more timely, personal, and useful.

The difference is whether the customer feels helped or watched, and that judgment is shaped by timing, relevance, and what the bank does when the customer says no.

What History Can Hide

Broad performance numbers can reassure leadership while concealing problems in smaller segments.

Shashwat studies the details. Geography may need to be examined at pincode level, not just state or city level. Occupation may need to be studied with gender. Age groups may need narrower intervals. Customer cohorts may need sharper cuts before hidden bias becomes visible.

The devil lies in details, and bias can only be removed using details.

Historical data adds another layer of risk. It carries past exclusions, old collection practices, earlier underwriting choices, and assumptions once made by people who may be absent from current decision forums. Before using history to guide future lending, Shashwat asks four questions.

Who is missing? What has changed? Whose decision is baked into the label? What did we never observe?

Data is a record of earlier institutional choices. Treating it as neutral evidence can quietly carry old mistakes into future decisions.

Where Data Rails Meet Adoption

India has built a powerful layer of digital financial infrastructure across identity, payments, taxation, account aggregation, and data exchange. Yet MSME credit remains difficult to scale.

Shashwat sees the next challenge less as a rail problem and more as an industry question around governance, explainability, adoption, and confidence in alternative-data-led lending.

Banks can now see richer signals about small businesses, from cash-flow patterns and transaction behavior to tax trails and digital footprints. The challenge is ensuring that these signals can be governed, explained, audited, and adopted with confidence. Data rails may create visibility, but institutional adoption depends on trust in how those signals are used.

His answer is to separate discovery from deployment. Teams should be allowed to test, learn, and identify what may work. The movement from experiment to customer impact needs stronger governance.

“Skill is the gate, not the brakes,” he says.

The principle matters beyond MSME credit. Exploration should remain alive inside institutions, while deployment at scale must pass through disciplined review.

Customer Intelligence After Consent

The Digital Personal Data Protection framework changes how banks think about customer data. Data becomes something a bank is trusted with, rather than a resource it can freely mine.

Shashwat sees consent-led analytics as a redesign of the customer relationship.

Consent first is not a constraint on analytics. It is a redesign that separates the legitimates from the lazy.

The impact will vary by use case. Fraud detection, AML, and mule account identification have strong legitimate-use foundations. Collections, cross-sell and personalization will require more careful purpose definition, consent design, and customer-benefit framing.

The opportunity is to move from broad inference toward more transparent, permission-led engagement. For banks, this is not only a compliance adjustment. It is also a chance to build customer intelligence that earns greater trust because the customer can understand why data is being used and how the action benefits them.

Execution Is the Real Product

Many pilots succeed in meeting rooms and fail inside institutions. The prototype works, the presentation is convincing, the business case sounds attractive, and the leadership team sees promise. Then live data, large scale, latency, exception handling, customer behavior, and frontline workflow arrive.

Shashwat separates demos from deployments through two questions: does the system work in real time, and does it work at scale?

A system may work on ten lakh records and fail on ten crore. A customer may tolerate a few seconds of waiting, while several minutes can end the application. Live data brings missing fields, unusual cases, poor inputs, integration problems, and operational surprises.

A serious deployment needs workflow ownership, large-scale data handling, and exception management. A demo can impress without proving any of these.

Fast Talent, Slow Systems

Intelligent tools have compressed the time required to build models and prototypes. Fast analytical talent can now create in days what earlier took weeks. Institutions may still need months for approval, adoption, review, and integration.

The gap between talent velocity and system velocity can produce frustration, cynicism, and attrition.

Shashwat’s method is to create milestones. Discovery is a win. Movement from discovery to implementation-ready is a win. Live deployment is another win. Each stage deserves recognition because talented teams need to see progress before the final rollout arrives.

Fast talent also needs protection. Speed often attracts suspicion. People ask how something could be built so quickly and assume quick work means careless work.

“Their job is to be brilliant. Our job is to make the institution safe for their brilliance,” Shashwat says.

As tools make coding, modeling, and prototyping easier, the premium in analytics leadership moves to the work around the build. Shashwat identifies the human premium in five areas: choosing the right problem, questioning the answer, translating output into business meaning, making the decision, and carrying the consequence.

Large institutions have hundreds of problems at any given time. A tool does not know which one deserves attention now, which one can wait, which one affects customer dignity, or which one changes the economics of the business. Human leaders still have to choose.

The Silence Before Failure

Many institutional failures begin quietly. A concern is left unraised. An assumption remains unchallenged. A model output gets accepted because it confirms an existing belief. A risk is noticed but kept too low in the organization. A dependency is known, yet no one names it because the system still works.

“The silent ones are more difficult to handle than visible risk,” Shashwat says.

Assumptions become especially dangerous when they disappear inside tools. Shashwat points to a simple example: many people discussing advanced systems may struggle to name the assumptions behind foundational methods like linear regression, because those assumptions have become buried inside the layers built on top of them.

Every serious institution needs people willing to ask uncomfortable questions: Who is missing? What are we assuming? Why do we like this output? Which risk has been noticed but left unraised? Which dependency are we avoiding because the current system still functions?

What Leaders Can Take From This

• Speed needs a reversibility test: A fast decision earns its value only when the institution can correct the mistake before the mistake compounds. A decision that cannot be unwound within one operating cycle deserves friction regardless of confidence.

• Ownership must be designed before deployment: In a distributed system, responsibility cannot be left to interpretation. Every data source, model, vendor, policy, and business outcome needs a named owner.

• Customer intelligence must earn its welcome: A useful reminder can protect a customer. A poorly timed product push can weaken years of goodwill. Timing, relevance, and permission matter as much as prediction.

• History must be challenged before it becomes policy: Old exclusions, weak labels, and past collection practices can enter future decisions through data. Leaders have to ask who is missing and whose judgment is already baked into the record.

• Talent needs progress before deployment: Fast teams lose belief when every win is postponed until final rollout. Discovery, readiness, and deployment should each count as real progress.

• Broad performance numbers protect institutional comfort more than they protect customers: The populations most likely to be underserved by a model are often visible only at the level of detail the model was never asked to report on. Pincode, gender, occupation intersection, and age interval matter more than state-level or category-level aggregates when the question is whether the model treats everyone fairly.

• Consent is a customer relationship question before it is a compliance question: Banks that treat data protection as documentation will build minimum consent infrastructure. Banks that treat it as a chance to redesign how they earn the right to use customer data will build something more durable.

• Silence is a leadership signal: The concern no one raises, the assumption no one challenges, and the risk no one escalates may reveal more about an institution than the dashboards everyone reviews.

The Name Behind the Decision

Every bank wants better decisions: faster credit, sharper risk control, cleaner customer experiences, stronger frontline intelligence, and more useful engagement. The challenge is managerial, cultural, and institutional.

Shashwat’s work sits inside that reality. Banking decisions affect credit access, customer dignity, risk exposure, regulatory scrutiny, and institutional reputation. Intelligence has value only when the institution can use it with discipline.

The serious work is to build systems that can be explained, corrected, audited, improved, and owned. In banking, the decision may become faster. The responsibility still needs a name.