The Rise of Generative AI in Banking and Fintech: Architecture, Journeys and Outcomes

Generative AI arrived in banking the way most technology does: first in engineering, then in the back office, and only then, carefully, in front of customers. The banks getting real value from it have stopped asking whether a model can answer a question. They ask whether they can show, for any answer, which data it used, which rules applied and who signed off. This article shows where it fits, a reference architecture that holds up to a regulator, and three customer and staff journeys you can click through, with the outcomes to measure at each one.

Why this is happening now

Adoption is no longer the question. The Bank of England and FCA's third survey of UK financial firms, published in November 2024, found 75% of firms already using AI, up from 58% in 2022, with a further 10% planning to within three years [1]. The same survey found that 46% of those firms had only a partial understanding of the AI they use [1]. That gap, between use and understanding, is the engineering problem this article is about.

The economics are large because banking is a language business. Statements, disclosures, complaints, credit memos, KYC files and suspicious activity reports are all text. McKinsey estimated generative AI could be worth $200–340 billion a year to banking, mostly through productivity [2]. Klarna's assistant handled 2.3 million conversations in its first month, two-thirds of its customer service chats, which it put at the work of 700 full-time agents [3]. By 2025 Klarna was publicly rebalancing toward a hybrid model with more human agents for quality [4]. That correction is the useful lesson: volume is easy to automate, trust is not.

Where it fits, and where it must not decide

A practical way to place a use case is on two axes: how much language work it involves, and how much a wrong answer costs. The cost axis is what matters in finance. A clumsy internal summary is an annoyance. A wrong fee quoted to a customer is a complaint. A wrong credit decision about a person is a regulated harm: the EU AI Act lists creditworthiness assessment of natural persons as a high-risk use [5].

Three patterns fall out of the map. On the left, assist freely: the existing review process (code review, a manager reading the email) already catches mistakes. In the middle, draft and sign off: the model produces a complete draft with its sources and a person approves it. On the right, a person decides and the model prepares: the decision-maker is a validated model or a named human, and the language model gathers evidence and writes up the result.

A reference architecture that holds up to scrutiny

The common mistake is to treat the language model as the system. In a bank it is one component in a request path, and usually not the one doing the important work. The architecture below is the shape that keeps showing up in teams that have shipped: a policy gateway in front, grounding through scoped APIs, a rules engine for anything numerical, write actions behind approvals, and one evidence store underneath everything.

Four design decisions carry most of the weight:

• Scope is set by the gateway, not by the model. The session becomes a scope (this customer, this card, read-only unless stepped up). Every tool call is checked against it, so a prompt injection can at most ask for something the gateway will refuse. Prompt injection is the first item in OWASP's Top 10 for LLM applications for good reason [6].
• Money facts come from code. Fees, refunds, limits and eligibility are computed by the rules engine. The model may explain a number; it never produces one.
• Writes become proposals. Anything that moves money or changes a contract is a typed proposal with evidence attached, approved by a person or, for low-value reversible actions the customer started, by the customer's explicit confirmation.
• Everything lands in an evidence store. Request, scope, model version, sources, tool calls, approver and outcome. This is what you need to answer a complaint, reproduce a decision, and show model risk controls working under the PRA's SS1/23 principles [7].

Here is the core of the write path in code. The point is how little of it involves the model:

from dataclasses import dataclass
from decimal import Decimal

@dataclass(frozen=True)
class Scope:                      # built by the gateway from the session, never by the model
    customer_id: str
    card_ids: frozenset[str]
    can_write: bool               # true only after step-up authentication

@dataclass(frozen=True)
class ProposedAction:             # what the model is allowed to produce for a write
    kind: str                     # "chargeback" | "cancel_recurring" | "freeze_card"
    card_id: str
    amount: Decimal
    reason_code: str
    evidence: tuple[str, ...]     # ids of transactions / documents it relied on

AUTO_APPROVE = {"cancel_recurring", "freeze_card"}   # customer-initiated, reversible

def handle_proposal(p: ProposedAction, scope: Scope, request_id: str) -> dict:
    if p.card_id not in scope.card_ids:
        return refuse(request_id, "out_of_scope")          # model asked for a card it may not touch
    if not p.evidence:
        return refuse(request_id, "no_evidence")           # no sources, no action
    if p.kind == "chargeback" and p.amount != rules.charged_amount(p.evidence[0]):
        return refuse(request_id, "amount_mismatch")       # money facts come from the rules engine

    evidence_store.append(request_id, scope=scope, proposal=p,
                          model=MODEL_VERSION, sources=p.evidence)

    if p.kind in AUTO_APPROVE and scope.can_write:
        return execute_after_customer_confirms(p, request_id)
    return approval_queue.submit(p, request_id)            # a person approves anything else

The model's job ends at producing a well-formed ProposedAction. Whether it is in scope, whether the amount is right, whether it needs a person, and what gets recorded are all decided by ordinary, testable code.

User journeys and their outcomes

Architecture diagrams hide what a customer or member of staff actually goes through. The three journeys below follow real request shapes from start to outcome. Open each one, then hover, tap or tab through the numbered steps. Each journey ends in more than one outcome, because the honest version of an AI journey always includes the branch where it hands over to a person.

Notice what the journeys have in common. The model never decides who someone is, never computes money, and never takes an irreversible action alone. It does the slow parts that used to need a person on the phone or at a keyboard: finding the facts, explaining them, asking the one missing question, and writing the first draft.

What to measure

Demo quality is a poor guide. Measure each journey on outcomes the business and the regulator already care about:

The FCA's Consumer Duty makes the last column more than a nice-to-have: firms have to show they deliver good outcomes, including customer understanding and support that does not create unreasonable barriers [8]. An assistant that deflects contacts but raises repeat contacts is a worse outcome, not a saving.

Risks and the controls that address them

A rollout path that earns trust

Teams that try to start with a customer-facing agent that can move money usually stall in risk review. Teams that climb a ladder, and pass an explicit gate at each rung, tend to get there faster because each rung produces the evidence the next one needs.

What this means for teams building it

The work is mostly not prompt engineering. It is the gateway that turns a session into a scope, the typed tools that return facts, the rules engine that owns every number, the approval queue that makes a person's decision a piece of data, and the evidence store and evaluation harness that let you prove all of it. Build those, and the language model becomes a replaceable part. That is the right place for it in a bank: very useful, and never the only thing standing between a customer and a wrong answer.

References

1. Artificial intelligence in UK financial services – 2024 — Bank of England and FCA, November 2024
2. The economic potential of generative AI: the next productivity frontier — McKinsey & Company, June 2023
3. Klarna AI assistant handles two-thirds of customer service chats in its first month — Klarna, February 2024
4. Klarna customer service: from AI-first to human-hybrid balance — PromptLayer
5. Regulation (EU) 2024/1689 (Artificial Intelligence Act), Annex III — EUR-Lex
6. OWASP Top 10 for LLM Applications — OWASP GenAI Security Project
7. SS1/23 Model risk management principles for banks — Prudential Regulation Authority, May 2023
8. Consumer Duty — Financial Conduct Authority
9. NIST AI 600-1: Artificial Intelligence Risk Management Framework, Generative AI Profile — NIST, July 2024