Training first, then a centre of excellence, then systems your own teams build. Mapped to EASE 9.0, the RBI FREE-AI framework and the DPDP Act, or to the regulator that applies to you.
Every automated step is logged. Every decision in the right-hand column stays with a named officer.
In brief
EigenSpark trains banking teams, sets up AI centres of excellence, and engineers the systems that come out of them, on the bank’s own infrastructure. Much of that training is SQL, data engineering, cloud and cybersecurity, because a team that cannot query its own data cannot specify a model. One public sector engagement ran the sequence to ten use cases, all on open-weight models inside the bank.
Regulatory frameworks
These three frameworks decide what gets built and where it runs. Below is our work under each one, in the order a bank meets them.
R.I.S.E reform indicators
We write the roadmap against the indicators you are scored on. The LLM and GPU plan, private cloud deployment, tokenisation at scale and the FY 2026-27 capacity-building roadmap arrive in a form your EASE submission can use.
Board AI policy and model risk
We draft the board AI policy and design the oversight that sits under it. Every system we ship carries its model card, evaluation record, vendor position and shut-down path. Your risk function gets the evidence before it asks.
13 November 2026, then 13 May 2027
We design for the 2027 position now. Redaction and tokenisation run before processing, with the keys on your side. Consent state travels with the data, and the audit record answers a data principal request.
We draft the policy and design the governance. We do not certify you as compliant. That judgement belongs to your risk function and your auditors. Outside India we map the same controls to your own regulator’s requirements.
The starting position
Document volume, one record across four systems, GPU capacity, and EASE scoring.
Credit files, KYC packs, grievance tickets, regulatory returns. Staff read, compare and key. Headcount is the only lever most teams have when volume rises.
Any system worth building has to read all four and reconcile them. That work is the project. The model on top of it is the short part.
Cloud has the compute. The data cannot move without a control in place. This gap stops more bank pilots than any modelling problem.
A bought system with nobody trained behind it scores nothing and stops the day the contract ends. Capability has to be visible in the workforce.
How an engagement runs
All three run from month one, reviewed monthly, until your teams ship without us.
A readiness read across data, systems and teams, then a ranked use-case roadmap mapped to the reform indicators the bank is scored on. AI governance and policy work sits here too, including what a board-approved AI policy has to contain under FREE-AI.
Board and executive fluency so sponsors can judge a proposal, technical depth for the data and development teams, and role-specific programmes for business and branch staff. Delivered as a cascade, so each tier can brief the one below it. Not all of it is AI: SQL, data engineering, cloud and cybersecurity tracks run alongside, because they are the floor the rest stands on.
Use cases identified with the business, built by the bank’s own teams with our engineers alongside them, and reviewed monthly. The measure of this track is whether the bank ships the next use case without us.
Use cases
Each one links to the product or the service that delivers it.
Reminder engines that read repayment history, cash-flow pattern and channel preference, and write the nudge in the language the bank already approved.
Agentic AI →Sentiment and intent classification across every touchpoint. Early warning on issues that trend badly, and a check that the branch actually resolved a ticket before it closes.
Generative AI →Draft credit notes assembled from origination systems, bureau reports and core banking, with the risk commentary and regulatory clauses in place for an officer to challenge.
Document Intelligence Engine →Staff ask a question and get the answer from the bank’s own circulars, with the clause cited. Nobody has to call the one person who remembers the last version.
Contract Risk Analyser →Checks against internal policy and reporting requirements run on a schedule, with the evidence assembled as the work happens, so it is ready the day an inspection is called.
Continuous Compliance Monitor →A PII redaction and tokenisation layer that separates personal data from processing data. It is usually the control that has to exist before any other use case can run on cloud infrastructure.
Data Engineering & Platforms →What we offer BFSI teams
Most banking engagements start with training and end up drawing on three of the four.
Where most banking engagements start. AI and the foundations under it.
Strategy, governance and the centre of excellence.
Built for document-heavy, regulated operations.
Working in a specific function? See how we help Risk, Compliance & Governance teams.
Security and controls
On-premise deployment, personal data kept separate, an audit record on every step, and board-level model governance.
We design systems to run on your own infrastructure, with no mandatory public cloud dependency. Open-weight models on your own GPUs are a standard choice here and they hold up in production.
Redaction and tokenisation run before processing, and the keys stay on your side. Your DPDP position holds whether the model runs inside or outside the boundary.
Every automated step records what it read, what it did and what it produced. The detail matches what an inspection or an internal audit asks for.
We document model versions, evaluation results, known limits and the shut-down path. The AI policy your board approves then describes something that exists.
FAQs
Not unless you decide it should. We design on-premise first. Systems run on your own infrastructure, with no mandatory public cloud dependency, and open-weight models on your own GPUs are a normal answer. When cloud is the only route while your own capacity is still being built, we put a redaction and tokenisation layer in front of it. Personal data and the keys stay inside your boundary. What reaches the processing layer carries no identifiers.
We write the roadmap against the indicators your bank reports on. That covers the core AI stack: LLM licensing, the GPU plan and private cloud deployment. It also covers tokenisation at scale, consent management and the FY 2026-27 capacity-building roadmap. We sequence capability building so the evidence exists before IBA compiles the quarterly index.
We draft the board AI policy and design the model oversight that sits under it. Every system we ship carries its model card, evaluation record, vendor position and shut-down path. The June 2026 draft guidance on model risk management goes further on board oversight and vendor checks, and we build to it. We do not certify you as compliant. That judgement belongs to your risk function and your auditors.
In three places. Where personal data may travel. What we redact or tokenise before processing. What the audit record shows afterwards. Consent manager obligations land on 13 November 2026, and full compliance on 13 May 2027. We design against those dates. That is why the redaction layer usually gets built before the use cases that need it.
That is the normal case. The work reads from a core system, a loan origination system, a CRM, a warehouse and the spreadsheets between them. We scope integration in stage two, before anything gets built, because it is usually the longest part of the job.
Because the constraint is rarely the model. The people who understand the process cannot yet specify, judge or run an AI system. A bought tool with nobody trained behind it stops working when the contract ends. Capability building, use-case labs on your own data and a centre of excellence turn one delivered use case into a pipeline your own teams run.
Related
The training catalogue, the centre of excellence service, and two banking case studies.
The deepest training catalogue here, written in banking language.
→ ServiceThe operating model behind a bank that keeps shipping use cases.
→ Case studyThe bank’s own teams, ten use cases, and what it took.
→ Case studyTraining led to an operating model the bank now runs itself.
→ FunctionThe function that most often owns this work inside a bank.
→ PillarThe engineering side, for the systems that go into production.
→Send us one process, one EASE reform indicator, or one team that needs training. We call you within 48 hours and go through what is worth building, what your teams have to learn first, and where DPDP applies before anything runs.
Talk to us