AI in Banking, Financial Services & Insurance: Built to Survive an Audit
In most sectors a model has one job: to work. In finance it has three. It must work, give a reason to the customer it turned down, and survive an audit two years later. That rules out a lot of what is sold as AI, and it shapes every answer on this page.
18 min read
Start Here
Four Constraints That Decide What Is Buildable
These are not footnotes at the end of a proposal. These four shape the design, so they come first.
Anyone you turn down is owed a reason
A model that shapes a credit decision must give reasons. A person has to state those reasons and defend them, one case at a time. A bare score with no account of itself will not do. This rules out a few strong methods for underwriting. It is why we use models you can read there, even when a black box would score a little better.
Fair lending is testable, and will be tested
A model may never see caste, religion or gender. It can still discriminate through proxies. Pin code, employer and school all carry that risk. So you test for disparate impact across protected traits. That test is not optional diligence. You should be able to show it on the day it is asked for.
You must be able to rebuild any decision
Two years on, you must be able to say which model version scored an application, on what data, and why. That means you version the model and the inputs together, and keep both. Adding this later is painful. Designing for it at the start costs almost nothing.
Data localisation is an architecture decision
RBI expects payment data to stay in India. DPDP sets rules for personal data. Together they limit where processing may happen. Settle this on day one. Pick the platform after that. Finding it out during a compliance review is a far worse way to learn it.
Indian finance holds more usable structured data than almost any other sector. Each transaction, each repayment, each claim — dated, logged and reconciled. It also has rules that reward care more than cleverness. The best approach is almost never the most advanced model. It is the model that works well enough, explains itself in full, and can be defended in a room with a regulator in it.
The eight use cases below split into two groups. Fraud work and document work carry little regulatory risk. That is where most banks should start. Credit and underwriting carry the most. They need the governance above in place first. They also hold the largest value once it is.
Transaction Monitoring
Learn what is normal for each customer, then flag what is not.
Rule-based systems raise alerts by the thousand. Analysts clear them by the thousand. That is a poor use of trained staff. It is also a reliable way to miss the one alert that mattered. The rules stand still. The behaviour they watch does not.
A behavioural model learns what is normal for each customer. Amounts, counterparties, timing, channel and hour of day. It then flags what departs from that customer's own baseline, not from one threshold set for everybody. A ₹50,000 transfer is routine for one customer and odd for another. A single rule cannot say that.
Alerts still go to analysts. What changes is how they arrive: ranked, with reasons attached. An analyst's day then goes to the alerts that deserve it.
Measure
- Alert volume, and the share actioned
- Analyst time per alert — the real saving
- True positives the old rules missed
- Run the old rules alongside before retiring any
KYC & Onboarding Automation
Read, check and match ID documents so onboarding takes minutes.
Drop-off during KYC is costly, and most of it is self-inflicted. Think of a customer who photographs documents, waits a day, then gets a query about a mismatch. Many of them do not come back. Most of that delay is manual data entry and cross-checking.
The system reads PAN, Aadhaar, cheques and address proof. It checks that the details agree, matches the photograph, and flags only real gaps for review. Clean cases finish in minutes. The rest reach a person with the exact mismatch marked, not a whole file to read again.
Handle carefully
- Aadhaar masking rules are design constraints
- Poor photos are normal — test on real submissions
- Name matching across transliterations needs deliberate work
- Log what was read and what staff changed
Insurance Claim Automation
Extract, validate against policy terms, and separate the routine from the questionable.
Claims come in as documents, in whatever form the claimant had to hand. Your staff or your TPA re-key them, check them against the policy, and pick out what needs a second look. Most claims are routine. Finding the routine ones takes as long as settling the rest.
The system reads the claim data and checks it against the policy. Sub-limits, waiting periods, exclusions. Clean claims are then split from the ones that need a person. Each exception comes with the issue named: this treatment falls in a waiting period, this amount is over a sub-limit.
Turnaround time is often the first thing to improve. In retail insurance, turnaround is what customers judge you on.
Value shows up in
- Turnaround time, which drives renewal more than price
- Consistency of decisions across assessors
- Checks aimed at real anomalies, not random files
- Watch: policy wording changes break the rules
Account Reconciliation
Match across systems automatically and surface only genuine breaks.
Reconciliation is high in volume and rule-shaped. It takes hours of skilled finance time each day. Most items match cleanly. The work is finding the few that do not. That is often done by looking at all of them.
Automatic matching handles the clean majority. It handles the messy cases too: a cut-off reference, or one payment split across two entries. It then shows only the real breaks, with the matches it tried and rejected. That last part matters. An analyst clearing a break wants to see what was tried.
Good early project because
- Errors cost rework, never customer harm
- The measure exists: unreconciled items, time to close
- No regulatory risk beyond the audit trail
- It builds data links that later projects reuse
Regulatory Reporting Automation
Assemble returns from source systems with the traceability an inspection will want.
Each month or quarter, the same people build the same returns from the same systems. The same reconciliation, under the same time pressure. It often happens in a spreadsheet that one person understands.
Automating the assembly is worth doing. The trail matters more. Each figure in a return should link back to the records it came from. When an inspector asks where a number came from, the answer should take one query. It should not take a fortnight of digging.
The real deliverable
- Each reported figure traceable to source transactions
- Same inputs, same output, on demand
- Definition changes versioned, so old periods hold
- Removes key-person risk from the process
Loan Underwriting Automation
Assess creditworthiness with models that produce the reasoning a regulator will ask for.
This is where the value sits, and where the limits are tightest. A model can judge an application faster than a committee, and more consistently. For thin-file borrowers it can read signals an old scorecard ignores. That widens access to credit. It is not only about speed.
Every decision must still be explained, one by one. So we use models you can read, by default. Where a more complex model is justified, we ask for reason codes that hold up case by case. A global feature importance chart is not the same thing. The reason given to a customer you turn down must fit in one sentence, and a branch manager has to be able to defend that sentence. If it cannot, the model does not go live, no matter what it scores.
Fair lending testing starts on day one, not in launch week. A model can discriminate through pin code alone. It never has to see a protected trait to do it. You want to find that during the build, not two years later.
Non-negotiable
- Reason codes per decision, not aggregate importance
- Disparate impact tested and written down
- Model and inputs versioned together, kept for the audit period
- One named model owner who can explain it
Wealth Management Insights
Portfolio insight and suitable recommendations, generated from holdings and stated objectives.
A relationship manager covers more clients than one person can study. So reviews run to a calendar, not to what has changed. The client whose holdings have drifted badly gets the same slot as the client whose have not.
Running the whole book through one analysis shows where attention is needed. Drift from the target mix, concentration risk, a goal now off track. The manager gets a ranked list with the reasoning attached. The work becomes preparing a conversation, not assembling one.
Suitability stays with the manager. The system prepares. The adviser advises.
Boundaries
- Suitability stays with the qualified adviser
- Flagged as talking points, never as advice
- Record what was surfaced and what was done
- Stale risk tolerance and goals, stale analysis
Market & Sentiment Analysis
Read news and commentary at volume to inform positioning and risk.
A research desk cannot read all that is written about its coverage. The volume grows each year. Sorting news, filings and commentary by company, theme and sentiment gives you steady coverage. No team can read that much by hand.
The output is a starting point, not a signal. It tells an analyst that sentiment on a holding has moved, and where to look. That much is useful. Feeding it straight into trading is a different and far riskier thing.
Keep expectations honest
- Coverage and triage, not alpha generation
- Source quality varies; weight it
- Indian commentary spans many languages and formats
- An analyst reads the source before acting
Governance
What Has to Exist Before Anything Goes Live
This is not paperwork for its own sake. One day you will be asked to produce each of these, and building them in is far easier than assembling them later.
- 1
A named model owner
One person answers for how the model behaves, and can explain it in a review. Not a committee, and not the vendor. If no name is on it, no one is watching it.
- 2
Documented validation, including fairness
How the model performs on a held-out sample, broken down by segment. Plus disparate impact testing across protected traits. Write it down at the time. Rebuilding it when asked is not the same thing.
- 3
Versioning of model and data together
Any past decision must be reproducible: this version, these inputs, this output. This is the gap we find most often. It is also the most costly to add later.
- 4
Monitoring with defined thresholds and an owner
Watch population drift, score distribution and performance by segment. Set a threshold that triggers a review. Name the one person who gets the alert. A dashboard no one answers for is not monitoring.
- 5
A documented fallback
What happens when the model is down or withdrawn. Manual underwriting, an older scorecard, or a hold on new cases. Decide that in advance, not during the incident.
Where We Specialise
Agents That Do the Assembly
Finance runs on files. A loan file, a claim, a dispute, a return — each one has to be assembled before a decision can be made. Deciding is skilled work. Assembling is not, and it takes most of the hours.
The four agents below gather, check and draft. None of them decides. Each one hands its work to a qualified person to review. Any step that costs money or touches a customer waits for approval.
Loan Processing Agent
The credit file complete and checked before the officer opens it.
A credit officer spends most of the day finding out what is missing. Documents come in piece by piece. Bureau reports have to be pulled, bank statements read, references checked. Credit judgement itself takes a small part of the day.
The agent builds the file on day one, as the application arrives. It reads and checks the documents, pulls the bureau report, and reads bank statements for income and other loans. It runs the policy checks. It flags what is missing or does not agree, while the applicant is still engaged. What lands on the desk is a complete file with the exceptions marked.
The credit decision stays entirely with the officer. The agent removes the gathering. That is where turnaround time goes, and where applicants drop out.
What it touches
- Documents read and checked against the application
- Bureau reports and internal history
- Bank statements for income, loans and bounces
- Policy checks shown as findings, never a decision
Collections Outreach Agent
Prioritised, appropriate, recorded contact — at a volume a team cannot reach.
Collections is mostly contact attempts. Most accounts in early delinquency — the first thirty days — are not distressed. They are late for ordinary reasons and will pay on a reminder. Costly collector time spent there is time taken from the accounts that need a real conversation. Those are the ones that slide towards NPA.
The agent handles early-stage outreach. Reminders in the customer's own language and chosen channel, payment links, and a record of any promise to pay. Real hardship or a dispute goes straight to a person. It never negotiates a settlement. It never makes contact outside permitted hours.
Conduct rules are not a setting here. They are the design. Limits on how often you call, the hours you may call, language that is barred, and instant escalation on hardship — the system enforces all of it. You are not trusting it to behave.
Conduct is designed in
- Call limits and permitted hours enforced, not configured
- Any hardship or dispute goes to a person
- No settlement talk; that is a human job
- All contact recorded, including what was said
Dispute Resolution Agent
Chargebacks and disputes gathered and evidenced before the deadline passes.
Disputes carry hard deadlines, often a matter of days. Cases are lost on process, not on merit. Evidence is not gathered in time, or a form goes in half filled. The work itself is retrieval and assembly across several systems.
The agent gathers the transaction trail, the authorisation records, the customer's history, merchant details and any related disputes. It then drafts the response pack in the format the network wants, with the deadline tracked. Strong cases are prepared for defence. Weak ones are flagged, so a person can decide whether to contest at all.
A person decides whether to contest, and submits. The agent makes sure nothing is lost to a deadline no one was watching.
Where it pays
- Cases now lost on deadlines, not on merit
- Evidence spread across switch, core banking and merchant records
- Repeat merchant patterns visible across disputes
- Whether to contest stays a commercial decision
Compliance Filing Agent
Returns assembled with sources attached, ready to review rather than to build.
Each month or quarter the same assembly repeats, under the same time pressure. One person knows how the spreadsheet works. That is a single point of failure, and most banks would rather not think about it.
The agent builds each return from source systems on schedule. It reconciles against prior periods and flags any movement outside the expected range. It attaches the trail for each figure. What reaches the compliance analyst is a finished draft, with the odd numbers marked and the sources linked.
The analyst reviews and files. Part of the value is the hours saved. Most of it is that the process no longer lives in one person's head.
The real benefit
- Key-person risk removed from the process
- Every figure traceable to source, as inspections ask
- Movements flagged before filing, not after a query
- The same inputs give the same return
Being Straight About It
Worth doing if
- Lenders with structured transaction history and model governance, or the will to build it
- Teams where document handling eats qualified staff time
- Lenders who want to judge thin-file borrowers on more than instinct
- Teams who accept that explaining a decision limits model choice, and want that respected
Probably not, if
- Anyone who wants the best-performing model, explained or not
- Banks that will not name an accountable model owner
- Credit decisions with no fair lending testing planned
- Teams that skip validation because a vendor says it works elsewhere
FAQ
Questions Banks and Insurers Ask Us
The label is not the question. What matters is whether each decision can be explained, tested for fairness, governed and reproduced. Models that meet that bar are live across Indian lending today. The problem is a model that cannot explain one decline, whatever technique produced it. So we build to the standard rather than to the label. We would rather give up a little performance than hand you something you cannot defend.
For credit decisioning we default to interpretable models. Scorecards, constrained additive models, shallow trees. The reasoning is built into them, not rebuilt afterwards. Every decision comes with reason codes in plain words. Where a more complex model is genuinely justified, those reason codes must hold up one case at a time, under review. Looking sound in aggregate is not enough. Explaining a black box after the fact is not a faithful account of what it did. That is not enough for a decision about someone's access to credit.
It depends on the data and the use case, and this is an architecture decision rather than a detail. RBI expects payment data to stay in India. DPDP sets obligations on personal data. Both limit where processing may happen. Much of what is described here runs on your own servers, or in an Indian cloud region. Where a large language model is involved you have three options: an Indian-hosted deployment, a self-hosted open model, or limits on what data reaches it. We settle this at proposal stage, because it changes both the design and the cost.
We measure outcomes across protected traits. Approval rates, average terms, score distributions. Then we test for disparate impact, even where those traits are not model inputs. Proxies are the real risk. Pin code, employer and school can carry caste or religion without anyone meaning them to. Testing happens from the first week of the build, not as a checkbox at the end. Find it early and you can fix the model. Find it late and you only argue about it.
You notice. That takes monitoring, defined thresholds and someone who owns the alert. We track population stability, score distribution and performance by segment, with a threshold that triggers a review. Drift is normal. The economy changes and your customer mix changes with it. It is a maintenance event, not a failure. The failure is not noticing for eighteen months.
Usually. Finacle, Flexcube and the other common Indian core systems all offer a workable route in. It may be an API, a database read, or a scheduled file exchange. All three work, and they differ mainly in effort. We settle this early. It shapes everything downstream. A vendor who quotes before asking about your core has not scoped the work.
Scoring models are cheap. They are small, they run on a schedule, and they need modest infrastructure. Document extraction scales with volume, but the cost per document stays low. Agents that use a large language model carry a real cost per action. A collections agent contacting thousands of accounts costs a good deal more than one handling hundreds. Model this against your own volumes before you commit, and insist that any vendor does the same.
Your data is yours. You can export it at any time, and we will never make that difficult. You get the working system, the documentation, and training so your team can run it day to day. What else transfers at the end of an engagement — model artefacts, source, licence terms — is set out in the contract before work starts, so there are no surprises either way. If you are regulated, agree up front what you need in order to explain and reproduce a decision for a supervisor. That should shape the contract, not turn up after it is signed.
Reconciliation or document extraction takes six to ten weeks. Transaction monitoring takes three to four months, including a parallel run against your existing rules. Credit decisioning takes four to six months. Most of the extra time is validation and governance rather than engineering. Anyone quoting a credit model in six weeks has not counted the part where it has to be defensible.
No, and we would advise against it at the start. Run both side by side for one full cycle. Compare what each one catches. Retire rules one at a time, once you have evidence, rather than in a single switch. Those rules hold institutional knowledge that is often written down nowhere else. Finding that out after you switch them off is an expensive way to learn it.
This is where models can widen access rather than just speed things up. Other signals can help: banking behaviour, repayment on utilities and telecom, cash flow patterns. They can support lending to thin-file borrowers a bureau score cannot judge. The constraints do not change. Explainable, fairness-tested, governed. And take care which alternative data you use. Some of it tracks protected traits far more closely than it first appears.
It can, if built carelessly. That is why conduct rules are enforced by the system rather than left to a setting. Limits on contact, permitted hours, barred language, and instant escalation on any hardship or dispute. It handles early reminders, where most accounts are simply late. It never negotiates, and it never handles a distressed customer. Anything unclear goes to a person.
Independently, and you should insist on being able to. That means you get the training data specification, the validation method, performance broken down by segment, and enough of the model to reproduce a decision. A vendor who will not provide that is asking you to carry regulatory risk on faith. We provide it as standard, because one day you will need it.
It is normal rather than a blocker. It is work, though, and it should be quoted honestly. Core banking, the card switch, the LOS, the collections system and a CRM rarely share identifiers cleanly. Building one reliable customer view across them is usually the first four to six weeks of a project. It is worth doing well, because everything after it depends on it.
Then we say so. Sometimes the data does not support the use case. Sometimes the governance is not there, and building it is the sensible first project. Sometimes the problem is a process one that no model will fix. In a regulated business a badly founded model is not just wasted money. It is a supervisory finding. We would rather tell you in week two.
Recognise your plant in any of that?
Tell us which problem is costing you most and we will tell you honestly whether it is worth building, what data it needs, and roughly what it costs.
Book a Free ConsultationSee our BFSI solutions