Why Fixed-Income Desks Need FINOS AI Governance Now

The argument I keep hearing from senior compliance leaders is that AI governance is too immature a field to commit to a framework. The argument is wrong in both directions.

Immature compared to what — model risk management under SR 11-7? Operational resilience under FFIEC? Those frameworks were also “immature” in their first years. They became universal because the cost of not committing was higher than the cost of adopting an imperfect first version. AI governance is at the same inflection.

And committing to FINOS AIGF v2.0 does not narrow the regulatory surface — it broadens it. Every AIGF mitigation in a working reference implementation carries cross-framework references to NIST AI RMF, NIST 800-53r5, EU AI Act, ISO 42001, SR 11-7, FFIEC, OWASP LLM Top-10 2025, and MAS. One adoption decision; multiple regulatory regimes satisfied.

This article walks through the cross-framework alignment, the things ad-hoc policies miss, and what “AIGF v2.0 coverage” actually buys a fixed-income desk.

What AIGF v2.0 is

The FINOS AI Governance Framework v2.0, shipped in 2025, is a taxonomy of 23 risks and 23 mitigations for agentic AI in financial services. It is framework-agnostic in the sense that it is published as Markdown — not as runnable controls. That is the gap that motivated BondFoundry’s role as the first runnable reference implementation: a fork-friendly artifact where every risk has a mapped mitigation in code, every mitigation has a passing eval case, and every audit row carries a framework_ref.

The risks span five categories:

• AIR-OP — Operational (tier routing, segregation of duties, policy editor controls, coverage gating)
• AIR-SEC — Security (HMAC approval envelopes, MCP allowlists, prompt firewalls)
• AIR-DET — Detection (tamper-evidence, audit chains, anomaly surfaces)
• AIR-RC — Recovery / cross-cutting (replay, evidence packs, role separation)
• Plus agentic-specific mitigations covering A2A communication and tool-call manifests

The taxonomy is closer to the right level of abstraction than most adjacent guidance. It is concrete enough that engineers can map a control to a function; abstract enough that the same control can be implemented in Python, Rust, or Java without forcing technology choices.

Cross-framework alignment

This is the part most evaluators miss. AIGF v2.0 does not exist in isolation. Each mitigation in a serious reference implementation carries explicit cross-references:

AIGF risk	Adjacent framework	Reference
AIR-OP-6 Tier routing	NIST AI RMF	MANAGE-1.3, GOVERN-3.1
AIR-SEC-24 HMAC envelopes	NIST 800-53r5	AC-3(2), AC-3(3), SC-12
AIR-DET-21 Tier-3 audit	SR 11-7	Model risk audit-trail requirements
AIR-OP-14 Coverage gate	EU AI Act	Article 17 (quality-management system)
AIR-OP-18 Segregation of duties	ISO 42001	A.6.4
AIR-RC-22 Recovery / replay	FFIEC IT Examination Handbook	Business Continuity
AIR-SEC-15 Prompt firewall	OWASP LLM Top-10	LLM01 (Prompt injection)
AIR-OP-4 SoD enforcement	MAS Notice on Operational Risk	Para 6

The full mapping ships with BondFoundry’s bondfoundry-finos cross-framework CLI. One AIGF mitigation in code can be cited against five separate regulatory regimes. The auditor in your London office reads it as SR 11-7 (model risk). The auditor in your Frankfurt office reads it as EU AI Act. The auditor in your Singapore office reads it as MAS. Same code. Same audit row.

Adopting a framework is not narrowing your regulatory exposure. It is collapsing five separate audit programs into one verifiable substrate.

What ad-hoc AI policies miss

Most desks that have an AI policy today have a document that says something like: “AI systems used in trading workflows shall have appropriate human oversight, logging, and risk management.” That sentence is a Rorschach test. Five engineers will build five different systems, all of which the policy “endorses,” and none of which would survive an SR 11-7 audit.

Specifically, ad-hoc policies miss:

1. Tier routing. The policy says “human oversight.” It does not specify which actions require oversight, what “oversight” means (review? approval?), or who counts as a valid approver. Result: a flat “approve everything” model that gets fatigue-bypassed, or a flat “trust the agent” model that fails audit.

2. Verbatim rule citation. The policy says “logging.” It does not specify that the log must include the rule that caused a routing decision. Result: logs that say “action_blocked, reason=policy_violation” without telling the auditor which policy clause was violated.

3. Tamper-evidence. The policy says “audit trail.” It does not specify that the trail must be tamper-evident, where immutability is enforced, or how detection works. Result: audit logs that pass the application layer but fail the database layer.

4. SoD at the API. The policy says “segregation of duties.” It does not specify that SoD must be enforced server-side. Result: a UI that hides the self-approval button while the API accepts it directly.

5. Coverage as CI. The policy says “periodic review.” It does not specify continuous coverage monitoring tied to the pull-request graph. Result: governance regressions ship to production between reviews.

6. Materiality aggregation. The policy says “above-materiality trades require approval.” It does not specify session-aggregate materiality. Result: the split-order bypass we discuss in Materiality-Driven Access Control.

A framework like AIGF v2.0 specifies all six. A reference implementation like BondFoundry instantiates them.

What “AIGF coverage” actually buys you

In BondFoundry, AIGF coverage is not a quarterly artifact. It is a CI gate.

Every pull request runs the four-dimension eval harness (accuracy, policy, robustness, latency) and the coverage report:

bondfoundry-finos coverage --threshold 0.85

If coverage drops below 85% or any AIGF v2.0 risk has zero passing eval cases, the build fails. The control is enforced where regressions actually happen — the engineering pull-request graph — not on a quarterly evidence-pack timeline.

For an external auditor, this changes the conversation. Instead of “show me your quarterly coverage report,” the question becomes “show me the CI runs over the last 90 days and the coverage delta per PR.” The data is already there.

The evidence pack

bondfoundry-finos evidence-pack --period 30d produces:

1. Coverage matrix — 23 of 23 AIGF v2.0 risks with passing eval count per dimension
2. Chain verification report — every audit row in the window, sha256-walked
3. Materiality ledger summary — session-aggregate notional vs threshold per portfolio
4. Framework-ref distribution — every framework reference written, with row counts
5. HITL trace — every T2/T3 action with envelope_id, approver(s), dispatch path
6. Cross-framework matrix — AIGF mitigation → NIST / EU AI Act / SR 11-7 / ISO 42001 mappings, with the rows that satisfied each

This is what the auditor wants. Generation runs against the live audit table in under ten minutes for a 30-day window. There is no “let me get back to you.”

Why now (and not next year)

Two things converging in 2026 turn this from “good practice” into “table stakes”:

1. The EU AI Act Article 17 quality-management system requirements are now in force for high-risk AI systems, which includes any agentic AI in capital markets workflows. Article 17 specifies, at minimum, what BondFoundry’s coverage gate already produces.

2. The first wave of SR 11-7 examinations explicitly scoping AI systems is happening. The model risk management bar is no longer “is your model documented?” — it is “is your model’s decision pathway auditable to the same standard as a human decision?”

The cost of catching up to either requirement after you have shipped an AI agent is materially higher than the cost of adopting AIGF v2.0 before. The reason is that the controls (tier routing, audit chain, HMAC envelopes, coverage gate) are foundational. Retrofitting them into an agent that was built without them is roughly as expensive as building the agent again.

Where to start (this quarter)

1. Read the AIGF v2.0 taxonomy. It is short. Two hours.
2. Map your current AI usage to the taxonomy. Where do you have coverage? Where do you have none?
3. Run BondFoundry locally. make demo from the repo, 60 seconds. Read the framework_ref column on the seeded audit rows.
4. Decide on your reference implementation. Either fork BondFoundry and swap the domain, build your own with AIGF as the spec, or vendor it. The first two are months. The third is years and a lock-in.
5. Add the coverage gate to your CI before the policy committee asks for a review.

The desks that adopt AIGF v2.0 in 2026 will spend the audits of 2027 explaining their controls. The desks that don’t will spend them explaining their gaps.

---

BondFoundry is the working reference implementation of FINOS AIGF v2.0. The full source is MIT-licensed on GitHub. Book a walkthrough of the mapping, coverage gate, and evidence pack.