The third meeting on the KYC automation project ends the way the first two did. The operations head wants onboarding in a day. The CISO says no customer document leaves the data centre. The vendor says their product is cloud-only. Someone suggests a pilot on masked data, which tests nothing that matters. The project goes back into the quarter-end pile, and applicants keep waiting for emailed documents.
For a bank or NBFC, “on-premise or cloud” is the wrong first question; the useful questions are where the data sits, who holds the keys and which model is allowed to see it, and each can be answered on its own.
This post is a way to structure that conversation inside your institution. It is not regulatory or legal advice. Your compliance team and advisers should confirm what applies to your licence and data.
“Cloud” bundles three decisions that should be made separately
When a CISO says “no cloud”, they usually mean one or more of three concerns. The data might be stored or processed outside approved locations. Someone other than the institution might be able to decrypt it. Or a third-party model might see customer information and keep or learn from it.
These are different risks with different controls. Treating them as one yes-or-no often forces a worse outcome than necessary: either a blanket refusal or a hurried exception. The table below separates them.
| Question | What it really asks | Typical options |
|---|---|---|
| Where does the data sit? | Storage and processing location | Managed cloud, your own cloud account (VPC), your own data centre |
| Who holds the keys? | Who can decrypt it | Vendor-managed keys or your own keys |
| Which model sees what? | Where inference runs and what it receives | Hosted model, model in your environment, local or open-weight model |
Residency is about location and access, not just a server address
A system can store data in India and still let support staff elsewhere read it, or send it to a model hosted elsewhere for processing. Ask any vendor to map every place a customer document goes: upload, storage, document reading, decision, logs and backups. If one of those steps leaves your approved boundary, residency on the storage layer alone does not settle the question.
A private cloud account in your own name, a VPC on a major provider, often gives a middle path: your account, your region, your network rules, with less hardware to run than a full on-premise build.
Holding your own keys changes who can read the data
Encryption is standard everywhere now. The question that matters is who controls the keys. If the vendor manages them, the vendor can, in principle, decrypt. If the institution holds them, revoking a key cuts off access. For many security teams, customer-held keys plus a clear audit log answer more of the original “no cloud” worry than the physical location does.
Most of the fear in “no cloud” is really “not without our keys and not without our log”. Those can be granted wherever the servers are.
The model question is new, and it deserves its own policy
AI adds a step older software did not have: a model reading the document or drafting a decision. Ask where inference runs, what text or images the model receives, whether anything is retained and whether it is used for training. Some institutions will accept a hosted model with contractual limits. Others will require a local or open-weight model running inside their own environment.
Write this down as a policy, by data class. A PAN card image, a bank statement and an anonymised count of applications do not carry the same risk, and they need not follow the same rule.
On-premise means sizing for your peak, not your average
Here is an illustrative capacity example, not a customer figure. Say an NBFC handles 3,000 applications a month with 4 documents each: 3,000 × 4 = 12,000 documents. Spread evenly over 30 days and 10 working hours, that is 12,000 ÷ 300 = 40 documents an hour.
Now say 40% arrive in the last 5 days of the month. That is 4,800 documents over 50 hours, or 96 an hour. An on-premise setup must be sized for 96, more than twice the average, and sits partly idle the rest of the month. A cloud or VPC setup can scale with the peak. This is not an argument against on-premise; it is a line that belongs in the business case.
The case for keeping everything on-premise
A strong objection: on-premise keeps every component under the institution’s direct physical and administrative control, simplifies some audit conversations and avoids depending on a provider’s region or contract terms. For some institutions and some data, that certainty is worth the extra cost and slower change.
We agree that on-premise is the right answer in many cases. Our point is narrower: decide it per question and per data class, not by habit. And whatever you choose, start AI read-only, with maker-checker before anything is written to your core. Our maker-checker exceptions playbook covers that control in detail.
How AutoKYC is deployed
AutoKYC runs on managed cloud, in your own VPC on AWS, Azure or GCP, or on-premises, with your keys. It supports India data residency when required and local or open-weight models when policy demands it, with SOC 2 Type II and ISO 27001 controls. It is read-only by default, writes only through APIs you open and keeps one audit log for every read, decision and write. The AutoKYC guides and our guide to digital KYC onboarding on WhatsApp describe the journeys it runs.
What to do this week
- Ask your CISO to restate “no cloud” as answers to the three questions: location, keys and model.
- Classify the data in one onboarding journey, from ID images to aggregate counts, and set a rule per class.
- Estimate your month-end peak for that journey and compare it with the monthly average.
- Ask every vendor to draw the full path of one customer document, including logs and backups.
- Take the result to compliance and your advisers before choosing a deployment model.
The institutions that move fastest are not the ones that pick cloud or on-premise first. They are the ones that write down what they are actually protecting.