Banking SLM: Engineering a domain-specialized language model for financial services

2. Why financial services require domain-specialized language models

Banking workflows are shaped by formal product hierarchies, transaction semantics, deterministic processing rules, regulatory obligations, exception paths, and audit requirements. Even straightforward banking scenarios involve multiple systems, policy validations, product states, configuration dependencies, and operational controls operating in sequence.

This complexity means that general-purpose language models, trained on broad corpora, produce responses that are plausible but imprecise in banking contexts. A term like “limit” carries different meanings depending on whether the context is credit, transaction processing, or collateral management. Getting disambiguation right means going beyond just understanding words — it takes real knowledge of how banking products, entities, and processes actually connect and work together.

Enterprise search has improved significantly through semantic retrieval techniques that match queries on meaning rather than keywords. But search and a domain-specialized language model serve different functions. Search locates relevant documents; a banking SLM helps interpret and contextualize information within specific banking products, processes, and operational relationships. The challenge is far greater when AI must help people make operational decisions, where context and accuracy matter more than finding the right document.

3. Building the banking SLM

The banking SLM was built by extending the Infosys’s enterprise SLM foundation through a structured domain-specialization approach designed for financial-services environments (Figure 2). The enterprise SLM provided the language capabilities, deployment characteristics, and enterprise-grade controls required for production use. This enabled the team to focus on semantic grounding, supervision engineering, operational integration, and banking-specific adaptation.

In banking environments, sustainable AI performance requires the combination of model specialization, governance, reliability, observability, and continuous learning. The primary challenge was enabling the model to understand the specialized concepts, relationships, workflows, and business context that define modern banking.

Figure 2. Banking SLM specialization life cycle

Life cycle used to extend the enterprise foundation into a banking-specific model.

Source: Infosys Topaz Fabric Studio

4. Corpus engineering

The first stage focused on building a high-quality banking specialization corpus. Relevant knowledge assets were consolidated from multiple Finacle-related sources, including product documentation, training material, support records, validated resolutions, functional specifications, configuration guides, and implementation references accumulated through years of banking operations [1].

Enterprise knowledge is typically distributed across documents, support records, workflows, and implementation artifacts — not organized for direct model adaptation.

Much of the source material contained redundant information, inconsistent terminology, implementation-specific details, and metadata that could introduce noise or leakage into the training process. To address these challenges, the team implemented a preprocessing and normalization pipeline (Figure 3). This masked sensitive information, removed leakage-prone metadata, standardized banking terminology, deduplicated content, and segmented knowledge into coherent training units. Traceability information was preserved throughout the process, while issue descriptions were aligned with validated resolutions to improve consistency and training quality.

Figure 3. Corpus engineering pipeline

Knowledge preparation pipeline used to create a consistent banking corpus.

Source: Infosys Topaz Fabric Studio

5. Semantic grounding

A high-quality corpus provides the content required for specialization. Semantic grounding provides the context that gives that content meaning. Banking terminology is inherently interconnected. Concepts such as account, collateral, settlement, mandate, product, and limit derive significance from their relationships to business entities, service domains, operational processes, and regulatory obligations.

Capturing these relationships helps the model move beyond terminology recognition toward a deeper understanding of how banking concepts interact within real-world operational environments.

To preserve these relationships during specialization, the team aligned the banking corpus with banking industry architecture network (BIAN)-inspired semantic structures (Figure 4) [2]. This provided a consistent framework for mapping concepts across banking capabilities, encoding relationships among products, entities, and processes, and reducing ambiguity in terminology. The result was a semantically grounded knowledge foundation. It enabled the model to learn not only banking vocabulary but also the contextual relationships that give banking concepts their operational significance.

Figure 4. BIAN-inspired semantic relationship model

This simplified example illustrates how banking concepts derive meaning from their relationships rather than from isolated terminology.

Source: Infosys Topaz Fabric Studio

6. Synthetic supervision engineering

A second challenge involved transforming banking expertise into supervision data suitable for model adaptation. Documentation, configuration guides, support records, and implementation references contain valuable operational knowledge, but they are not naturally available in formats designed for supervised fine-tuning.

To address this gap, Infosys implemented a large-scale synthetic supervision engineering pipeline (Figure 5). Approximately 600,000 banking question-and-answer pairs were generated from the curated corpus, covering a broad range of operational scenarios — including diagnostics, configuration troubleshooting, exception handling, process explanations, dependency analysis, and operational investigations. This substantially expanded the breadth of banking situations represented during model training. Synthetic generation approaches of this kind have demonstrated strong results in knowledge-intensive NLP tasks [3], and this technique was applied at scale to produce banking-specific training pairs with both breadth and operational precision.

A privacy-aware generation framework was applied throughout the process. Masking and sanitization controls ensured that generated supervision data preserved semantic fidelity to source knowledge while preventing the inadvertent exposure of sensitive enterprise information. Generated supervision pairs were evaluated against defined utility and privacy criteria before being considered for training.

Figure 5. Synthetic supervision pipeline

Pipeline used to create the supervision dataset for banking-specific adaptation.

Source: Infosys Topaz Fabric Studio

7. Expert validation

Expert review played a critical role in strengthening the quality of the supervision corpus. Infosys implemented a three-reviewer validation framework involving domain experts and banking specialists. Reviewers evaluated generated supervision pairs for correctness, relevance, semantic precision, and operational applicability.

By combining synthetic supervision with expert validation, the team created a training corpus that was more reliable, consistent, and aligned with real-world banking operations, providing a stronger foundation for model adaptation.

8. Model adaptation

The curated and validated supervision corpus served as the foundation for banking-specific model adaptation. The approach draws on transfer learning principles [4], applying domain-specialized supervision to refine the model’s understanding of banking-specific concepts and relationships.

Through exposure to domain-specialized supervision, the banking SLM developed the ability to work with banking terminology, understand product and process relationships, navigate operational workflows, disambiguate entity references, and reason about business dependencies.

The outcome was more than a model capable of speaking the language of banking. It became a model capable of understanding the structural relationships that underpin banking operations — allowing it to interpret information within the broader context of products, processes, entities, and operational outcomes.

9. Runtime governance and continuous learning

Effective banking AI is built on four foundations: capable models, institutional knowledge, robust governance, and an ongoing process of learning and improvement. These capabilities enable AI systems to operate effectively within enterprise workflows while adapting continuously to new operational scenarios and evolving business requirements. The banking SLM was deployed within a governed operational workflow. The runtime architecture handles query ingestion, preprocessing, response generation, confidence scoring, response ranking, and escalation routing. Responses that fall below confidence thresholds are routed to human review before use in operational contexts — a design choice that preserves governance integrity without requiring human review of every output.

The runtime environment also captures telemetry, observability signals, feedback data, and operational error patterns used to detect response drift, identify knowledge gaps, and prioritize areas for model improvement (Figure 6).

These production insights are incorporated into recurring fine-tuning cycles, enabling the model to evolve as new support scenarios, recurring issues, and knowledge gaps are identified.

Figure 6. Runtime governance workflow

The runtime design combines confidence-based escalation with telemetry and feedback signals that feed recurring fine-tuning cycles.

Source: Infosys Topaz Fabric Studio

10. Results and operational impact

The banking SLM implementation demonstrated that enterprise AI performance is shaped by the interaction of model capability, domain expertise, and operational systems. Semantic grounding, expert-reviewed supervision, runtime controls, and continuous learning enabled the model to interpret banking terminology more accurately, preserve relationships among products and processes, and deliver contextually relevant responses across diverse support scenarios.

The experience reinforced the importance of treating domain knowledge, supervision, and operational feedback as core architectural components of enterprise AI systems.

11. Beyond banking: A repeatable enterprise AI pattern

While this implementation was developed for banking, the underlying pattern applies across industries. Many enterprises possess decades of accumulated expertise embedded in documentation, support records, operational procedures, and specialist knowledge. This institutional expertise represents a valuable foundation for building domain-specialized AI systems.

The broader lesson is that enterprise AI creates the greatest value when domain knowledge, semantic consistency, trusted supervision, and operational learning are treated as core architectural capabilities. Together, these elements help transform institutional expertise into intelligence that AI systems apply reliably within real-world operational environments.

Organizations that systematically transform institutional expertise into operational intelligence are well positioned to strengthen decision-making, improve operational effectiveness, and create sustainable competitive advantage through AI.