AI in Banking: How Forward Deployed Engineers Deploy It

What Is AI in Banking?

AI in banking is the use of machine learning, language models and automation inside a bank's operations to detect fraud, assess risk, serve customers, review documents and support staff. It spans old and new techniques: classical models for credit scoring and anomaly detection, and newer generative AI for summarising documents, drafting responses and searching internal policies.

A forward deployed engineer is an engineer who works directly inside the customer's environment to take AI from prototype to production and own the business result. In a bank, that means someone who can read a core-banking integration spec in the morning, sit with a fraud analyst after lunch, and walk a model-risk reviewer through the evidence the next day.

Why Is AI Hard to Deploy in Banks?

International Banker's analysis of why banks deploy AI cautiously lists regulation, explainability, the cost of mistakes, fragmented data and model drift. The same themes show up in Deloitte's 2025 EMEA Model Risk Management Survey of 87 banks and 49 insurers, where respondents cited general AI risks (46%), skills and capabilities (39%), fairness concerns (34%) and the regulatory landscape (34%) among their barriers. Those are European figures, so treat them as indicative for India rather than a local benchmark.

In practice, five constraints decide most projects.

• Regulation. Decisions must be explainable and auditable.
• Legacy systems. Core banking platforms often predate modern APIs, so integration is slow and careful.
• Fragmented data. Customer, transaction and document data sit in separate systems with different definitions.
• Risk culture. One wrong credit decision or missed alert can bring losses, penalties and reputational damage.
• Change resistance. Analysts and branch staff will not use a tool they do not trust.

None of this is a reason not to deploy. It is the reason the deployment skills matter more than the model choice.

What Does the RBI Expect?

For Indian banks, the main reference point is the Reserve Bank of India's FREE-AI Committee report, published on 13 August 2025 and chaired by Prof. Pushpak Bhattacharyya of IIT Bombay. FREE-AI stands for Framework for Responsible and Ethical Enablement of Artificial Intelligence.

According to the RBI's publication page and a KPMG India summary, the framework is built on seven guiding principles, called "sutras", and six pillars grouped into two parts: innovation enablement (infrastructure, policy, capacity) and risk mitigation (governance, protection, assurance). It contains 26 recommendations. Those highlighted include a board-approved AI policy at each regulated entity, extending product-approval, consumer-protection and audit processes to cover AI, stronger cybersecurity and AI incident reporting, governance across the full AI lifecycle, and informing customers when they are interacting with AI.

This is a committee report with recommendations, not a list of final binding rules, and supervisory expectations may have moved since. Confirm the current position with the bank's compliance and legal teams before relying on any specific obligation. The practical takeaway for an FDE is stable though: build with a policy owner, an audit trail, a lifecycle view and disclosure in mind from day one. Our guide to AI governance for forward deployed engineers covers that foundation, and HIPAA, GDPR and SOC 2 for FDEs covers the privacy and security frameworks that often apply alongside it.

Where Banks Use AI: Use Cases and Risk Levels

Not every use case carries the same risk. A sensible FDE sorts them by how much damage a wrong answer can do.

Deloitte's EMEA survey found fraud detection (AML and KYC) was the most common use case among surveyed banks, at 58%, followed by customer experience at 53%. Again, that is a European sample, but it matches what FDEs see: begin where the volume is high and a human can still check the output.

How FDEs Deploy AI Inside a Bank

The method follows the standard FDE project lifecycle from discovery to deployment, adapted to banking's constraints.

1. Discover the real workflow

The FDE shadows the people who do the work: fraud analysts, KYC reviewers, relationship managers. They map the actual steps, the systems touched, the time spent and the errors that matter. The official process and the real process rarely match.

2. Pick a narrow, measurable use case

A good first project has a clear owner, a baseline metric (for example, minutes per alert or documents per hour), accessible data and low-to-medium risk. "Reduce average time to triage a transaction-monitoring alert" is better than "use AI for fraud".

3. Map data and integration early

Most of the effort sits here. The FDE finds where the data lives, who owns it, how it is defined, and how to reach it securely. Our guide to AI data pipelines for messy enterprise data goes deeper. Where the AI must call internal systems, standard connectors help, and MCP for FDEs explains one approach. Core banking systems often predate modern APIs, so the FDE builds careful, auditable bridges rather than touching the core directly.

4. Involve risk and compliance from the start

Bring model risk, information security and compliance into the first weeks, not the last. Agree what evidence they need: model documentation, test results, data lineage and a rollback plan. Waiting until launch week is how bank projects stall.

5. Build for explainability and audit

Every output should trace back to its inputs: the documents retrieved, the rules applied, the model version, the prompt and the human action taken. Logging this is not optional in a bank. It is what lets an auditor reconstruct a decision months later.

6. Design controls and human review

Match the control to the risk. Low-risk drafts may need only spot checks; high-risk actions need approval. The design patterns in LLM guardrails and human-in-the-loop design apply directly. International Banker notes Citigroup has kept some risk and compliance AI in a human-in-the-loop phase where tools assist staff rather than act autonomously, which is a useful pattern to copy.

7. Run in shadow mode, then limited rollout

For weeks, the AI makes recommendations that nobody acts on, while the team compares them with what humans actually decided. Only after the results hold up does it go live for a small group, then widen. Shadow mode produces the evidence the risk committee needs.

8. Drive adoption and monitor

A tool nobody uses has zero return. Training, champions and workflow fit matter; see AI change management. After launch, monitor accuracy, drift, overrides and incidents, and keep a clear path to roll back or retrain.

A Worked Scenario (Hypothetical)

A mid-sized bank's fraud team gets far more transaction-monitoring alerts than analysts can review, and each alert needs context pulled from several systems.

The FDE spends the first week sitting with analysts and discovers that most time goes to gathering information, not judging it. The proposal is narrow: an assistant that collects the customer's recent transactions, prior alerts and KYC notes, then writes a short summary with a suggested priority. The analyst still decides.

Compliance and model risk join in week two and set requirements: full logging, no customer data leaving the bank's environment, and a human decision on every alert. The FDE builds read-only connectors to the case system, logs every summary with its sources, and runs the tool in shadow mode for a month. Analysts mark where summaries missed something. After tuning, the team pilots with a small group, tracks triage time and missed-escalation checks, and expands only after the numbers hold.

The model was the easy part. Access, logging, sign-off and analyst trust decided the outcome. This scenario is illustrative, not a real case.

Skills an FDE Needs for Banking Work

For a fuller map, see our guide to which industries need forward deployed engineers the most, which places banking alongside other sectors, and the sibling article on AI in manufacturing for how the same method changes on a factory floor.

Common Mistakes

Most of these are variations on the patterns in why AI projects fail and how FDEs fix it.

• Starting with the riskiest use case. Autonomous credit decisions are a poor first project.
• Treating compliance as a final gate. Involve risk teams early.
• Ignoring data ownership. Unclear owners stall access for months.
• No audit trail. If you cannot reconstruct a decision, you cannot ship it.
• Skipping shadow mode. It produces the evidence approvers need.
• Assuming one bank's rules apply everywhere. Check the local regulator and the bank's own policies.

This article is general information about AI deployment, not legal or regulatory advice.

TL;DR: AI in banking is not mainly a modelling problem. The models work; what is hard is fitting them into old core systems, fragmented data, strict regulation and risk teams that must be able to explain every decision. Forward deployed engineers (FDEs) close that gap by embedding with the bank, choosing a narrow high-value use case, integrating with existing systems, running the AI in shadow mode, building audit trails and human review into the design, and handing over something compliance can sign off. The usual first targets are fraud and AML alerts, KYC document work, service-desk copilots and internal knowledge search, not autonomous lending decisions.

Banks have money, data and plenty of AI ambition. Deployment is still slow, because the cost of an error is high and the systems around the model are decades old. That is exactly the gap a forward deployed engineer exists to fill. This guide explains what deploying AI in a bank involves, what the regulator expects, and how an FDE works through it step by step.

‍