Open-source AI arrives in a bank by many doors. A data scientist downloads open weights to fine-tune a classifier. An engineering team adopts an agent framework. A business unit installs an MCP server to connect an assistant to market data. Each is reasonable on its own. Together they create a portfolio of third-party AI components that most banks’ software intake processes were not designed to see, let alone assess.
The good news is that the questions are well understood and the tools to answer them exist — many of them open source too. The challenge is to extend existing software governance to cover three things that are new with AI: licences on models and data as well as code, provenance of artefacts that cannot be read like source code, and regulatory obligations that attach to models and their providers.
Licence risk: code, weights and data are licensed separately
Traditional open-source compliance asks whether a package’s licence is OSI-approved and compatible with how the bank will use it. AI adds layers. FinGPT is a good illustration: its repository is MIT-licensed, but its published sentiment models are LoRA fine-tunes of Llama 2 and ChatGLM2 base models9, which carry their own terms. Llama’s community licences are not OSI licences; the Llama 3.1 licence, for instance, requires any licensee whose products had more than 700 million monthly active users on the release date to request a separate licence from Meta, which Meta may grant at its sole discretion7.
The Open Source Initiative’s Open Source AI Definition 1.0 sets a higher bar still: to qualify, a system must make available its code and parameters under OSI-approved terms and sufficiently detailed information about its training data for a skilled person to build a substantially equivalent system8. Few popular models meet it. And metadata cannot be taken on trust: GitHub’s API reports no recognisable licence for OpenBB, while the repository’s LICENSE file states that all files are licensed under Apache 2.010. Licence review has to read the files, the model cards and the base-model chain.
Supply-chain security: provenance before performance
Model files, prompts, agent skills and MCP servers are executable in effect, even when they are not code in form. A connector with access to a bank’s data and credentials deserves the scrutiny of any privileged integration. MCP adoption makes this pressing: the reference servers repository alone has 90,771 stars19.
OpenSSF Scorecard is the most widely used automated signal of open-source project hygiene. It scores projects from 0 to 10 on checks such as code review, pinned dependencies, signed releases and maintenance, and runs a weekly scan of the one million most critical open-source projects11. We queried its public API on 1 October 2026 for 18 widely used finance-AI repositories — including TradingAgents, OpenBB, ai-hedge-fund, anthropics/financial-services, FinGPT, FinRobot, FINOS Legend, FINOS AI Governance Framework, FINOS CDM, MCP reference servers, LangGraph, CrewAI, two bank-published repositories, financial-datasets/mcp-server, IBM AMLSim and NVIDIA garak — and found a published result for only one, Microsoft’s AutoGen12. Exhibit 1 shows that result alongside the general-purpose AI libraries that do appear.
Security hygiene data exists for core AI libraries, not for most finance-AI projects
OpenSSF Scorecard results (0–10) from the public API, queried 1 October 2026
| Repository | Aggregate score | Maintained | Code review | Pinned dependencies | Result date |
|---|---|---|---|---|---|
| openai/openai-python | 7.9 | 10 | 10 | 9 | 2026-09-28 |
| huggingface/transformers | 6.5 | 10 | 9 | 3 | 2026-09-28 |
| pytorch/pytorch | 6.4 | 10 | 10 | n/a | 2022-10-26 |
| langchain-ai/langchain | 5.8 | 10 | 2 | 8 | 2026-09-28 |
| microsoft/autogen | 5.6 | 0 | 6 | 0 | 2026-09-28 |
| 17 other finance-AI repositories checked | No published result | – | – | – | – |
Note: A missing result means the project is not in Scorecard’s public dataset, not that it is insecure; Scorecard can be run on any public repository. The pytorch/pytorch result is stale (2022).
Two lessons follow. First, absence of evidence is the norm, so banks must run Scorecard (or equivalent) themselves at intake and on a schedule. Second, the checks catch real signals: AutoGen scores 0 on ‘Maintained’12, consistent with its README notice that it is now in maintenance mode and will receive no new features16. Lifecycle risk is live elsewhere too — Protect AI’s LLM Guard, a popular LLM security toolkit, is now archived and no longer maintained17.
Provenance tooling for AI artefacts is maturing. CycloneDX’s ML-BOM records models, datasets and their provenance alongside software components13, and Sigstore’s model-transparency project provides signing and verification for ML models14. Red-teaming tools such as NVIDIA’s garak, an LLM vulnerability scanner with 9,394 stars, can be built into pre-production testing18.
What regulators expect
In the EU, obligations for providers of general-purpose AI models have applied since 2 August 2025 and were not moved by the Digital Omnibus2. The Omnibus, published as Regulation (EU) 2026/1744 and in force since 27 July 2026, defers high-risk obligations for Annex III systems — which include creditworthiness assessment — to 2 December 20273. Open-source status helps only at the margin: Article 53(2) exempts providers of models released under a free and open-source licence with public weights from some documentation duties, but not those of models with systemic risk1. A bank that fine-tunes and deploys an open model is still accountable for how it uses it.
DORA, applicable since 17 January 2025, requires financial entities to manage ICT third-party risk across all ICT services, and to keep a register of information on those arrangements4. On 18 November 2025 the ESAs published their first list of critical ICT third-party providers, 19 in total, for direct EU oversight56. That oversight does not transfer the bank’s own responsibility for assessing its providers6 — and open-source components, which often have no contractual provider at all, need an owner inside the bank.
The regulatory clock for open-source AI in EU banks
Key dates and what they mean for adopting open models and agent components
| Date | Requirement | Relevance to open-source AI | Source |
|---|---|---|---|
| 17 Jan 2025 | DORA applies | ICT third-party risk management and register of information cover AI services and components | 4 |
| 2 Aug 2025 | EU AI Act GPAI provider obligations apply | Open-licence exemption is partial and excludes systemic-risk models | 21 |
| 18 Nov 2025 | First 19 critical ICT third-party providers designated | Direct oversight of major providers; banks keep responsibility for their own assessments | 56 |
| 27 Jul 2026 | Digital Omnibus on AI (Reg. 2026/1744) in force | Amends AI Act timelines | 3 |
| 2 Dec 2027 | High-risk obligations for Annex III systems | Covers uses such as creditworthiness assessment built on open models | 3 |
Note: EU-focused; banks outside the EU should map equivalent model risk and third-party guidance.
A practical intake checklist
The FINOS AI Governance Framework, developed by practitioners from across the industry, catalogues 23 AI risks — 11 operational, 9 security and 3 regulatory — with preventative and detective mitigations mapped to the EU AI Act, NIST, OWASP and ISO 4200115. It is a sound spine for an intake process. We would add seven gates specific to open-source components:
- Licence chain: code, weights, base model, training data and outputs, read from the files and model cards rather than platform metadata107.
- Project health: Scorecard results, last push, maintainer identity, maintenance or archive notices111617.
- Provenance: signed artefacts where available and an ML-BOM entry for every model and dataset1413.
- Connector privileges: least-privilege credentials and network egress controls for each MCP server or tool.
- Adversarial testing: prompt-injection and data-leakage testing before production18.
- Regulatory classification: AI Act role and risk tier, plus DORA register entry14.
- Named owner and exit plan: who patches, monitors and, if needed, replaces the component.