Modernizing Financial Data Infrastructure: An Interview with Business Intelligence Architect Nithish Shetty

Financial systems do not tolerate casual data handling. Tax lot records, security attributes, pricing feeds, and vendor mapping rules may appear small within a pipeline, but they can shape what appears in valuation, reporting, and compliance workflows. A Deloitte survey found that 94% of banking and capital markets data users identified data accuracy and reliability as critical priorities.

That is the kind of operating pressure behind Nithish Shetty’s work. A Lead Business Intelligence Architect with more than 14 years of experience across financial systems, retail operations, analytics platforms, and data governance, he built part of his foundation in Tax Lot Accounting, securities reference data, pricing workflows, and analytical infrastructure.

He has also served as a Beta University Builders of Tomorrow AI Super Hackathon judge, a role that fits his view of technical work: strong systems should be inventive, but they also have to be testable, traceable, and practical.

What first drew you to tax lot accounting infrastructure?

Tax lot accounting sits behind investment operations, but it carries real weight. It helps determine how securities are tracked, how pricing data is applied, and how reporting teams gain confidence in the records they use.

What drew me in was the precision. A tax lot system is not just a reporting layer. It connects to portfolio valuation, client reporting, and regulatory obligations. My focus was to make the surrounding workflows more dependable so the business could rely on the information moving through them.

What made the support environment complex?

The Tax Lot Accounting platform depended on many connected pieces: pricing inputs, reference attributes, ETL workflows, exception handling, and reporting needs. When something failed, the cause was not always obvious.

I was the sole L2 support owner for the TLA platform, so the work was both operational and architectural. I had to resolve incidents, but also look for patterns. If the same support issue kept appearing, the better answer was not more manual effort. It was a stronger workflow design.

How did the ETL modernization work help?

The ETL layer controlled how data moved across systems. I worked on pipelines that integrated mainframe and HDFS Hadoop platforms, which required careful attention to processing logic and analytics accessibility.

One result was approximately a 20% improvement in ETL processing and analytical query performance. That was important because shorter runtimes helped teams investigate issues and complete analysis with less friction. In that kind of environment, performance is not just about speed. It also helps people see problems sooner and handle exceptions with more control.

Where did securities reference data fit into the project?

Reference data was one of the foundations. If a security attribute is incomplete, mismapped, or inconsistent, the issue can affect pricing checks, reporting control points, and compliance-related workflows.

In the SMSV (Security Master Strategic Vision) program, I supported validation efforts involving more than 482,000 securities and over 596,000 associated data attributes. I view that as infrastructure work, not cleanup work. At that scale, the important question is whether the process can keep producing reliable checks, not whether one team can manually inspect everything after the fact.

What role did test coverage and mapping rules play?

They gave structure to the work. Across CARMA and STARRS, I executed more than 5,000 test cases, completed more than 500 analytical queries, and helped define more than 100 vendor data mapping rules.

Those rules mattered because external data sources often carry different formats and assumptions. A mapping rule gives the team a shared way to understand how one source connects to another. Test coverage then checks whether that logic holds across real scenarios.

What did the Bloomberg pricing comparison make possible?
It created a more organized way to evaluate pricing vendor coverage. The Bloomberg coverage and price comparison analysis gave the U.S. pricing team its first structured vendor comparison framework through a Data-as-a-Service analytical approach.

That changed the vendor evaluation conversation. Instead of reviewing isolated examples, pricing partners could compare coverage and differences in a more systematic way. The goal was not to make the decision for them. It was to give them a clearer analytical base for the decision.

You have written about rule engines in finance. Why does that matter here?

Finance needs explainable controls. Machine learning can be useful, but many financial data problems first need deterministic checks. Teams need to know which rule ran, what exception was flagged, what changed, and whether the result can be explained later.

That is the argument I made in my HackerNoon article, “Why Finance Data Quality Needs Rule Engines, Not ML Hype.” The article focuses on rule engines, governance, vendor controls, and audit trails that regulators and business teams can understand. An IBM Institute for Business Value report found that 43% of chief operations officers cited data quality as their most significant data-related challenge.

How does auditability shape financial data infrastructure?

Auditability changes how you design. If a number appears in a report, the organization should be able to explain where it came from, how it moved, what rules applied, and how exceptions were handled.

That matters in tax lot accounting because pricing data, securities attributes, and reporting logic are connected. Forrester found that organizations can lose more than $5 million annually due to poor data quality. In financial environments, the concern is also confidence: whether teams can defend the path from input to report.

What did this work teach you about building better financial systems?

It taught me that strong infrastructure is often quiet. It shows up when support workflows need fewer manual steps, when mapping logic is clear, when test coverage catches risk earlier, and when pricing teams have better evidence for vendor decisions.

The work was also reflected in senior director and service delivery leader level award citations tied to technical delivery, innovation, reference data controls, and business enablement. That mattered because the improvements were not abstract. They helped make a complex financial data environment easier to support and easier to explain.

For Shetty, modern financial data infrastructure is not about adding complexity for its own sake. It is about strengthening the control points that allow tax lot records, pricing inputs, vendor mappings, and reference attributes to move through systems with clarity. In that sense, modernization begins with discipline: cleaner workflows, better checks, and evidence that can stand up when accuracy matters most.