At a Glance
| Before ZTA-AI | After Pilot | |
|---|---|---|
| Time to answer internal data queries | Hours to days | Under 30 seconds |
| Raw data exposure to AI layer | Direct access | Zero — never |
| Audit trail for AI queries | None | Complete, immutable |
| Compliance team confidence in AI use | Low | Cleared for internal rollout |
| Cross-department data leakage incidents | 2 near-misses | Zero |
| Onboarding time | — | 6 days |
The Organisation
Finova Credit is a lending-focused fintech operating in the MSME segment. With 120 people across operations, compliance, finance, and customer success, they had reached a scale where internal data — loan performance, collections data, compliance registers, risk reports — was being generated faster than teams could make sense of it.
The data existed. The insights were in there. But getting to them meant either waiting for a data analyst to run a query, or exporting CSVs and doing it manually in Excel. Neither was fast enough for the pace the business was moving at.
The answer, everyone agreed, was some form of AI assistant that could answer internal questions in plain language. The problem was that nobody on the leadership team was willing to put a general-purpose AI on top of their customer data, their credit models, or their compliance records without knowing exactly what the AI could see and what it could do with it.
That concern killed two previous evaluations before ZTA-AI came into the picture.
The Problem
Finova's hesitation around AI wasn't unusual for a regulated lending business. It was the right instinct.
Most AI assistant deployments work by giving the model access to the underlying data — connecting it to a database, a document store, or a knowledge base and letting it retrieve what it needs to answer a question. That architecture is convenient. It is also, for a fintech handling borrower data under the DPDP Act and operating under RBI oversight, a compliance liability that most legal and risk teams will not sign off on.
The specific concerns the team had raised were concrete:
Data exposure through the model. If the AI has direct access to borrower records, what stops a carefully worded question from surfacing data it shouldn't? Prompt injection attacks — where a user crafts a query designed to extract information beyond what they're authorised to see — are a documented risk in direct-access AI architectures. The compliance team had read enough to know this was not theoretical. No audit trail. When the AI generates an answer, which data did it access? In what form? Authorised by which policy? Without answers to those questions, the organisation cannot demonstrate to a regulator that its AI system handled sensitive data appropriately. It can only say it thinks it did. Role boundaries don't hold. A collections executive and a finance manager should not be able to ask the same AI assistant and receive access to the same data. In a direct-access model, separating those boundaries at the AI layer is difficult to enforce reliably. One misconfigured permission and the boundary is gone.These weren't hypothetical concerns invented by a cautious legal team. They were the documented failure modes of exactly the architecture every other vendor had proposed.
What ZTA-AI Did Differently
The fundamental difference in ZTA-AI's architecture is that the AI — the language model that generates the response — never touches the data.
When a compliance officer at Finova asks "what is our 90-day NPA rate across the MSME portfolio this quarter," here is what happens:
The question is interpreted by a deterministic layer that understands what data is being requested. That layer checks the asking user's role and permissions against the current access policy. If the request is authorised, it retrieves the relevant data — not the raw records, but a structured, pre-approved summary of the answer. That summary is handed to the language model, which turns it into a clear, readable response.
The language model never saw the underlying loan records. It never knew the database existed. It received a structured claim — a verified, policy-approved representation of the answer — and its only job was to present it clearly.
If the same question is asked by someone without the right permissions, the deterministic layer stops it before the data layer is ever reached. The model doesn't see a redacted version. It sees nothing, because nothing was retrieved.
Every step of that process — the query, the policy check, the data access, the claim generation, the response — is logged to an immutable audit trail. Finova can answer, for any query ever made to the system, exactly what was accessed, by whom, under which policy, and when.
The Pilot
The pilot ran across three departments: compliance, finance, and operations. Each had different data access profiles and different use cases.
Compliance needed to query the organisation's internal regulatory registers, flag tracking logs, and audit documentation. Previously this required a compliance analyst to manually search through shared drives and produce summaries. The turnaround was typically 24 to 48 hours for anything non-trivial. Finance needed quick access to portfolio performance data, disbursement summaries, and collection rates — data that existed in their systems but required an analyst to extract and format before it could be used in a meeting or a report. Operations needed to check loan processing queues, application status summaries, and team-level throughput — things that required logging into multiple systems and manually aggregating what they found.All three departments ran through ZTA-AI with strictly separated data access profiles. A compliance query could not return finance data. A finance query could not surface borrower-level operational records. The separation was not configured once and trusted — it was enforced at the policy layer on every single query.
What Changed During the Pilot
Query turnaround went from hours to under 30 seconds for the large majority of internal data questions that had previously required analyst involvement. The compliance team described this as the most immediately noticeable change — questions that had previously meant a Slack message and a wait now had answers before the meeting started. The compliance team cleared AI for internal rollout. This was the outcome that had blocked every previous evaluation. ZTA-AI was the first architecture the legal and compliance team at Finova was willing to sign off on — because it was the first one where they could answer the question "what can the AI see?" with a definitive answer: only what the policy explicitly permits, in the form the policy explicitly allows, with a log of every access. Two near-miss data exposure incidents were avoided. During the pilot, two queries were submitted that — in a direct-access architecture — would have returned data the requesting user was not authorised to see. The ZTA-AI policy layer stopped both at the gate. Neither reached the model. Both appeared in the audit log with the policy rule that blocked them. Onboarding took 6 days. The operations team had expected integration to take significantly longer given the sensitivity of the data being connected. The no-code connector setup and the role configuration tools meant the technical lift was smaller than anticipated.What the Team Said
"Every other vendor we looked at wanted to put the AI directly on top of our database. Our compliance team killed it immediately. ZTA-AI was the first conversation where we could actually answer the question: what does the AI see? The answer — nothing raw, ever — was the only answer that was going to work for us." — CTO, Finova Credit
"We used to spend a meaningful portion of each week pulling data for internal questions that should have had instant answers. That time is now spent on the actual analysis, not the retrieval." — Head of Compliance, Finova Credit
"The audit trail was the thing that surprised me most. I didn't expect to be able to see every query, what it accessed, and which policy allowed it. That's the kind of visibility we've never had before on an AI system." — CFO, Finova Credit
Where They Are Now
Finova Credit expanded ZTA-AI access to the full compliance and finance teams at the end of the pilot. The operations team rollout is underway.
They are not a large organisation. The problems they were solving were the right scale for where they are — a growing fintech that needed the productivity benefit of AI without the regulatory exposure of giving a general-purpose model access to sensitive borrower data.
The compliance sign-off that had previously been the blocker for every AI initiative in the organisation is no longer a blocker. That is, ultimately, what the pilot was trying to prove.
It did.
Figures reflect platform data from one 8-week pilot engagement. Organisation name has been changed at the client's request.