SystemebeneAI ENGINEERING · SOFTWARE SYSTEMS · INFRASTRUCTUREDE

AI Compliance in Swiss Banking: What FINMA Expects, Where It Fails and What Engineering Can Do

Switzerland has no dedicated AI law, but FINMA has clear expectations for governance and risk management. What Guidance 08/2024 means in practice and which technical patterns help.

24 min read
  • #AI Engineering
  • #Compliance
  • #Finma

Switzerland has no AI law. That is the first sentence in almost every presentation on the topic, and it is correct. It is also often used as though the absence of an AI-specific statute meant the absence of requirements. The opposite is true. Existing principle-based rules on governance, risk management and outsourcing continue to apply unchanged; institutions simply have to work out for themselves what those rules mean for a RAG system or an agent. Much of that translation is engineering work rather than legal work.

FINMA made this explicit in Supervisory Guidance 08/2024: Switzerland currently has no AI-specific legislation, while the technology-neutral, principle-based requirements of financial-market law for effective governance and risk management already cover risks arising from AI. (FINMA Guidance 08/2024) The associated principle is same business, same risks, same rules. (FINMA)

The practical questions are therefore what actually applies, where implementation tends to fail and which technical patterns help. I will close with the publicly documented state of AI adoption at individual Swiss banks.

What actually applies

Supervisory Guidance 08/2024 as the reference document

Guidance 08/2024, published on 18 December 2024, is not a FINMA circular and is therefore not formally binding in the same way. In practice, it is the most important reference because it describes what FINMA actually examined in supervisory discussions and on-site reviews. It covers seven areas: governance, inventory and risk classification, data quality, testing and ongoing monitoring, documentation, explainability and independent review. (FINMA Guidance 08/2024)

The most useful part for implementation appears in a footnote. FINMA lists factors that influence the materiality of an application: relevance to compliance with financial-market law, financial impact, legal and reputational risk, relevance of the product, number and type of affected customers, and consequences of failure or error. It separately lists factors affecting probability of occurrence: complexity, type and volume of data, inadequate development or monitoring processes, degree of autonomy and process integration, dynamism, chaining of several models, and exposure to attacks or outages. (FINMA Guidance 08/2024)

That is essentially a ready-made classification matrix. An institution building a model inventory can use those two axes directly instead of inventing a private taxonomy that then has to be explained during an audit.

The definition of AI is also notable. FINMA explicitly expects a broad definition and refers to the OECD approach because classical applications can create similar risks and equivalent risks should be treated equivalently. It observed institutions defining AI narrowly in order to focus on supposedly larger or newer risks. (FINMA Guidance 08/2024) An inventory limited to LLM applications while excluding a long-running credit-scoring model therefore misses the expectation in the more uncomfortable regulatory direction.

What has been added since

In April 2025, FINMA published the results of a survey of roughly 400 supervised institutions conducted between late November 2024 and mid-January 2025. Around 50 percent already used AI or had initial applications under development, with another 25 percent planning adoption within the next three years. Institutions reported an average of five applications in production and nine under development. Of those using AI, 91 percent also used generative AI. Only about half had an explicit AI strategy. Among the 187 supervised institutions already using AI, 100 were banks and securities firms. (FINMA survey)

The most practically important sentence in the press release appears at the end: FINMA recommends contacting it early if AI is to be used in critical processes or for calculating regulatory metrics. (FINMA survey) That is the threshold at which a project stops being purely an internal matter.

The November 2025 Risk Monitor is interesting partly for what it does not list. FINMA identifies nine major risks rated high: real estate and mortgages, other credit, credit spreads, liquidity and refinancing, money laundering, sanctions, outsourcing, cyberattacks and ICT risks. AI is not one of them. (FINMA Risk Monitor 2025) That is consistent with technology-neutral supervision: AI risks materialise inside existing categories, particularly outsourcing and ICT. In supervisory practice, an AI application is therefore examined in the ordinary operational-risk framework, including the expectation that systems remain resilient when individual components fail.

In April 2026, FINMA added Supervisory Guidance 02/2026 on digital fraud risks at banks and persons under Art. 1b of the Banking Act, based on a survey of 19 banks across several supervisory categories conducted in late 2025. It matters here for two reasons. First, FINMA explicitly points to the trend towards AI tools and automation in account administration and payment processing and expects an appropriate control framework, including under FINMA Circular 2023/1 on operational risks and resilience. Second, it expects technical means for detecting deepfakes and manipulated video. FINMA also found that thresholds for suspicious retail transactions among low- and normal-risk customers were often fixed at CHF 100,000 to 200,000, meaning static limits rather than analytical scenarios. (CMS on FINMA Guidance 02/2026, FINMA)

AI therefore appears on both sides of the same guidance: as a tool used by attackers and as an expected part of the defence.

The framework outside FINMA

Four additional strands matter, and none is new.

Banking secrecy. Art. 47 of the Banking Act does not prohibit processing customer data abroad as such. The Swiss Bankers Association’s cloud guide, based on a legal opinion, explains the practical requirement: the institution has to limit access risk appropriately through technical, organisational and contractual measures. Where data is pseudonymised, the mapping rule should remain under the bank’s control in Switzerland. (SBA cloud guide, LAUX legal opinion) For LLM architecture, the place where de-pseudonymisation happens is therefore a compliance artefact, not an implementation detail.

Outsourcing. FINMA Circular 2018/3 applies where a service provider assumes a material function. Its applicability has to be assessed for machine-learning services with access to significant volumes of customer data. (SBA cloud guide) Guidance 08/2024 adds expectations around additional tests, controls and contractual clauses covering responsibilities and liability, together with an assessment of the service provider’s capabilities. (FINMA Guidance 08/2024)

Data protection. Art. 21 of the Swiss Data Protection Act gives people affected by an exclusively automated individual decision with legal effects or significant adverse consequences the right to state their position and have the decision reviewed by a natural person. That is a hard boundary for fully automated credit decisions. A nominal human-in-the-loop who simply approves whatever the system says does not solve the problem; the review has to be substantive.

EU AI Act. The regulation has extraterritorial reach where an AI system is placed on the EU market or put into service there, or where its output is used in the EU. A Swiss bank serving EU customers can therefore fall within scope for those activities. Creditworthiness assessment is a high-risk category under Annex III. The May 2026 Digital Omnibus agreement, however, shifted the high-risk deadlines substantially: Annex III to 2 December 2027 and Annex I to 2 August 2028. (Summaries of the Omnibus agreement) This timing is based here on secondary sources; anyone planning against it should verify the final legislative text.

What is still coming. In February 2025, the Federal Council decided to ratify the Council of Europe’s AI Convention and adapt existing Swiss law rather than introduce an EU-style AI statute. The Federal Department of Justice and Police is preparing a consultation draft by the end of 2026. In parallel, the State Secretariat for International Finance is reviewing financial-market regulation for gaps and obstacles to AI applications; publication had been announced for the second quarter of 2026. FINMA has operated a dedicated “AI Desk” since 2022. (SIF)

Anyone building AI architecture today is therefore building into a framework that will become more concrete over the next two years but is already stable in its underlying logic: technology-neutral, proportionate and risk-based.

Where implementation fails in practice

FINMA describes weaknesses unusually directly in Guidance 08/2024. Four stand out as substantive.

The focus is privacy rather than model risk. FINMA observed that supervised institutions concentrated primarily on data-protection risks and less on model risks such as insufficient robustness and correctness, bias, instability and explainability. (FINMA Guidance 08/2024) That aligns with the EY Banking Barometer 2026: among challenges in customer and investment use cases, 63 percent cite privacy and security while 48 percent cite concerns about correctness and accuracy. (EY Banking Barometer 2026 via Netzwoche)

That focus is understandable because privacy has established departments and processes. Model risk often does not, at least outside market-risk functions where model validation has been standard for decades. Handing an LLM project to the data-protection officer and treating the job as finished addresses precisely the risks FINMA names least well.

Inventory completeness is the real problem. FINMA notes that completeness is difficult because AI development and use are widely distributed across organisations and generative-AI tools are broadly accessible. Institutions also had difficulty determining whether purchased applications contained AI at all. (FINMA Guidance 08/2024)

This is the most uncomfortable observation in the document because it cannot be fixed with a policy. An inventory based on voluntary self-declaration is structurally incomplete in an organisation with decentralised development. Purchased software is harder still because almost every SaaS vendor now embeds a model somewhere, often without describing that cleanly in the contract.

Data quality beats model choice. FINMA states this explicitly: data quality is often more important than the selection of a particular model. (FINMA Guidance 08/2024) A Dun & Bradstreet study of specialists and executives across five markets reports that 61 percent of banking AI projects fail because of inadequate data foundations; 56 percent of banks have only limited trust in their own data, and only 35 percent say they can make decisions on that basis. (Dun & Bradstreet via Netzwoche)

Those numbers deserve the normal caution applied to vendor research: Dun & Bradstreet sells data-quality products. The direction nevertheless matches both FINMA’s supervisory observations and what appears in almost every data project.

Independent review barely exists. FINMA observed an insufficient separation between AI development and independent review in some cases and found that only a few supervised institutions independently reviewed the complete model-development process using appropriately qualified staff. (FINMA Guidance 08/2024)

This is where AI governance meets the skills shortage. Independently reviewing a RAG system requires someone capable of assessing retrieval quality, prompt injection and evaluation design who is not the same person who built the system. A bank with twenty people in IT does not have that person twice.

A further finding is easy to underestimate. The EY Banking Barometer 2026 shows AI use in risk management falling from 27 percent in the previous year to 8 percent. EY attributes this to data-quality and availability problems, regulatory requirements and low tolerance for errors. (EY Banking Barometer 2026 via Netzwoche) Banks are therefore retreating from precisely the area where AI would be most sensitive from a supervisory perspective and concentrating on process automation, cited by 80 percent. That is rational, but it postpones rather than removes the underlying problem.

Technical patterns that help

The following patterns map directly to expectations in Guidance 08/2024. They are not a complete banking platform but building blocks that can be combined at different levels of depth.

Enforce the inventory instead of asking for it

An inventory that exists only in Excel starts ageing on the day it is created. A stronger design centralises access to models and makes inventory registration a prerequisite for access.

Concretely, all model calls pass through an internal gateway. Direct egress to model providers is blocked at the network layer. The gateway accepts only requests carrying a valid application token tied to an inventory entry. No entry means no access. For internally built applications, completeness therefore becomes an infrastructure property rather than a matter of discipline.

The inventory entry can be versioned in the repository using the classification axes from Guidance 08/2024:

# inventory/apps/kb-assistant.yaml
id: kb-assistant
owner: retail-ops
purpose: >
  Beantwortung interner Fragen zu Weisungen und Reglementen.
  Kein Kundenkontakt, keine Entscheidungsunterstützung im Kreditprozess.

wesentlichkeit:
  finanzmarktrechtlich_relevant: false
  betroffene_kunden: 0
  konsequenz_bei_fehler: mittel   # falsche Weisungsauskunft an Mitarbeitende
  reputationsrisiko: niedrig

eintrittswahrscheinlichkeit:
  autonomiegrad: assistiv          # assistiv | teilautonom | autonom
  prozesseinbindung: keine
  personendaten: nein
  modellverkettung: nein
  kalibrierungszyklus: quartalsweise

risikoklasse: mittel               # abgeleitet, siehe classify.py
outsourcing_relevant: true
provider: <anbieter>
modellversion: <modell-id>@2026-05
datenresidenz: CH
fallback: verweis_auf_fachstelle
eval_suite: evals/kb-assistant/
letzte_unabhaengige_pruefung: 2026-04-18

The risk class should not be set manually; it should be derived from the two axes. Otherwise applications have a tendency to drift downward over time. A small CI step that recalculates the class and fails on a mismatch prevents exactly the kind of inconsistent criteria FINMA criticises.

None of that solves purchased software. Procurement still has to ask about AI use, preferably in a form that cannot honestly be answered with a simple “no”. Instead of “Does your product contain AI?”, a more useful question is: “List every third-party model to which your product sends data belonging to our users, including provider, model version and processing location.” That is verifiable and can be tied contractually to a notification obligation when something changes.

A gateway as the control point

A gateway is where several Guidance 08/2024 expectations can be implemented once instead of independently by every team:

  • Traceability: Persist prompt, context, model version, parameters and response, linked by correlation ID to the business transaction. That is the basis for reconstructing any later decision.
  • Data classification: Check before transmission whether the payload fits the application’s declared data class.
  • Model versioning: Provider-side model changes are change events for risk management. A system using a moving alias is not reproducible.
  • Cost transparency and rate limits per application, which in practice is often the first reason the gateway gets built at all.

The effort is not trivial, but it is paid once. Having every team build its own logging and classification creates exactly the fragmentation FINMA describes as decentralised development and distributed responsibilities.

One frequently missed detail is retention. Complete prompts can contain personal data that should not remain in logs for seven years. A workable compromise is to retain metadata and hashes for longer periods while deleting clear-text payloads quickly, unless a particular application has an explicit retention requirement.

Anonymisation before the model call

Migros Bank has publicly described a pattern that I consider the cleanest documented approach among Swiss retail banks at the moment. Customer requests pass through several stages: analysis and anonymisation of the input, search in an internal knowledge base, answer generation and fact checking. Identifying customer information is replaced with placeholders before the request reaches the Swiss cloud and is reinserted on premises afterwards. (IFZ Retail Banking Blog)

The decisive property is the location of the mapping rule. It remains inside the bank, matching the Swiss Bankers Association cloud-guide expectation that this mapping stay under the bank’s control in Switzerland. (SBA cloud guide)

The limitations need to be explicit. Entity recognition is imperfect and performs worse on free-form customer text than on structured fields. Anonymisation also does not prevent re-identification from context. An inquiry containing a transaction amount, date and branch may be unique without a name. The pattern reduces risk; it does not eliminate it, and the documentation should say exactly that.

Evaluation as a gate, not a report

FINMA expects predefined performance indicators, thresholds or other validation methods and testing for accuracy, robustness, stability and, where relevant, bias. In a footnote it explicitly names backtesting, out-of-sample testing, sensitivity analysis, stress testing, adversarial testing with false inputs and benchmarking against simpler models. (FINMA Guidance 08/2024)

That is effectively a specification for an evaluation suite. Running it in CI is the difference between “we tested” and “we test”.

# evals/kb_assistant/test_regression.py
import pytest, yaml
from app.pipeline import answer

GOLDEN = yaml.safe_load(open("evals/kb_assistant/golden.yaml"))
THRESHOLDS = {"exact_ref": 0.95, "no_answer_recall": 0.98, "hallucination": 0.02}

@pytest.mark.parametrize("case", GOLDEN["cases"], ids=lambda c: c["id"])
def test_case(case, results):
    out = answer(case["question"], seed=0)
    results.record(
        case_id=case["id"],
        # Wird die korrekte Weisung als Quelle zitiert?
        exact_ref=case["expected_ref"] in out.citations,
        # Wird bei Fragen ausserhalb des Scope korrekt abgelehnt?
        refused=out.refused,
        # Enthält die Antwort Aussagen ohne Beleg im Kontext?
        unsupported=count_unsupported_claims(out.text, out.context),
    )

def test_thresholds(results):
    m = results.aggregate()
    assert m["exact_ref"] >= THRESHOLDS["exact_ref"]
    assert m["no_answer_recall"] >= THRESHOLDS["no_answer_recall"]
    assert m["hallucination"] <= THRESHOLDS["hallucination"]

Three points matter more than the code itself.

First, the golden set has to come from domain specialists rather than the development team. FINMA frames this as an expectation that specialists in the relevant application domain contribute questions and predefined expectations. (FINMA Guidance 08/2024) A team writing its own test cases tests against its own mental model of the system.

Second, refusal behaviour needs to be tested just as carefully as answer quality. Migros Bank decided that its assistant should answer only questions about the bank and its services and not provide advice in the narrower sense. When asked for the optimal account, it refers the customer to an adviser. (IFZ Retail Banking Blog) That boundary is a control only when it is measurable.

Third, reproducibility in LLM pipelines is difficult and should not be defined away. A fixed seed and temperature zero help but do not guarantee bit-identical output from hosted models. Provider-side batching and infrastructure changes are enough to create differences. What has to be reproducible is not the exact text but the state: prompt version, context documents with hashes, model version and parameters. That makes a past answer explainable even when it cannot be regenerated identically. In my view, that is the realistic interpretation of the expectation that results can be traced, explained or reproduced.

A pragmatic interpretation of explainability

Guidance 08/2024 expects institutions to be able to assess plausibility and robustness of results and understand the drivers of applications or their behaviour under different conditions. (FINMA Guidance 08/2024) That is a less demanding standard than mechanistic interpretability, appropriately so: the latter simply cannot be supplied for a model with hundreds of billions of parameters.

What can be supplied is:

  • Source grounding. Every claim can be traced to a document. UBS’s internal assistant “Red” shows the source in the tool with a link to the original document. (IFZ Retail Banking Blog) That is not explainability in the XAI sense, but it makes the answer verifiable by the user, which is the actual purpose.
  • Behaviour documentation through tests. An evaluation suite that covers edge cases, missing information and conflicting sources says more about behaviour than an attribution heat map.
  • Ablations. Measure what changes when one document is removed from the context. This is inexpensive and directly tests the drivers of a concrete answer.

Classical models such as scoring, segmentation and transaction monitoring are different. SHAP values, partial-dependence plots and benchmarking against a simple interpretable reference model remain standard there, and FINMA explicitly names benchmarking against simpler models. It is useful to keep these two worlds separate in documentation rather than force one universal definition of explainability across both.

Drift and override rate as early warning signals

One detail in Guidance 08/2024 receives little attention even though it is one of the cheapest signals available: monitoring should include analysis of cases where users ignore or modify the model’s output because manual corrections can reveal weaknesses. (FINMA Guidance 08/2024)

Every human-in-the-loop system already produces an override rate; it only needs to be captured. For an email assistant such as the one Migros Bank integrates directly into Outlook, the amount of editing before sending is a direct quality metric. (IFZ Retail Banking Blog) A rising override rate within one topic cluster can indicate a knowledge gap or a rule change not yet reflected in the system. That is useful monitoring without additional modelling.

Input drift is the second component and is also explicitly expected. In LLM systems, the relevant drift is often not feature distribution but the mix of query topics and freshness of the knowledge base. Migros Bank systematically treats poorly rated answers as evidence of knowledge gaps and closes those gaps. (IFZ Retail Banking Blog) That is a closed feedback loop and considerably more useful than a quarterly report.

Deployment: the real trade-off

Four options are realistic, and none is universally better.

Hyperscalers with EU or US processing. Best model quality, lowest operational burden, highest third-party dependency. FINMA explicitly identifies increasing reliance on providers of hardware, models and cloud services in an increasingly concentrated market as a risk (FINMA Guidance 08/2024); the 2025 Risk Monitor reinforces this with the finding that almost half of reported cyber incidents involved third parties (FINMA Risk Monitor 2025).

Swiss hosting through a provider with model access. This is the middle path chosen by several institutions. UBS hosts the externally sourced information area of its assistant in Switzerland and blocks employee access to public ChatGPT. (IFZ Retail Banking Blog) Migros Bank uses LLMs in a Swiss cloud combined with upstream anonymisation. (IFZ Retail Banking Blog) Data residency is addressed, while model dependency remains.

Own infrastructure. Swissquote says it is building sovereign AI infrastructure, investing roughly CHF 30 million through 2028 and already using a data centre rated at 140 petaflops. CEO Marc Bürki frames the investment as a way to retain control over core technology and reduce dependence on external platforms. (Netzwoche) That scale is unrealistic for most institutions.

Open models on own infrastructure. Apertus, the fully open Swiss LLM developed through the Swiss AI Initiative, is the most interesting option where data must remain inside Swiss jurisdiction; version 1.5 had been announced for summer 2026. (Swisscom on the Swiss AI Initiative) The limitation should not be minimised. For tasks at the frontier of current model capability, the performance gap is real. For well-scoped tasks with strong retrieval, such as policy lookup, classification or extraction, it is often irrelevant.

My view is that deployment is often discussed too early. A better sequence is to separate data classes first and choose deployment per class. An assistant over public product information and one with access to customer files are different systems with different requirements even if they share the same UI.

Agents: the next stage

Guidance 08/2024 names degree of autonomy and process integration, together with chaining of multiple models, as factors affecting probability of occurrence. (FINMA Guidance 08/2024) That is exactly where current development is heading.

In May 2026, Sygnum said it had become the first Swiss bank to test an AI agent for live digital-asset transactions. The agent turns text instructions into multistep blockchain transactions, plans the steps, checks smart contracts and points out transaction risks before presenting the transaction to the customer for approval. The customer signs through his self-custody wallet on his own device. The architecture uses the Model Context Protocol, with Claude used in the test. The agent is not yet available to customers and any deployment remains subject to comprehensive regulatory review. (Netzwoche)

The pattern generalises beyond digital assets. The agent plans and explains, the human authorises, and the critical credential, here the private key, never leaves the control of the authorised party. That separation should be treated as an architectural principle rather than a temporary compromise to optimise away later. The authorisation boundary is where responsibility can be assigned, and assignment of responsibility is exactly what FINMA identifies as difficult when systems act autonomously and opaquely.

Where Swiss banks actually stand

The data is better than for most technology topics because three independent surveys are available.

FINMA’s early-2025 survey found roughly 50 percent of institutions already using AI or developing it. (FINMA survey) The EY Banking Barometer 2026, based on 100 banks in Switzerland and Liechtenstein surveyed in late 2025, reports 78 percent working on implementation of AI projects, up from 53 percent the year before. Cantonal banks lead at 87 percent, regional banks are at 75 percent. The study authors heard that AI was not a topic only from some private banks. (EY Banking Barometer 2026 via Netzwoche)

The HSLU IFZ Bank IT and Sourcing 2026 study, based on executives from 43 retail banks, gives a more differentiated ranking. For the first time, around half assign high importance to AI, putting it fourth behind cybersecurity at 95 percent, process automation at 74 percent and digital support for advisers at 65 percent. The authors note that AI is already implicit in those three areas. Some 51 percent outsource AI capabilities; larger institutions in particular build internal expertise, while use in payments and anti-money-laundering is often outsourced. (HSLU study via Netzwoche)

The differing percentages are not contradictory because they measure different things: “uses AI”, “is implementing AI” and “assigns high importance”. The direction is the same in all three surveys.

Evidence for individual institutions varies widely. Publicly documented examples include the following.

UBS announced around 50,000 Microsoft Copilot licences in its Q3 2024 results and introduced the AI assistant “Red”. Red is based on Microsoft’s platform, adapted specifically for UBS use cases, and by the end of 2024 was intended for roughly 20,000 employees in Switzerland, Hong Kong and Singapore, with rollout completing by March 2025. The area containing external information is hosted in Switzerland, public ChatGPT access is blocked, sources link to original documents, and the system includes a feedback loop and defined guardrails. (IFZ Retail Banking Blog)

Zürcher Kantonalbank has used “ZKB ChatGPT” since October 2024 following a two-month test phase. Employees have access to a dedicated version with internal data. The most common use cases are research, drafting and summarisation. (Microsoft Switzerland News Center)

Migros Bank is the most customer-facing of the documented examples. According to the IFZ blog, its digital assistant based on ParetoLabs handles more than 15,000 requests per month. It also operates a Secure AI Chat and an email assistant for employees. The customer assistant works autonomously; the email assistant uses a human-in-the-loop model where the employee retains editorial responsibility. Agentic workflows are planned as a next step. (IFZ Retail Banking Blog)

Swissquote is pursuing the infrastructure investment described above, with a focus on fraud detection and digital assistants. The personal assistant “Yuhlia” is being tested inside the Yuh platform app. CEO Marc Bürki has also stated that some applications are already programmed entirely by AI systems. (Netzwoche)

Sygnum conducted the agent test described above. (Netzwoche)

Valiant has, according to IFZ, used AI in crisis-management exercises to create a structured situation overview quickly. Several banks use the Hypodossier SaaS product in mortgage processes for document classification and data extraction, including indicators of inconsistencies. (IFZ Retail Banking Blog)

For Julius Baer, reports around its restructuring programme mention expected AI contributions to savings, but I found no robust public details about specific architecture or governance. The same is true of Vontobel, Pictet and most other private banks: rankings on digital maturity exist, but not verifiable descriptions of how AI applications are technically designed and controlled. That gap should remain a gap rather than being filled by analogy.

Across the documented cases, the pattern is clear and matches the IFZ finding: the large majority of applications support employees in supporting processes. AI remains uncommon in the core processes of financing, saving, pensions, investing and payments. (IFZ Retail Banking Blog) Migros Bank’s customer-facing system and Sygnum’s transaction agent are exceptions rather than the norm.

Assessment

Three points matter most to me. They are my conclusions rather than quotations from the sources.

The compliance problem is mostly an engineering problem. Almost every expectation in Guidance 08/2024 maps to a technical property: inventory completeness to egress control, traceability to logging and versioning, test requirements to a CI-integrated evaluation suite, data quality to validated pipelines. Build those properties and much of the documentation appears as a by-product. Do not build them and the organisation ends up writing documents about a state it cannot measure. The second path is cheaper in the short term and difficult to defend during an on-site review.

The underestimated problem is breadth rather than depth. Most institutions I see around me have respectable documentation for their flagship AI application. The larger risk sits in twenty small automations nobody registered as AI and in purchased tools that quietly acquired a model. If I had to prioritise one measure, it would be technically consolidating model access, not because of cost but because it makes the question “What is actually running here?” answerable.

Explainability is overrated while reproducibility is underrated. Discussion often centres on whether an LLM can be explained. FINMA’s actual expectation is narrower and more practical: institutions need to assess plausibility and robustness. Source grounding, test coverage and ablation can support that. The harder and less discussed problem is preserving enough state to reconstruct an answer two years later in a legal dispute. Model versions are retired, prompts change and knowledge bases are updated. If that state is not versioned from the beginning, nobody can later explain why the system answered the way it did at the time. That is exactly the question a dispute is likely to ask.

The regulatory framework will become more concrete through the end of 2027, including the Federal Department of Justice and Police consultation, the SIF work and shifted EU deadlines. The underlying logic is unlikely to change much. Institutions that build clean inventories, gateways, evaluations and versioning now will already satisfy a large share of what comes next. Waiting for a rule to spell out every step creates systems whose past behaviour cannot be proven afterwards.

Sources

Regulation and supervision

Legal context

Studies and market data

Bank-specific cases

Related reading