Open-Source vs Vendor SaaS: Building Your Own Governed AI Desk

The argument that “buy-side desks should just use vendor SaaS for AI” rests on a single assumption: that the audit chain, the materiality ledger, and the prompt firewall don’t have to live in the desk’s own tenant.

That assumption is wrong in 2026. Here is why.

The auditor’s question

When an external auditor scopes an AI system at a buy-side desk, the first three questions are predictable:

1. Where does the audit log live?
2. Who has write access to the audit log?
3. Can you produce the audit log on demand, without coordinating with a third party?

For a self-hosted system, the answers are: in our database; our DBAs (with database-layer immutability); yes, immediately.

For a SaaS system, the answers are: in the vendor’s database; the vendor’s operators (with whatever access controls they document); we have to file a request and wait.

The second set of answers can be made acceptable with the right vendor commitments. It is rarely the same conversation as the first.

What “self-hosted” actually means

Self-hosted is not “we run it on a laptop in the back office.” It means:

• The application runs in your VPC (cloud or on-prem)
• The database runs in your VPC; the audit chain rows are your data
• The LLM API call goes from your VPC to the model provider (Anthropic, OpenAI, or self-hosted) under your own contract
• Backups, key rotation, access control, and incident response are your processes
• You can fork the source, modify it, and run the modified version

Self-hosted is a deployment topology, not a level of operational maturity. A self-hosted system can be lazily operated. A SaaS system can be tightly operated. The question is who owns the operational responsibility — and how that maps to audit accountability.

The fork-and-swap pattern

The main objection to building your own AI agent on AIGF v2.0 principles is engineering cost. Six months to build the policy gate, the audit chain, the HITL envelope, the eval harness, the prompt firewall — and you haven’t shipped a single feature.

The fork-and-swap pattern resolves this. BondFoundry is MIT-licensed. You fork it. You strip out the fixed-income domain (QuantLib, curve providers, FIX gateway) and replace it with your own domain — loans, derivatives, structured products, equities, whatever. You inherit the control plane: policy gate, audit chain, HITL envelopes, eval harness, AIGF coverage gate, prompt firewall, MCP allowlist, OIDC sessions, OpenTelemetry tracing, evidence pack CLI.

The control plane is roughly half the system’s code. By forking, you skip that half.

What you keep

When you fork BondFoundry as a control plane:

• The pure-function policy gate with tier routing (T0–T3) and verbatim rule citation
• Postgres-enforced append-only audit log with sha256 row chaining
• HMAC-signed HITL approval envelopes with SoD enforcement at the API
• Four-dimension eval harness with adversarial prompt corpus
• bondfoundry-finos CLI for coverage, evidence pack, cross-framework mapping, chain verification
• Prompt firewall with eight pattern families and four severity modes
• MCP allowlist with manifest pinning
• OIDC session management with JWKS TTL caching
• End-to-end OpenTelemetry tracing
• Age-encrypted backups
• Postgres HA runbook (Patroni)

What you build is the domain — the actual business logic of your trading workflow, your risk model, your portfolio universe. That is where your firm’s expertise sits anyway. The control plane is undifferentiated heavy lifting; the domain is your moat.

The license question

MIT permits you to fork BondFoundry, modify it, and deploy it privately without disclosing your changes. You can run a modified BondFoundry that adds your firm’s proprietary risk models, your venue-specific FIX flows, your internal SSO — and you have no obligation to publish any of it.

We deliberately chose MIT over GPL precisely because buy-side firms cannot redistribute internal trading systems as open-source. The license is permissive so the system is adoptable.

The trade-off is that we (and the FINOS community) cannot pull your improvements back upstream automatically. The mitigation is the community process: if your firm builds a generic improvement (e.g. a new curve provider, an MCP tool that handles structured products), there is an active path to contribute it back without exposing your competitive logic.

The vendor-SaaS counter-argument, taken seriously

There are real reasons to use SaaS for AI agents in finance:

• Speed to first deployment. Vendor SaaS can be live in a week; self-hosted is a quarter, even with a fork.
• Operational burden. Self-hosting means owning the on-call rotation for an AI system.
• Model-update cadence. A vendor SaaS upgrades models centrally; self-hosting means tracking the model provider’s deprecations.
• Commercial responsibility. A vendor SaaS comes with an SLA and a throat to choke. Open-source comes with a community.

All four are real. None of them are decisive. The first three are mitigated by maturity — if your firm runs other production systems, AI is one more. The fourth is the one that matters most: when something goes wrong, who is on the hook?

For a buy-side firm under SR 11-7, the answer is you either way. The vendor SLA does not transfer audit accountability. The vendor’s SOC 2 does not satisfy your model risk framework on its own. The vendor’s incident response is additive to yours, not substitutive.

When the auditor asks “what was the agent’s decision logic on June 1?” — the answer comes from your operational posture, not the vendor’s. Owning the substrate makes that answer easier to give.

Where to start

1. Stand up BondFoundry with make demo on a developer laptop. Read the seeded audit chain.
2. Fork the repo. Swap a single tool — price_bond → your domain’s equivalent. Watch the audit row format stay identical.
3. Run bondfoundry-finos coverage against your fork. See where coverage drops as you add tools.
4. Decide whether the maintenance cost of owning the substrate is lower than the audit cost of not owning it. For most firms with a real compliance posture, the answer is yes.

The substrate is the easy part. The domain is your firm’s actual job. Fork and swap.

---

BondFoundry is MIT-licensed and self-hostable. Full source on GitHub. For the control-plane primitives, see The Four Pillars of Governed AI in Finance.