Banking’s technology problem is often described as a race toward intelligence. More automation. More AI. Faster decisions. Smarter workflows. But many of the industry’s weakest points remain surprisingly familiar. Capgemini found that financial institutions still face significant inefficiencies in core business functions, with customer onboarding and KYC — Know Your Customer — among the most inefficient processes; for banking, the report also flags cross-border payments and compliance management among the top pain points.

To understand why modernization in banking so often becomes difficult at the point of execution, we turn to Jayanth M. Prasanna, a global quality engineering lead whose work has helped financial institutions modernize some of their most sensitive operational systems without compromising stability, compliance, or day-to-day continuity. Across the modernization of customer verification (KYC) and anti-money-laundering systems (AML systems), sanctions-screening infrastructure, SWIFT-related change programs, and cross-border deal workflows, his work has made it possible for organizations to replace outdated architecture, reduce reliance on manual processes, strengthen release confidence, and bring greater consistency to systems where errors can carry regulatory and operational consequences.

Jayanth, many programs still stall once they move from strategy into real operations. In your experience, what modernization programs move from strategy into real operations, what part do institutions most often underestimate?

Many institutions still approach modernization as if it were mainly a feature question. They ask how to make systems faster, more intelligent, or more efficient. Those are valid goals. But in banking, the deeper issue is whether the system remains dependable when the conditions are less than ideal.

A workflow may perform well in a controlled environment and still create serious problems in production. In regulated operations, the real pressure comes from incomplete data, overlapping rules, exception handling, audit expectations, and timing. That is why I think banks often underestimate the difference between a system that is technically upgraded and one that is truly ready to be trusted. Modernization becomes meaningful only when it strengthens control, not when it simply adds capability.

You raised user interface automation coverage in a major banking modernization program and led the migration of a mission-critical compliance platform to Angular. What kinds of dependency or logic problems usually become visible only once the migration is underway?

The first thing that becomes visible is how much business logic is embedded in the platform beyond what the front end seems to show. A compliance system may look like a workflow with forms, validations, and analyst actions, but underneath that there are years of accumulated decisions. Rules around onboarding, due diligence, escalation, exception handling, and downstream integrations are often more interconnected than the business initially realizes.

Once migration starts, those connections become very difficult to ignore. A change that looks straightforward from a technical perspective can affect how a customer record is validated, how an analyst handles an incomplete case, or how a compliance decision is documented and defended later. That is why these programs have to be approached as workflow migrations, not just technology upgrades. The issue is usually not whether a page renders correctly in the new stack. The issue is whether the logic, control path, and case behavior still hold together once real users and real data start moving through the system.

Leading the implementation and validation of SWIFT messaging and payment platforms at a commercial bank, you reduced transaction errors, improved system reliability, and supported mandatory annual SWIFT upgrades. Once a bank has technically established the connection, where do international payment processes most often begin to break down in practice?

Usually, after the message leaves the point of connection and starts moving through the wider process. A bank can confirm that a SWIFT interface is up, that a message format is supported, and that the annual upgrade was completed. That does not automatically mean the payment process is stable.

The real failure points are usually downstream. Routing logic may behave inconsistently in certain scenarios. Data can lose quality as it moves between systems. Exceptions may not be surfaced early enough for teams to act before a delay becomes material. Reconciliation may become more difficult if message handling is technically valid but operationally fragile. In international payments, that is where readiness is tested. Not at the point where the connection succeeds, but at the point where the institution has to keep data accuracy, exception handling, and traceability intact all the way through the transaction lifecycle.

Financial firms are trying to scale AI while still struggling with fragmented workflows, weak data quality, and control discipline. In a banking environment, what usually prevents an advanced tool from scaling once it meets those conditions?

The biggest barrier is that AI depends on process quality more than many institutions expect. If the underlying workflow is inconsistent, if the ownership of key decisions is fragmented, or if the data path is unreliable, then the tool inherits those weaknesses very quickly.

In banking, that creates a particular problem because advanced systems are often introduced into environments where exception handling, auditability, and accountability already matter a great deal. If the institution cannot clearly explain how a decision was reached, where the source data came from, or how a case moved through review, then scaling intelligence becomes difficult. The technology may appear promising in a controlled setting, but once it enters a live regulated process, the lack of structured inputs and governed execution becomes a limiting factor. In that sense, AI does not remove process weakness. It exposes it faster.

As Quality Engineering Lead for the New York operations of a major international commercial bank, you enabled uninterrupted OFAC-compliant screening, full audit traceability, and continuity across high-risk U.S. banking operations. How did you make that transition work when the bank moved from a legacy sanctions platform to Firco Trust?

The first step was to treat the project not as a simple platform replacement, but as a controlled transition inside a highly regulated environment. I led the replacement of an obsolete sanctions platform with Firco Trust, and that meant the priority was not only getting the new system live. It was making sure screening integrity, traceability, and business continuity were preserved throughout the change.

That required close attention to the workflows that could not break. We validated customer and PEP screening in detail, made sure legacy data was migrated accurately and securely into Firco Trust, and tested the new case-management capabilities for both functionality and operational reliability. I also directed user acceptance testing across environments so stakeholders had enough evidence to approve release decisions with confidence. 

Just as important, we kept the process tightly coordinated across product, engineering, and business teams. Defects had to be resolved quickly, release risk had to be assessed continuously, and audit traceability had to remain intact from the old environment to the new one. That is what made it possible to modernize a high-risk sanctions workflow without losing control of the screening process while the transition was still underway.

More recently, you gave the business greater traceability, clearer governance, and a more reliable way to manage complex cross-border workflows by replacing fragmented Excel-and-email approval chains with a more centralized process. What does a business gain once manual approval chains are pulled into a structured system?

First of all, it’s visibility. Not visibility in a reporting sense, but visibility into the process itself. Once approvals move out of spreadsheets and email threads and into a structured system, the business can see who acted, what was approved, which version is current, where a delay entered the workflow, and how the decision path can be traced later.

That matters because manual approval chains often feel manageable right up until the process becomes multi team, multi region, or audit sensitive. Then the weakness is no longer just an inconvenience. It becomes uncertainty. Teams start spending time reconstructing decisions instead of advancing the work. A structured workflow changes that. It gives the business a reliable approval lineage, clearer accountability, and a better understanding of where the process is slowing down. Before it improves scale, it improves visibility. And in complex financial workflows, that is usually the condition that makes scale possible.

Your approach has centered on identifying risk early and deciding whether a platform is genuinely ready for production. Before a major release in a regulated banking system, what evidence do you need to see before you are comfortable saying the platform can be trusted in production?

In practical terms, it means asking difficult questions before release instead of after an incident. Which business flows carry the most risk? Which dependencies are likely to fail first? What evidence is needed before the team can say the platform is ready? What happens if the data is incomplete, the rule logic conflicts, or the exception volume rises?

That changes the role of quality engineering. It stops being a final checkpoint and becomes part of risk control. The goal is not simply to document defects. It is to understand whether the institution has enough evidence to rely on the system in production.

In highly regulated environments, that difference matters. The cost of uncertainty is higher.

You have led global teams of up to 27 professionals and supported release decisions across regions. When timelines tighten and stakeholders want to move forward, how does a strong quality organization help leadership make a realistic release decision instead of an optimistic one?

A serious quality organization creates clarity. It helps leadership understand what is known, what is uncertain, what is acceptable, and what creates real risk. A weaker organization may produce a lot of reporting, but still leave the business unsure about readiness.

That difference becomes especially visible near major releases. When timelines tighten, can the team identify the issues that actually matter? Can it explain dependencies clearly? Can it help the business make a realistic decision, not just an optimistic one?

If it can, then quality is serving the institution. If it cannot, then a lot of activity may be happening without much real control.

Looking ahead, what will distinguish the banks that scale safely from the ones that keep introducing new instability?

The institutions that scale safely will be the ones that build discipline into the operating model before they build more complexity on top of it. They will understand their data paths, reduce unnecessary workflow fragmentation, make release evidence reusable, and treat observability as part of the system rather than as an afterthought.

They will also be more honest about dependencies. In banking, many failures do not come from a lack of ambition. They come from trying to layer new capability onto processes that are still difficult to see, govern, or explain. The banks that move forward successfully will not just adopt better tools. They will make their workflows clearer, their controls more measurable, and their production decisions more evidence based. That is what allows innovation to scale without creating a new layer of hidden risk underneath it.