Government organizations are pouring money into AI and cloud infrastructure for financial supervision, yet adoption remains uneven. However, a January 2026 Financial Services Matters survey shows that poor data quality and talent shortages continue to slow deployment, with 26% of regulatory authorities still at an early exploration stage and only 7% reporting widespread use. The core issue lies in the foundation: effective supervision systems depend on clean, well-governed, and reliable data, which determines how successfully these technologies perform in practice.
That is precisely the problem Pratikkumar Chaudhari works on every day. As a Project Management Analyst at Datics Inc., he works at the intersection of data governance and financial regulation, building data quality frameworks, governance systems, and analytical tools that support supervisory decision-making at scale. A certified Scrum Master with over 5 years of expertise in Business and Data Analysis, his work spans the full lifecycle of regulatory data — from standardizing definitions and establishing governance controls to designing executive dashboards and driving enterprise-wide data initiatives. Drawing on experience across both financial services and healthcare data, he argues that regulatory roles have evolved into some of the most technically demanding positions in the industry.
The research suggests that the biggest obstacle to modernizing financial supervision isn’t the technology itself but the data quality — poor data, inconsistent definitions, and fragmented systems. From your position at Datics, where major regulatory bodies are among your clients, does this match what you see?
Completely. Working with regulatory clients, one of the first things that became clear was that the challenge lies not in the lack of tools, but in the inconsistencies arising from different units within the division working off different definitions of the same data. A discrepancy may seem minor, but they compound quickly when you are trying to make regulatory decisions at scale. Before you can build any meaningful analytics or supervision system, you have to do the foundational work: establish what the data actually means, where it comes from, and who owns it. This work may sound less glamorous than deploying AI, but it’s what determines whether the AI is useful or dangerous.
Your background is in computer science and data science, and being a Certified Scrum Master is a credential more associated with software teams than regulatory agencies. How did that technical training lead you toward working in financial regulation specifically?
I started my career in business data analysis in India, then moved into healthcare data work in the US, where data quality requirements are notoriously demanding. What I found across these experiences is that the underlying problem is the same everywhere: organizations are sitting on data they can’t fully trust or use. When the opportunity to work in the regulatory data space came up, what appealed to me was the complexity of the regulatory environment and the scale of the data challenge. As a Scrum Master, I had experience coordinating across teams and managing competing priorities, which is exactly what cross-bureau data governance requires.
One of the Dartics’ clients is the New York State Department of Financial Services — a body that oversees the entire New York banking sector, from community and regional banks to foreign and wholesale institutions. Can you describe what the Banking Division needs from its data infrastructure, and what your work in support of that looks like day to day?
The Banking Division alone spans five distinct units, each with its own regulated entities, reporting requirements, and risk profiles. What that means in practice is an enormous volume of data flowing in from very different types of institutions, and the Division needs to be able to see it all coherently. My work includes aggregating and validating large-scale banking datasets, building and maintaining governance frameworks and data dictionaries to establish consistent standards across units, and designing executive dashboards to provide senior leadership with visibility into compliance status and institutional risk profiles. A significant part of the work involves facilitating governance forums, aligning stakeholders across bureaus on data definitions, and producing documentation that makes all of this transparent and transferable.
Throughout your work at Datics supporting the regulatory body, you’ve built centralized entity profile dashboards that unify institution-level data, from licensing and contacts to operational attributes, giving the division a single, coherent view of every regulated entity. For an organization overseeing hundreds of institutions, that level of visibility didn’t previously exist. What did it take to build this, and what changed once it was in place?
The core challenge was that the data existed but lived in different places, in different formats, and was maintained by different teams with different conventions. Building the entity profile dashboards meant standardizing how institution-level attributes were defined, ensuring the underlying data was clean and consistently structured, and then integrating it into a single accessible view. After the data governance work is done properly, the technical side actually becomes the more straightforward one. Once the system was in place, the division could now pull up a coherent picture of any regulated institution without manually reconciling information from multiple systems. That kind of transparency directly affects how efficiently supervisory decisions are made.
One of the projects you’ve been central to is migrating the department’s regulatory systems from a legacy platform to Salesforce and integrating datasets into a unified system to ensure data across the division is consistent, accessible, and properly governed. That is a significant infrastructure undertaking for a government body. What made the shift necessary, and what was the hardest part?
The legacy system — EASy — had served its purpose, but it wasn’t built for the kind of integrated, data-driven supervision the regulatory body is now moving toward. Data was siloed in ways that made cross-divisional analysis difficult, and gaps in data integrity affected the reliability of the outputs. The migration to Salesforce, alongside building a Single Source of Truth — a centralized, shared data structure that eliminates conflicting data layers — and establishing a cloud-based data platform, was about creating an architecture where data is accessible, consistent, and governed from the ground up. Overcoming organizational barriers was probably the hardest part, as the migration required aligning multiple bureaus on shared standards, given that each had its own workflows and historical practices.
Beyond the migration itself, your responsibilities have included building governance KPI frameworks and delivering executive dashboards that allow senior leadership to monitor compliance and institutional risks across the entire Banking Division. That puts you in a position of defining what leadership actually sees, which is a significant responsibility. How do you decide what to measure and how?
You start with understanding what decisions the dashboards are meant to support, which means working closely with senior leadership and the bureaus to understand their supervisory priorities before designing any metrics. You have to consider the risks of doing this wrong in both directions: if you measure too little, you create blind spots; if you measure the wrong things, the leadership may get a false sense of confidence. What I’ve tried to build are frameworks where the KPIs are directly tied to regulatory outcomes rather than metrics that look informative but don’t drive action. The governance layer I mentioned previously matters here too: the metrics have to be based on clean, consistently defined data, or the dashboards themselves become unreliable.
Data governance is understood differently across industries. In a regulatory context, where the definitions you standardize might affect how a bank is assessed or what risk signals get flagged, what does getting data governance right actually require?
It requires treating data definitions as decisions, not just technical choices. When you standardize what counts as a particular field — such as a licensing status, a contact type, an operational attribute — you’re effectively setting the parameters for how institutions get assessed. That means governance has to involve the subject-matter experts, the legal and policy people, and the bureaus that actually use the data to make supervisory decisions. What I’ve found is that the process of building a data dictionary — getting everyone to agree on definitions — surfaces disagreements that weren’t previously visible. That’s uncomfortable, but it’s also where much of the real governance value lies.
One of the most complex aspects of your work has been coordinating across multiple bureaus simultaneously, facilitating governance forums, aligning stakeholders with very different priorities, and producing documentation that must serve both operational and executive audiences. What does this cross-functional leadership actually look like in a regulatory environment, where the stakes of getting alignment wrong are high?
In practice, this means dedicating equal time and attention to both the human and technical sides of governance. Each bureau has its own operational history, its own way of working, and its own perception of what the data means, and those differences should not be reduced to mere bureaucratic friction. The governance forums are where those differences surface, and the job is to work through them systematically. The documentation, such as data dictionaries, process guides, and governance frameworks, provides the foundation that makes the agreements durable. Without it, alignment tends to erode with time as the priorities shift.
You mentioned that the Banking Division is putting considerable effort into transparency — building dashboards that give senior leadership real-time visibility into institutional risk profiles. That’s a different model from how regulators have historically worked. Do you think we’re at a point where “data literacy” inside government becomes as important as legal expertise?
I’d say it’s becoming equally essential, not a replacement. Legal expertise defines what regulation requires; data literacy determines whether you can actually see it happening. The dashboards built for senior leadership provide a practical example. When you can give decision-makers real-time visibility into compliance patterns and risk signals across hundreds of institutions, it improves decision-making quality. But that is possible only when the underlying data is governed well enough to be trusted. The regulators who will be most effective going forward are the ones who understand both sides — the regulatory framework and the data infrastructure that makes it legible. Building that kind of capability inside government, I think, is one of the more important investments the public sector can make right now.
