Choosing an AI partner for banking and insurance

Choose the partner who can show you a regulated system they built, name the controls it passed, and explain what they refused to automate. In banking and insurance, domain experience means audit trails, data residency and a tested failure path, not a slide about financial services. Test the claim before you sign anything.

This article sets out what an AI company in banking and insurance has to prove, which kind of supplier fits which kind of job, six tests that separate real experience from rehearsed vocabulary, and what a first engagement costs at published prices.

What domain experience in banking and insurance actually means

Almost every vendor deck contains a financial services logo wall. The logos tell you a project happened; they do not tell you whether the vendor understood the regime it happened under. Domain experience in this sector is a specific, checkable set of habits, and a team either has them or has never needed them.

The first habit is evidence. A regulated firm cannot deploy a model it cannot explain to an internal auditor eighteen months later, so a partner who works in banking and insurance builds an evaluation suite before the feature, keeps a versioned record of prompts and model choices, and writes decisions to an immutable log. The second habit is restraint. Most of the value in banking and insurance automation sits in preparation, not in final decisions: an agent that assembles a claim file, flags contradictions and drafts the adjuster's note is useful and defensible; an agent that approves the claim alone is neither.

The third habit is architecture that survives a data residency question. If customer data cannot leave the country or the perimeter, the retrieval layer, the logs and the model endpoints all have to sit somewhere the compliance team can point at. Retrofitting that after a pilot costs more than building it correctly in week one, which is why we ask about it on the first call rather than the fourth.

Which kind of AI partner fits which job?

The shortest route to a bad outcome is hiring the right supplier for the wrong shape of work. Five supplier types compete for banking and insurance AI budgets and they are good at genuinely different things.

Most banks and insurers end up with two of these at once: an integrator on the core estate and a smaller specialist on the AI surface. That is a sensible split provided someone owns the seam between them. Decide early which of the two owns the integration contract, the eval set and the incident bridge, because that seam is where most programmes lose a quarter.

Six tests to run before you shortlist

Each of these can be run in a single meeting, and each is hard to fake.

• Ask for the eval set, not the demo. Request the golden question set and the scoring method from a past build. A team that has none has been judging its own work by eye.
• Ask what they refused. A partner with real experience will name a use case they advised a client not to automate. If nothing has ever been refused, nothing has ever been assessed.
• Ask where the data sat. Model endpoint, vector store, logs, traces and prompt history each have a location. A vendor who can answer for all five has done this under supervision before.
• Ask how a wrong answer was caught. The honest reply describes a monitor, an escalation path and a rollback, not a promise that it did not happen.
• Ask who owns the artefacts. Code, prompts, infrastructure definitions, model choices and documentation should transfer to you. Ours do, by default.
• Ask for the hand-off plan. The plan should name your engineers, the runbook they receive and the date they take the pager.

Our general vendor screen, how to choose an AI development company, covers the commercial side of the same exercise. Two answers should end a conversation early: a vendor who cannot name a metric from a past deployment, and a vendor who describes accuracy as a percentage without saying what was measured or on how many cases.

What does a first AI engagement cost in banking and insurance?

A scoped first build sits between $12,500 and $32,000 for most banks and insurers, and the decision work before it is a few thousand dollars. Concretely: an AI Discovery Sprint is ten days at $3,250 or ₹2,00,000, credited against the build that follows. A three-week ProofRun that proves the hardest case against your real documents runs $6,250 to $10,500, or ₹4,00,000 to ₹6,80,000. A production customer service agent with account access and gated actions starts at $12,500 or ₹8,00,000, and a self-hosted agentic system inside your own perimeter starts at $31,500 or ₹20,80,000 plus infrastructure.

After launch, a Care Plan covers the work that regulated systems generate: Essential at $1,000 or ₹68,000 a month, Standard at $2,500 or ₹1,60,000, Enterprise at $5,250 or ₹3,40,000 with a one-hour response and a named engineer. The AI add-on at $750 or ₹40,000 covers evals, prompt regression and re-indexing when a model version changes underneath you. Every starting figure is published on the pricing page, in rupees with GST invoicing for Indian entities and dollars elsewhere.

The regulatory questions that decide architecture

Outsourcing and accountability

The Reserve Bank of India's master directions on outsourcing of IT services make the regulated entity accountable for outsourced activity, which means your vendor contract, exit plan and audit rights matter as much as the model. A partner unfamiliar with the RBI outsourcing guidelines will not anticipate the clauses your legal team will insist on: sub-contracting limits, inspection rights, a business continuity plan and a documented exit with data return.

Data protection and residency

The DPDP Act 2023 governs personal data handling for Indian entities, and insurers carry IRDAI expectations on policyholder data alongside it. In practice this decides whether you use a hosted model API with a data processing agreement or run open-weight models inside your own virtual private cloud. We cover the trade-off in private AI for banks.

Explainability and audit

Assume every automated decision will be reviewed. Log the inputs, the retrieved evidence, the model and prompt version, the output and the human action taken on it. That record is what makes an AI system defensible rather than merely accurate.

When we are the wrong choice

If your problem is a core banking or policy administration replacement, a boutique AI studio is not the right lead contractor. That work needs an integrator with a bench, a decade of migration scar tissue and the appetite for a three-year programme. We will happily sit alongside one and own the AI surface, but we will not pretend to lead the core.

If the use case is genuinely common and non-differentiating, buy rather than build. Off-the-shelf tooling for standard fraud screening or a generic document classifier will be cheaper than anything bespoke. And if your data is scattered across systems nobody has reconciled, the honest first project is not AI at all: it is the integration and cleansing work that has been deferred for five years. We say so on the first call more often than clients expect.

What a first engagement looks like

A non-banking financial company came to us with KYC and loan onboarding documents arriving as scans, photographs and PDFs, reviewed by hand. The constraint was that customer documents could not leave their environment. We built document intelligence that ran privately, with extraction confidence surfaced to reviewers, an exception queue for low-confidence fields and a full audit record of every automated read. The work is described in the KYC document intelligence case study.

The pattern holds across the sector. Start with one process that has volume, a measurable error rate today and a human who can supervise the machine while it earns trust. Related reading on the mechanics: KYC document processing with AI. Claims triage, collections and statement analysis follow the same shape: the machine prepares, a person decides, and the threshold for unsupervised action moves only when the evidence supports it.

Checklist before the RFP goes out

• Name the single process, its current volume and its current error rate
• Decide the residency position before you write the technical requirements
• Agree who signs off each automated action and at what threshold
• Ask every bidder for an eval set, a refusal story and a hand-off plan
• Require code, prompt and infrastructure ownership in the contract
• Budget for shadow running, not just for the build
• Name the internal owner who will review escalations weekly after launch

Related reading

RBI guidelines and AI goes deeper on localisation and audit obligations, AI audit trails describes the record regulators ask for, and our fintech and BFSI practice page lists the systems we work against. If you want a scoping conversation rather than a proposal, get in touch.

The right AI partner for banking and insurance is the one whose evidence you can check, not the one whose references sound the most like you.