Financial Services AI Agents: Audit Trails That Pass SOC 2 and FINRA

Financial services AI deployments come with three control regimes that interact: SOC 2 (security and availability), FINRA (broker-dealer communications, books-and-records), and increasingly the SEC’s AI-specific guidance. Plus GDPR if you operate in Europe and MiFID II if you operate in the UK or EU markets.

The good news is that the controls these regimes ask for are largely the same controls — audit trail, access management, retention, incident response. The bad news is that you have to demonstrate them to multiple bodies under different formats.

This is a practical guide.

What’s actually required

The high-impact controls for AI agents in financial services:

SOC 2 Trust Services Criteria (especially CC6, CC7, CC8):

• Logical access controls with role separation
• Change management with audit
• Monitoring and detection of anomalous activity
• Incident response with documented timelines

FINRA Rule 4511 (books and records) and Rule 3110 (supervision):

• Retention of communications with customers
• Supervisory review of communications
• Documented review procedures

FINRA Rule 3210 / NASD 3010:

• Restrictions on outside business activity, including AI-generated communications that might constitute advice

SEC marketing rule (Rule 206(4)-1) for RIAs:

• AI-generated client communications can be advertisements; same disclosure / fair-and-balanced rules apply

MNPI controls:

• Material non-public information must not flow into models or systems that could leak it

The agent control surface

Map those to what an agent system has to provide:

1. Per-user, per-role access controls with enforcement at the runtime, not just the UI
2. Append-only audit log with retention longer than your longest applicable window
3. MNPI tagging that prevents specific memory writes from being visible to specific scopes
4. Plan Mode for any communication that constitutes advice or solicitation
5. Supervisory review queue with approval / rejection tied to a named principal
6. Model version pinning with a documented change procedure

ONTO’s primitives map cleanly:

# Tagged memory write — MNPI.
onto.memory.add_assertion(
    subject="client_4421",
    predicate="position_request",
    object="long XYZ Corp",
    tags=["mnpi"],
    consent_scopes=["advisor:write"],
)

# A general-access tool refuses to read [mnpi] memory.
@Tool(
    name="generate_marketing_email",
    required_consent=["marketing:write"],
    excluded_tags=["mnpi", "phi", "pii"],   # ← cannot read these.
)
def generate_marketing_email(client_id: str) -> str:
    ...

The excluded_tags is the structural primitive that prevents MNPI from flowing into a marketing context — the same memory store, different access rules, enforced at the runtime.

The Plan Mode case for FINRA

Financial communications to clients are supervisable. Under Rule 3110, a registered principal has to review communications before they go out. A fully autonomous AI agent that sends client emails is a supervision gap.

Plan Mode is the structural answer:

# Advisor proposes a portfolio recommendation.
plan = onto.run_sync(
    "Recommend rebalance for client_4421.",
    user_id="client_4421",
    consent_scopes=["advisor:read", "tasks:write"],
    mode="plan_only",
)

# The plan goes to a supervisor's queue.
supervisor.review(plan)

# After approval, execute with appropriate scopes.
if approved:
    onto.execute_task(
        plan.tasks["send_recommendation_email"],
        consent_scopes=["client:communicate", "audit:write"],
    )

The supervisor’s approval is a row in the audit log linked to the plan_id. Books and records satisfied; supervision satisfied.

The on-prem decision

Several factors push financial firms toward on-prem AI:

• MNPI controls: easier to demonstrate that MNPI didn’t leave the network if there is no external API call.
• Audit complexity: every external vendor adds a sub-processor to your SOC 2 scope.
• Data residency: GDPR data-localization rules; MiFID II conditions.
• Predictable cost: hosted models bill by token; on-prem GPU cost is fixed.

ONTO’s default deployment runs entirely on your infrastructure: local Ollama (or vLLM) + Postgres + pgvector + Helm chart. No external API call required.

Model version pinning

For SOC 2 change management, the version of the LLM you call is configuration that has to be managed. Hosted model providers often update their models silently; this is incompatible with strict change management.

Two paths:

• Pin to a specific hosted model version with vendor commitment to retain it. Anthropic and OpenAI both offer this on enterprise tiers.
• Self-host open-weight models. The version is whatever you deploy.

ONTO supports both — it’s an env var.

The eval discipline

Most financial firms require pre-production testing for any AI change. The right shape:

• An eval set of representative inputs (anonymized, never real client data).
• Expected outputs or properties (e.g., “must not give a buy / sell recommendation without disclaimer”).
• CI gate that fails if regressions exceed threshold.
• Change-approval workflow that ties to the eval results.

ONTO’s eval harness reads TOML/JSON test cases and exits non-zero on failure. Integrate it into your CI; gate releases on it.

What you can’t do (yet)

Even with the right primitives, some patterns remain hard:

• Real-time MNPI screening: detecting in-flight that user input contains MNPI requires careful prompting + post-hoc review. No magic.
• Generative tax advice: most firms forbid this entirely; not an SDK question.
• Cross-border data movement: requires careful network architecture; the SDK can pin storage to a region but you have to enforce the rest.

These are deployment patterns, not code patterns. The SDK supports them; the policy enforces them.

A minimal compliance kit

The artifacts you should be able to produce on demand:

1. Data flow diagram (what data is where, what scopes can touch it)
2. Consent scope matrix (which role has which scopes; signed off by compliance)
3. Audit log retention policy (how long for each tag)
4. Eval set + last run results
5. Model version inventory + change log
6. Incident response runbook with AI-specific scenarios
7. Sub-processor list (every external vendor in the data path)
8. BAA / DPA list (signed agreements with each)

ONTO gives you the technical primitives that the artifacts reference. The artifacts themselves are your work.

The financial-services bottom line

The right way to ship AI in a regulated financial workflow is:

• Default to on-prem with open-weight models.
• Tag memory by regulation class; gate tools by tag.
• Plan Mode every client-facing or trade-affecting communication.
• Pin model versions and gate changes through CI.
• Treat the audit trail as a first-class deliverable, not an afterthought.

If your stack supports these by construction, your compliance burden becomes manageable. If they’re bolt-ons, every audit becomes an engineering project.

---

The features page covers consent scopes and Plan Mode. The thesis post on stateless agents explains why structural separation matters more than conventions.

Frequently asked questions

What's special about financial services AI compared to other regulated industries?

Three things: MNPI (material non-public information) controls, suitability and Reg BI obligations on customer-facing communication, and the SEC's growing AI-specific guidance. The fundamentals — audit trails, access control, on-prem options — are similar to healthcare.

Can a hosted model satisfy SOC 2?

SOC 2 is about your controls, including controls over your sub-processors. A hosted model vendor in SOC 2 scope must be in your sub-processor list with appropriate controls. Many firms find this cleaner with self-hosted open-weight models.

What about regulator-required model explainability?

Plan Mode + typed memory give you 'what data did the model see, what did it propose, and who approved it.' That's not 'why did the neural network produce this token' — but it's the question regulators actually ask.