How AI Can Transform BFSI: New Street Technologies CEO Sajeev Viswanathan Shares His Insights

Fragmentation happens when AI is deployed as a collection of point tools rather than as connected infrastructure. A bank may have a voice bot in one function, a coding assistant in another, and individual employees using consumer grade LLMs for research or content. Each may solve a local problem, but collectively they create another silo, another data boundary and another governance challenge.

The way out is not to ban these tools, but to give every use case a common foundation. Banks need a shared layer for identity, audit, version control and domain intelligence, so that a fraud model in retail banking and a compliance workflow in trade finance can draw from the same governed, permissioned pool of institutional intelligence rather than being developed in isolation.

This is the thinking behind Domain Intelligence Models: permissioned, shared intelligence that multiple processes and products can draw on, with an optional interface to external LLMs where required.

Just as important is keeping AI decoupled from production execution. When AI generated designs and configurations go through maker checker approval before deterministic execution engines run them in production, institutions get consistency and auditability by design. Isolated AI is often a symptom of isolated governance. Build a connected governance layer and intelligence can compound across the organisation instead of fragmenting further.

Quite significantly, but only if industry specific means more than fine tuning a general model on financial vocabulary.

A model shaped around BFSI specific transaction patterns, SWIFT message structures, KYC and AML workflows and regulatory reporting formats can identify anomalies and compliance gaps that a general purpose model may not be designed to recognise. That specificity is what can turn AI from a productivity tool into a genuine fraud control and compliance capability.

But the real strength of industry specific AI in a regulated environment comes from the architecture around the model, not the model alone. Compliance and risk teams will always ask three questions: Can this be explained? Can it be audited? Is a human still in control?

Our approach is therefore to separate the AI that designs or flags from the deterministic engine that executes. Configurations pass through maker checker approval, version control and audit trails before they reach production, while decisions remain traceable to human oversight.

Privacy also needs to be built into this architecture. Domain intelligence can be permissioned without requiring sensitive customer data to be moved outside its governed environment. Institutions can benefit from collective intelligence around fraud typologies and compliance patterns while retaining control over their underlying customer data.

They already are.

Cloud platforms, foundation models and engineering capabilities are becoming increasingly accessible, which means the model itself is becoming less of a differentiator. What organisations cannot simply buy off the shelf is the ability to convert a business requirement into a governed, production grade system quickly and safely.

That makes deployment velocity increasingly important. A bank that can implement a regulatory change in hours or launch a new product in days, on a well governed platform, can have a significant advantage over an institution running a larger model through a slower and less disciplined release cycle.

The real differentiators will therefore be data strategy and execution discipline: how well an institution has organised its domain knowledge, how deeply governance is embedded into the architecture, and how consistently it can translate business intent into deployed and compliant software.

This is also where measures such as time to market and Total Cost of Technology Ownership become important. The question is no longer simply which model a bank uses, but how efficiently and responsibly it can turn intelligence into business outcomes.

The tension is often smaller than it appears. Fraud typologies, money laundering patterns and emerging attack vectors are not where banks compete. Customer experience, pricing, product design and service innovation are where differentiation happens.

The collaboration models that can work best are therefore those that allow institutions to share pattern intelligence and threat signals while keeping proprietary data, models and customer information within each institution's governed environment.

Practically, this could mean permissioned, domain level intelligence sharing rather than data pooling. A shared library of fraud patterns, typologies and regulatory logic could allow multiple institutions to benefit from collective intelligence without requiring transaction data or customer records to leave their respective environments.

Federated approaches, where signals or models are shared while underlying data remains local, could be particularly relevant for BFSI. Regulator sponsored or industry utility models also have potential. Payment networks and settlement infrastructure already demonstrate how shared rails can create value without removing individual institutional control.

Collective defence against financial crime does not have to come at the cost of competitive differentiation. A safer financial ecosystem benefits every participant, while differentiation continues to come from how effectively each institution turns intelligence into action.

Industry specific AI ecosystems could do for intelligence what payment networks did for money movement: turn something every institution needs but may struggle to build independently into shared, governed infrastructure.

Over the next few years, I expect BFSI to move from isolated AI pilots towards interconnected ecosystems involving regulators, payment networks, fintechs and technology partners. Shared, permissioned domain intelligence and greater interoperability between AI systems could become increasingly important as institutions move towards AI native operations.

For banks, three priorities stand out.

First, modernise the operational core, not just the customer facing channel. The strategic challenge is increasingly the gap between how quickly a bank can launch or market a product and how quickly it can actually build, deploy and govern it.

Second, embed governance by design. Audit trails, version control, maker checker workflows, human oversight and appropriate controls need to be part of the architecture from the beginning rather than added after deployment.

Third, invest in domain intelligence rather than relying only on generic AI tools. Fragmented, single purpose AI tools may deliver short term productivity gains, but the greater long term value will come from governed intelligence that multiple processes and products can draw upon.

Customers will not choose a bank simply because it uses AI. They will choose it because it responds faster, manages risk better and earns their trust. AI may be the engine, but trust remains the defining enterprise differentiator.