A regulated firm should decide between fine-tuning a general LLM and building on a domain-specific language model by starting with tools and retrieval, adding fine-tuning where evidence shows a need for consistent style or lower high-volume cost, and choosing a domain-specific base model where jargon density and format conventions dominate the workload. Most production systems combine these methods (Mavik Labs, 2026), with policy checks and evidence capture around the model.
Engineering leaders in financial services face this choice whenever they bring language models into decision workflows. A general-purpose model starts with broad capability and no native grasp of financial terminology or regulatory formats. A domain-specific model starts with that grasp already embedded, and fine-tuning sits between the two. The sections below set out the mechanics and governance implications, with a decision table and examples from regulated banking.
Why this decision matters in regulated environments
Much of the AI in financial services is built on models a firm did not train. In the Bank of England and FCA's 2024 survey of 118 UK firms, foundation models made up 17% of all AI use cases, and a third of all use cases were third-party implementations (Bank of England and FCA, 2024). The choice between adapting such a model and adopting a domain-specific one therefore shapes what evidence a firm can produce for each decision.
Regulators set those expectations by instrument. Under the EU AI Act, creditworthiness assessment is a high-risk use. Record-keeping (Article 12) is a design requirement that the provider builds into the system. The bank is usually the deployer, and keeps the automatically generated logs for at least six months within the documentation that financial services law already requires (Article 26(6)). Both obligations apply to these systems from 2 December 2027. For UK banks with internal model approval for regulatory capital, PRA SS1/23 expects vendor models to be validated to the same standard as in-house ones. Whichever approach a firm takes, the record has to show which model version produced each output under which policy.
IBM's overview of domain-specific LLMs notes that these models understand industry-specific jargon and formatting conventions, and says specialisation can make them more safe and trustworthy in areas with strict regulatory and compliance frameworks. Screening narratives and credit rationales both depend on specialist terms and fixed formats, so the choice of model shapes how much of that work a reviewer must correct.
Agentic systems add a second dimension. When an agent plans and acts, controls apply at several points: a release control decides whether a model or prompt version may be promoted, a request check records principal, purpose, jurisdiction and policy version before the model sees the request, validation runs on each output and tool call before it takes effect, and monitoring runs after release. None of these controls stands in for another, and the same four points apply whichever model approach a firm chooses.
What fine-tuning and domain-specific models are
Fine-tuning adapts a pre-trained general LLM on domain data using techniques such as supervised fine-tuning (SFT) or parameter-efficient methods like LoRA. The base model weights change only where the adaptation data directs them. A domain-specific LLM is trained or adapted from the outset on corpora that reflect the language and structure of finance or legal work.
BloombergGPT is the extreme form of domain-first training. Wu et al. (2023) built a 50 billion parameter model on a 363 billion token financial dataset, augmented with 345 billion tokens from general-purpose datasets. Most regulated teams will not train from scratch. They will choose between adapting a general base, through fine-tuning or continued pre-training on internal corpora, and starting from a commercial domain model.
Hybrid approaches combine fine-tuning for style and reasoning with retrieval-augmented generation (RAG) for live regulatory data. The distinction matters because fine-tuning moves knowledge into the weights, while retrieval keeps knowledge outside them, so it can be updated without retraining. Policy text that changes quarterly calls for retrieval. House style and stable risk language call for weight updates.
How each approach works in practice
Fine-tuning updates model weights on labelled or instruction pairs. Full fine-tuning changes all parameters. Parameter-efficient fine-tuning (PEFT) trains a small set of added parameters, such as LoRA or QLoRA adapters. Both need a labelled dataset that captures the desired behaviour and a training run that can be audited for data lineage and evaluation scores before promotion, with every version pinned.
Domain-specific training from scratch or continued pre-training exposes the model to domain text at scale. That improves precision on jargon-heavy tasks, but it does not keep pace with overnight policy changes. IBM's comparison of RAG and fine-tuning frames the split: RAG connects an LLM to proprietary databases for current, private data, while fine-tuning retrains on focused external data for domain tasks.
RAG augments prompts at inference time without altering weights. It suits policy documents and case files that change faster than a retraining cycle allows. A peer-reviewed comparison found that RAG consistently outperformed unsupervised fine-tuning at injecting both existing and new knowledge, and that models struggle to learn new facts through unsupervised fine-tuning (Ovadia et al., 2024).
Tools and deterministic function calling handle exact calculations and policy checks. Language models struggle with basic functionality such as arithmetic, and a model trained to call tools such as a calculator improves on those tasks (Schick et al., 2023). Rate calculations and sanction-list matches therefore belong in tools with typed contracts rather than free-form generation. A practitioner blog from Mavik Labs (2026) reaches the same split, with fine-tuning reserved for consistent style and high-volume cost, and reports that most products need a hybrid.
How the four approaches compare
The table below sets when each approach fits against its cost and its support for audit. Costs vary by firm and by volume, so the cost column describes the shape of the spend and sets no figures.
| Approach | Use when | Cost shape | Auditability |
| Fine-tuning a general model | Style and mandatory phrasing must stay consistent, or serving cost at high volume matters | A training run and evaluation upkeep, then lower cost per request at volume | Record data lineage and evaluation scores for each pinned version; the weights change, so each version is a controlled artefact |
| Domain-specific base model | Jargon density and format conventions dominate the workload | Highest upfront cost when trained from scratch; lower when a commercial domain model is the starting point | The same records as fine-tuning, plus provenance of the training corpus |
| RAG | Knowledge changes faster than a retraining cycle | Retrieval infrastructure and content upkeep; no training run | Log which documents were retrieved for each answer and which version of each |
| Tools | Facts, identifiers, calculations and policy checks must be exact | Engineering for typed contracts; deterministic at run time | Typed inputs and outputs make each call reproducible |
Where each approach sits from human review to autonomy
Under human-in-the-loop review, a person checks each output, and any approach can serve as a drafting aid. In semi-autonomous operation, each approach handles the work the table assigns it, and humans review the exceptions that fall outside the contract. Broader autonomy follows only where the evidence and reversal paths already support it.
Key concepts and terminology
Teams need a shared vocabulary for these discussions. Supervised fine-tuning (SFT) teaches a model to follow labelled instruction-response pairs. Direct preference optimisation (DPO) and odds ratio preference optimisation (ORPO) align outputs to ranked human or policy preferences without a separate reward model. Continued pre-training (CPT) extends the base model's domain fluency on large unlabelled corpora. Low-rank adaptation (LoRA) and quantised LoRA (QLoRA) add small trainable matrices so domain behaviour can ship without rewriting every base weight.
Model merging combines multiple fine-tuned checkpoints. A 2025 npj Computational Materials study on materials informatics reported that fine-tuning on domain-specific data improves performance for smaller models, and that merging fine-tuned variants can produce capabilities that surpass the individual parents. The effect appeared in the 7B and 8B models and was absent in the 1.7B model, so merging does not make a small model match a larger one. The study is materials-focused, so treat its findings as an experiment to repeat on financial tasks.
Request checks and evidence connectors define the runtime controls in agentic pipelines. The request check decides whether an intent may proceed. The evidence connector writes the policy version, inputs, tool results and model trace into an immutable store. Domain-driven design supplies the bounded contexts that keep financial policy coherent across these layers, so credit and screening services do not share conflicting definitions.
Regulated financial-services use cases
Screening and economic-crime prevention workflows need reproducible audit trails for every alert decision. The model may draft a narrative or rank weak signals, but list matches and case routing resolve through deterministic tools. The request check records who requested the screen and under which policy pack. Bugni's published results include commercial customer onboarding reduced from 10 days to under 12 hours at a major UK bank (screening platform).
Credit decisioning and regulatory narrative automation need style consistency and policy adherence on every output. Fine-tuning helps lock house voice and mandatory disclosure phrasing. Retrieval supplies the live product rules and affordability tables, and tools compute the scores that the model must not invent. Bugni's published results include roughly 20 microservices taken from blank sheet to production in four months at a UK challenger bank (credit decisioning platform). More detail sits in the case studies.
Core-banking modernisation layers agentic reasoning over event-driven platforms, so each transaction carries its governance trace from the first request check. Event-driven architecture provides the durable event log that makes those traces queryable afterwards. Across these use cases the model choice sits inside a wider design, and the placement of controls and the capture of evidence carry as much weight as the model itself. Semi-autonomous agents change the operating model: humans set policy and review exceptions, and agents execute bounded work inside the envelope that the controls define.
Benefits, trade-offs and governance implications
Fine-tuning delivers consistent voice and lower per-token cost at high volume once the training run is complete, and domain-specific models improve precision on jargon-heavy tasks. Retrieval keeps regulatory content current, but it cannot enforce deterministic policy checks or guarantee consistent output style, so a hybrid covers gaps that a single method leaves.
Bugni recommends placing controls at every point, so that the trace shows who asked, which policy applied, which tools ran and why the action was allowed. A request check records the first of those facts before the model runs. Output and tool-call validation records the rest before anything takes effect.
Treat model merging as an experiment under the same evaluation harness as any other weight change. Promote a merged checkpoint only when it clears the release gate on offline cases and on shadow traffic. AI-native engineering describes engineering pipelines that test system behaviour and evaluate AI components continuously, while human engineers keep responsibility for the architecture. For the wider context, see Generative AI for regulated enterprises.
Common misconceptions and anti-patterns
Assuming one method solves every requirement. Retrieval suits fresh organisational knowledge, but a RAG-only stack leaves calculations and style drift unaddressed.
Treating fine-tuning as a one-time event. Products and house style change, and a model fine-tuned once drifts from them. Schedule re-evaluation and keep a rollback path, as for any other production model artefact.
Relying on one control point. A release control cannot see an instruction injected at runtime, and a request check cannot see a wrong output. Each control sees failures the others miss.
Leaving calculations to the model. Calculations and policy enforcement belong in deterministic tools, because a language model cannot perform them reliably.
Training on live customer data without a retention design. Expanding a domain model's training set with live customer data, with no retention and lineage plan, mixes static domain knowledge with organisational data and complicates audit. Keep stable patterns in the weights and live facts in retrieval.
Further reading
