Financial Services AI Governance — What do regulators actually expect vs what teams deliver?

[nagasatish007]

Financial Services AI Governance — Bridging the Gap

Opening this discussion to explore a specific challenge in financial services:
the gap between what regulators expect from AI agent governance and what teams
actually have in place today.

The problem as we see it:

Most teams are stuck in "Post-hoc Governance" — collecting logs after an agent
has finished its task to satisfy an auditor's request for data lineage. But
regulators (SR 11-7, EU AI Act, MAS guidelines) increasingly expect:

• A verifiable connection between the data accessed, the policy version active
  at that moment, and the resulting action
• Proof of which rule was triggered during a specific autonomous decision
• Reproducibility — same input + same policy = same decision, provably

Where TealTiger fits:

TealTiger's approach is deterministic governance — no LLM in the policy path.
Every decision produces a typed, versioned, auditable record. In v1.3, we're
adding TealProof (cryptographic governance receipts) to make these records
tamper-evident and independently verifiable.

Questions for the community:

1. What specific evidence do SR 11-7 examiners ask for when reviewing AI/ML
   model decisions? Does "we have logs" satisfy them, or do they want more?
2. How do teams currently handle the "Lineage vs Logic" problem — proving not
   just what data flowed, but what decision logic was active?
3. Is there appetite for a financial-services-specific policy pack in TealTiger
   (pre-configured controls mapped to SR 11-7 / EU AI Act requirements)?

Looking for perspectives from risk managers, compliance teams, and anyone
building AI agents in regulated environments.

[musaabhasan]

In financial services, "we have logs" is usually not enough if the logs cannot reconstruct the decision conditions.

For an examiner or model-risk reviewer, I would expect evidence across three layers:

1. Decision lineage: input facts, data source versions, policy version, model version, prompt/template version, tool version, and actor identity at decision time.
2. Decision logic: which rule evaluated, which branch fired, which thresholds were used, and why an override or denial happened.
3. Operating evidence: who approved the control, when it was tested, when exceptions expired, and whether monitoring found drift or policy bypass.

The lineage vs logic problem is exactly where deterministic governance helps. A governance receipt should not only say "action allowed". It should include the policy package hash, rule id, evaluated attributes, decision result, timestamp, subject, resource, action, and correlation id to the agent/tool trace.

For a financial-services policy pack, I would keep it implementation-oriented rather than trying to encode every regulation directly. Suggested controls:

• model/change approval before production use,
• high-impact action approval and separation of duties,
• customer-data minimization and purpose binding,
• tool-use allowlist by role and account type,
• explainable denial and override records,
• replayable decision receipts,
• drift and exception monitoring,
• evidence retention and tamper checks.

That gives risk teams a bridge from regulatory expectations to actual engineering artifacts.

[nagasatish007]

This is exactly the kind of structured thinking we want to build against. Thank you for laying it out so clearly.

Your three-layer evidence model (lineage, logic, operating evidence) maps directly to what we're shipping in v1.3:

Decision lineage — Our TEEC (Typed Evidence & Evidence Contract) envelopes already capture input facts, policy version, actor identity, and correlation IDs that link to the full agent/tool trace. In v1.3, TealProof adds cryptographic receipts: policy package hash + rule ID + evaluated attributes + decision result + timestamp + subject + previous hash, forming a Merkle tree that's periodically anchored to an RFC 3161 timestamping service. Third parties can verify a specific decision was included without access to the full tree.

Decision logic — Every Decision object includes: which rule evaluated, the action outcome, reason codes, risk score, and the policy version that produced it. Deterministic evaluation means identical inputs always produce identical outputs — replayable by design.

Operating evidence — v1.3 adds:

TealDrift for behavioral drift detection (statistical baseline comparison)
TealProof for tamper-evident proof chains (chain integrity violation detection)
FREEZE rules that persist across hot-swaps and cannot be overridden by agent output
Separation of duties enforcement (governance teams own policies, developers consume read-only)
Exception lifecycle tracking with mandatory expiry
Your suggested financial services controls are well-aligned with our roadmap:

Your Control TealTiger Implementation
Model/change approval before production CODE_CHANGE action class + two-person rule (v1.3)
High-impact action approval + separation of duties FREEZE + approval_required automation level + anti-tamper controls (v1.3)
Customer-data minimization + purpose binding TealMemory provenance tagging + trust-level propagation (v1.3)
Tool-use allowlist by role and account type TealRegistry + NHI capability scoping per identity (v1.3)
Explainable denial + override records Decision contract with reason codes + audit trail (v1.2+)
Replayable decision receipts TealProof Merkle receipts + deterministic evaluation (v1.3)
Drift and exception monitoring TealDrift + configurable threshold alerts (v1.3)
Evidence retention + tamper checks TealProof chain integrity + RFC 3161 anchoring (v1.3)
On the financial services policy pack specifically — we've scoped regulated packs (PCI-DSS, SOC2, etc.) for v1.4, but your framing of "implementation-oriented controls rather than encoding regulations directly" is exactly right. We'd rather ship controls that produce the evidence regulators need than try to be a compliance checkbox.

If you're interested in shaping what that financial services pack looks like, we'd welcome the input. The control catalog structure is already defined — each control gets a stable ID, maps to a governance dimension, and declares its evidence requirements. Your eight suggested controls could form the foundation.

Happy to share more detail on any of the above, or discuss how the evidence model works in practice.

[musaabhasan]

This is a strong direction. The TealProof layer sounds most useful if verifiers can test both receipt integrity and decision sufficiency.

A few negative cases would make the model easier to trust:

• policy package hash in the receipt no longer matches the policy bundle used for verification
• evaluated attributes are modified while the final decision remains the same
• a Merkle leaf is omitted from the exported proof set
• timestamp is valid but outside the policy freshness window
• subject or correlation ID does not match the underlying agent/tool trace
• verifier has the receipt but not the full trace and must return "integrity verified, context incomplete" rather than over-claiming compliance

That separation matters for regulators: a receipt can be cryptographically valid and still not prove that the decision was appropriate for the operating context.

[nagasatish007]

Spot on. The "integrity verified, context incomplete" distinction is critical — and it's one most governance tools gloss over.

You're right that a receipt can be cryptographically valid and still not prove decision appropriateness. We're designing TealProof with that separation explicit.

On your negative cases — here's how we're thinking about each:

1. Policy hash in receipt doesn't match verification bundle

Verifier returns PROOF_POLICY_MISMATCH — integrity holds, but the verifier cannot confirm the correct policy was active. Requires out-of-band policy registry lookup.

2. Evaluated attributes modified but decision unchanged

Receipt includes attribute hash. If attributes are mutated post-decision, the attribute hash breaks. Verifier returns PROOF_ATTRIBUTE_INTEGRITY_FAILED.

3. Merkle leaf omitted from exported proof set

Verifier detects gaps via leaf sequence numbering. Returns PROOF_COVERAGE_INCOMPLETE — the proof set is valid for what it contains, but cannot claim completeness.

4. Timestamp valid but outside policy freshness window

Receipt includes both decision timestamp and policy bundle timestamp. Verifier flags POLICY_STALENESS_WARNING if the gap exceeds a configurable threshold.

5. Subject/correlation ID doesn't match underlying trace

This is the hardest one. Receipt binds to correlation ID, but verifying the trace itself requires access to the telemetry layer. Verifier returns INTEGRITY_VERIFIED_CONTEXT_UNRESOLVABLE — exactly your "integrity verified, context incomplete" state.

6. Verifier has receipt but not full trace

We're introducing explicit verification levels:

• LEVEL_1_INTEGRITY — receipt cryptographically valid
• LEVEL_2_SUFFICIENCY — receipt + trace + policy confirmed
• LEVEL_3_APPROPRIATENESS — receipt + trace + policy + business context

Verifier declares which level it can attest to. Never over-claims.

The key design principle

TealProof should never over-claim. A verifier that can only confirm integrity should say exactly that — not imply decision appropriateness.

This maps to what regulators actually need: they want to know what level of assurance a given evidence artifact provides, not just "pass/fail."

Your negative cases are going directly into our TealProof acceptance criteria and test suite. Would you be interested in reviewing the verification SDK design as it takes shape? Having someone who thinks in failure modes from the start would be genuinely valuable.