LLM Development Services for Banks: Governance and Gates

A bank should buy LLM development services only from a partner that can show, before production, a governed scope, documented data flows, a repeatable evaluation set and written release gates with named owners. In Switzerland, FINMA treats AI as part of existing governance and risk management, so the partner’s work has to fit your control framework from the first pilot, not be retrofitted at the end.

This article is written for CTOs, Heads of AI, CRO and COO teams at banks, wealth managers and fintechs in Switzerland, the US and Germany. It is not legal advice and it does not promise compliance: it gives you the requirements to put in a statement of work and the questions to ask a development partner.

Key Takeaways

• Define the scope of LLM development services as a lifecycle (use case, data, build, evaluation, run), and require an owner for each stage.
• FINMA Guidance 08/2024 points to data quality, third-party AI due diligence and explainability as areas where supervised institutions need to be able to show their work.
• Data residency depends on the model provider’s actual settings. Verify them in the provider’s documentation, not in a sales deck.
• Evaluation must be built before the pilot starts and re-run on every model or prompt change.
• Production gates should be a checklist with evidence attached, signed by a business owner and an operations owner.

Table of Contents

• What LLM development services for banks actually cover
• Governance: what FINMA expects you to be able to show
• Data residency: verify the provider’s settings, not the pitch
• Evaluation: build the test before the pilot
• Production gates: a checklist with evidence
• Questions to ask a development partner
• How S-PRO helps banks and financial institutions
• FAQ
• Sources

What LLM development services for banks actually cover

LLM development services for a bank cover the full path from a narrow use case to a monitored production service, not only a model integration. If a proposal covers only prompts and an API call, the governance work lands on your team by default.

A complete scope has six parts:

1. Use case definition. One workflow, one user group, one measurable baseline. The Swiss FinTech Innovations and OST report (2025) recommends that production candidates start with a measurable business baseline and an accountable business owner.
2. Data and retrieval design. Which sources the model may read, how access rights carry through, and what is logged.
3. Model and provider selection. Which model, hosted where, under which contract terms, with what exit path.
4. Application build. Prompts, tools, retrieval, output filters, fallback behavior and integration with core systems.
5. Evaluation and documentation. Test sets, acceptance thresholds, model cards and a file that can be handed to an auditor.
6. Run and change management. Monitoring, incident handling and reassessment when a model or provider changes.

The same Swiss FinTech Innovations/OST report recommends compliance-by-design from the start of a proof of concept, a central AI inventory, consistent risk classification and independent review. Treat these as proposal requirements, not as phases for later.

Governance: what FINMA expects you to be able to show

FINMA expects AI to be governed through the risk management and internal control system you already have, and it names specific weak spots. FINMA Guidance 08/2024 summarizes its supervisory observations, and a legal summary of the guidance stresses central management and accountability, independent review by skilled personnel and contractual and liability management of third parties.

Three observations matter most when you choose a development partner.

Data quality

A model is only as reliable as the data it retrieves or was adapted on. Require the partner to document every data source, its owner, its refresh cycle and the checks applied to it. EY Switzerland (May 2026) reads the FINMA guidance as stressing high-quality, well-governed data and regular testing of accuracy, stability, bias and data drift.

Third-party AI due diligence

Most LLM services rely on a model vendor, a cloud platform and often a retrieval or orchestration layer. Each one is a dependency you must be able to assess. The Swiss Bankers Association’s Cloud Guidelines (November 2025) give priority to data security in provider due diligence, to advance notice of changes of significant subcontractors and to retrievability of data, including a termination period and free choice of export formats. Ask your partner to map these points onto the model vendor contract.

Explainability

Explainability is a design requirement, not a report written afterward. Where AI outputs affect clients, employees or regulatory compliance, the output should carry its sources, the retrieval trail and a log of the prompt and model version. The Swiss Bankers Association’s Generative AI in Banking guidance (April 2025) adds that where a decision rests exclusively on automated processing with legal consequences or a considerable adverse effect, the person may generally ask for review by a natural person. Design a human-in-the-loop step for those cases.

The US context: SR 26-2

If you operate in the US, note that SR 26-2, issued on 17 April 2026, replaces SR 11-7 as the model risk management guidance. In our reading it is context only for LLM work: it is not a generative or agentic AI framework, so do not cite SR 11-7 as current and do not assume SR 26-2 settles how an LLM service is validated. Your own policy still has to define that.

For operations touching EU clients, check the EU AI Act separately against each use case, with your legal counsel.

Data residency: verify the provider’s settings, not the pitch

Data residency for an LLM service is set by the model provider’s actual controls, so read the provider documentation and write the settings into the contract. Swiss banking secrecy raises the bar: the SBA Cloud Guidelines require technical and organizational measures that ensure, with near certainty, that no client data are disclosed or that disclosed data do not allow unauthorized persons to identify clients.

Take Anthropic’s first-party API as a worked example. Its data residency documentation describes two controls: an inference_geo parameter, set on each request or as a workspace default, that governs where model inference runs, and a workspace geo that governs where data is stored at rest. In our reading of that page, the workspace geo is US only and the first-party API offers no EU region. The documentation also states that inference_geo is supported on Claude 4.6 and later models and returns an error on earlier ones.

What this means for a Swiss or German institution is a design question, not a verdict:

• Decide which data classes may leave Switzerland at all, and record that in your DPIA. The SBA guidance says the Federal Act on Data Protection applies to personal data processing and calls for a DPIA for high-risk processing, with the FDPIC naming AI as a new-technology risk factor.
• Minimize and pseudonymize before the call. Client-identifying data should not reach the model unless the use case needs it.
• Check hosting alternatives offered through cloud platforms, and read their terms and regions in the platform’s own documentation, as they differ from the first-party API.
• Re-check the documentation before each release. Regions and model availability change.

A partner should hand you a data flow diagram that shows, for each hop, the location, the legal entity, the retention period and who can access it.

Evaluation: build the test before the pilot

Evaluation is the evidence layer for every gate that follows, so it has to exist before the first pilot user does. A demo that impresses a steering committee is not an evaluation.

Require these elements from your partner:

• A golden set. Real, anonymized cases from your workflow with approved reference answers, owned by your business team, not the vendor.
• Task-level metrics. Accuracy against the reference, groundedness in cited sources, refusal behavior on out-of-scope questions and consistency across repeated runs.
• Adversarial tests. Prompt injection through documents, attempts to extract confidential data, and requests that cross client or role boundaries.
• Bias and fairness checks where outputs affect clients, as the Swiss FinTech Innovations/OST report recommends.
• Regression runs. The full set re-run whenever the model version, prompt, retrieval index or tool changes.
• Independent review. FINMA’s observations, as summarized by EY, call for independent review separate from model development for material applications. The builder should not sign off their own work.

Set thresholds in advance. “Good enough” agreed after seeing the results is not a gate.

Production gates: a checklist with evidence

Production gates work when each one has an owner, an artifact and a pass or fail rule. Use this list as the release checklist in your statement of work, and adapt it to your risk classification.

1. Use case approved and registered. Entered in the central AI inventory with a risk classification. Check Annex III of the EU AI Act against the use case where EU exposure exists.
2. Business owner named. One accountable person, with a measurable baseline for the process today.
3. Data protection assessment complete. DPIA done where required, with disclosure-abroad and processing-agreement points addressed.
4. Provider due diligence complete. Security, privacy, resilience, subcontractors, data use, model change notification and exit rights reviewed. Cicrim (August 2026) lists the same areas in its model-risk checklist.
5. Documentation file ready. Purpose, data sources, model selection, performance measures, limitations, testing results and fallback, written so that an external reviewer could follow it.
6. Evaluation passed. Results against the pre-agreed thresholds, reviewed by someone independent of the build team.
7. Human oversight defined. Which outputs a person reviews, which actions need approval, and how overrides are logged.
8. Observability live. Monitoring of usage, exceptions, unsupported outputs, overrides, latency, cost and complaints, with thresholds for alerting, restriction and suspension.
9. Rollback and fallback tested. The business process still runs if the model is switched off.
10. Operations owner accepts handover. The Swiss FinTech Innovations/OST report treats an identified operations owner and accepted handover as part of production readiness.
11. Change triggers documented. A model or provider change triggers reassessment, retesting and approval before it reaches users.

The Swiss Bankers Association guidance recommends a pilot or minimum viable product as a controlled stage for testing technical feasibility, regulatory compliance and user acceptance, followed by MLOps monitoring with defined performance measures. The checklist above turns that recommendation into signable steps.

Talk to our engineers about your release gates

Questions to ask a development partner

A strong partner answers these questions with documents and named people, not reassurance. Use the table in your vendor selection round.

If a partner cannot answer a row, that gap becomes your project risk.

Our view: governance is the product

This is our view, not a regulatory position. In our experience of building AI agents for banks, the model is the easy part to swap and the controls are the part that lasts. A bank that treats the inventory, the evaluation set, the audit trail and the handover as deliverables, with the same weight as the user interface, reaches production with fewer surprises.

We therefore design for human-in-the-loop steps, logging and rollback from the first pilot week, and we argue for narrow first use cases: one workflow, one owner, one baseline. Our solutions are designed with EU AI Act and FINMA requirements in mind, and our team includes Claude-certified engineers and architects who can work with your risk and compliance teams on the evidence each gate needs.

The strongest question a buyer can ask a partner is not which model it uses but who signs the handover and what proof sits behind that signature.

The S-PRO team

How S-PRO helps banks and financial institutions

S-PRO is an international Swiss-American firm with offices in Zurich and Salt Lake City, and global delivery. We build AI agents for banks and software for banks, wealth and asset managers and fintechs. We build each solution on our own agentic platform, S-PRO Agents, and run it as a service, so the monitoring and handover that the gates above require are part of the engagement and not a separate project.

S-PRO was founded in 2014, has 250+ engineers, is ISO 27001 and ISO 27701 certified, and has R&D centers in Zurich and Łódź. S-PRO is a Certified partner in the Claude Partner Network. We have delivered 100+ AI projects, 40+ of them agentic.

If you are choosing a development partner for an LLM service, start with one use case and the checklist in this article. We will walk through your scope, data flows and release gates with your CTO, COO and risk teams. Book a discovery call.

FAQ

What should LLM development services for banks include?

They should include use case definition, data and retrieval design, model and provider selection, application build, evaluation and documentation, and run and change management. A proposal that stops at the integration leaves governance, monitoring and handover with your team. Ask for an owner and an artifact for every stage.

Does FINMA have specific rules for LLMs?

FINMA Guidance 08/2024 sets out supervisory observations on governance and risk management when using AI, covering areas such as data quality, third-party dependencies and explainability. It sits on top of existing technology-neutral requirements. This article is not legal advice, so confirm how it applies to your institution with your compliance function.

Can a Swiss bank use a US-hosted model API?

That is a decision for your risk, legal and data protection teams, supported by a DPIA and a provider due diligence. Check the provider’s documentation for inference and storage locations, because the first-party Claude API currently documents a US-only workspace geo. Minimizing and pseudonymizing data before the call reduces exposure.

How long does it take to reach production with an LLM service?

It depends on the use case, the data and your approval process, so we avoid generic timelines. Narrow scope, an agreed evaluation set and early involvement of risk and operations owners shorten the path. For a first step, we offer a design thinking pilot from USD 20k, 2–4 weeks.

Who should sign off before go-live?

At least a business owner who is accountable for the outcome, an operations owner who accepts the running service, and an independent reviewer who did not build the solution. Risk, compliance and data protection functions sign the points within their remit. Record each sign-off with its evidence in the documentation file.

Sources

• Swiss FinTech Innovations and OST: Bridging the AI PoC to Production Gap (2025)
• Swiss Bankers Association: Generative AI in Banking (April 2025)
• Swiss Bankers Association: Cloud Guidelines (November 2025)
• FINMA Guidance 08/2024 on governance and risk management when using AI
• EY Switzerland: Generative AI in finance, benefits, risks and regulatory expectations (May 2026)
• Federal Reserve: SR 26-2, Revised Guidance on Model Risk Management (17 April 2026)
• Claude Platform Docs: Data residency
• Cicrim: LLM model-risk checklist (August 2026)

Last updated 10 November 2026