Skip to main content

US Financial AI: SEC, FINRA, and OCC Compliance Requirements

US financial institutions do not need to wait for a single federal AI statute before they govern model usage seriously. The real pressure already comes from existing supervisory duties. Broker-dealers still have books-and-records obligations under SEC Rules 17a-3 and 17a-4. Investment advisers still have recordkeeping duties under Advisers Act Rule 204-2. Financial firms still have to protect customer information under Regulation S-P, supervise communications and business activity under FINRA Rules 3110, 2210, and 4511, and manage bank risk in line with OCC expectations on model governance and third-party oversight. AI changes the execution path, not the fact that those duties exist.

That is why runtime governance matters. The hard question is rarely whether a policy exists on paper. It is whether a real prompt, carrying real account data or research context, can be shown to have gone through an approved route with the right controls active at the moment of use. Keeptrusts is useful here because it gives compliance, risk, and platform teams a shared control boundary. It can narrow the provider set, reduce sensitive data before the model call, block obvious MNPI phrases, escalate high-risk outputs, and preserve decision evidence through events and exports. It does not replace supervisory judgment, legal review, or retention policy, but it makes those functions much easier to defend.

Use this page when​

  • You run AI-assisted workflows in a broker-dealer, registered investment adviser, bank, lender, payments company, or regulated fintech.
  • You need to connect SEC, FINRA, and OCC obligations to practical runtime controls.
  • You want a way to govern provider selection, sensitive-data handling, and review stops without overstating what an AI gateway alone can prove.

Primary audience​

  • Primary: compliance officers, risk managers, platform engineers
  • Secondary: supervisory principals, internal audit, security architects

The problem​

Financial AI programs usually fail at the boundary between a promising use case and a regulated workflow. A research assistant meant for internal summarization starts drafting language that looks like a recommendation. A support assistant touches customer account details and complaint history. A portfolio-analysis helper sees internal investment committee notes. A banking operations copilot receives information that is not public, is customer-linked, or could influence a high-consequence decision. Each scenario triggers different obligations, but the route itself often stays opaque.

That opacity creates three familiar supervisory problems.

First, firms lose control of communications risk. If the model is allowed to produce direct recommendation language or overly certain investment statements, a team can drift into conduct and advertising trouble before anybody notices. Second, they lose control of data exposure. Customer identifiers, account details, or internal research material can move to a provider path that has not been explicitly approved for that workload. Third, they lose control of evidence. Even if the firm says there is human review, reviewers and examiners still need to see what was configured, what happened, and how the organization responded when policy fired.

US regulators do not need a finance-specific AI law to care about those failures. SEC and FINRA are already concerned with supervision, communications, disclosures, and records. OCC expectations already force banks to manage model risk, vendor risk, and operational control. The gap is not awareness. The gap is execution discipline at runtime.

The solution​

The most defensible pattern is to split financial AI into a small number of lanes instead of treating every request as generic productivity traffic. Internal research support, customer-facing assistance, trading-adjacent analysis, and bank operations should not all share the same provider path and output policy.

Keeptrusts helps because the control chain can be tied to those lanes. prompt-injection protects the request boundary before upstream calls. pii-detector reduces obvious personal or account-linked content. data-routing-policy enforces the provider posture the firm has actually approved, including zero-retention or training-opt-out requirements where needed. mnpi-filter blocks obvious material non-public information signals in output. financial-compliance is a lightweight output control that can block phrases such as direct buy or sell language and prepend disclaimers when output looks like advice. human-oversight creates an explicit escalation stop for routes that should support an analyst or representative rather than act on their behalf.

The important discipline is not to overclaim. Keeptrusts does not make a broker-dealer automatically compliant with SEC and FINRA rules, and it does not replace a bank's broader model-risk management program. What it does provide is a concrete runtime boundary that those other programs can inspect. That is exactly what most AI governance programs lack.

Implementation​

Treat implementation as a repeatable supervisory loop, not a one-time configuration exercise.

kt policy lint --file policy-config.yaml
kt policy test --json
kt gateway run --listen 0.0.0.0:41002 --policy-config policy-config.yaml
kt events tail --since 24h --json
kt export-jobs create --since 30d --format json --wait

Use that loop after each material control change. Validate that the config parses, run scenario tests for finance-specific prompts, observe live decisions, and then generate an evidence package for review. For higher-risk routes, keep the lane intentionally narrow: approved providers only, explicit data-policy metadata, and escalation on outputs that could influence a customer communication, analyst judgment, or internal recommendation flow.

In practice, that means you should not rely on financial-compliance alone. Pair it with Data Routing Policy when provider posture is part of the control story, with MNPI Filter when internal disclosure risk matters, and with Human Oversight when a person must remain accountable for delivery. The most useful supporting pages are Financial Compliance, Protect Financial Data, and Tutorial: Export Compliance Evidence.

Results and impact​

When firms move to this lane-based model, the first improvement is clarity. Supervisors, risk teams, and engineers can all see which routes are allowed to do what. They can point to the provider restrictions, the sensitive-data controls, and the escalation decision instead of arguing from general principles.

The second improvement is better examination readiness. Decision events and export workflows give teams a faster way to explain what happened during a review window. Instead of pulling fragments from several systems, they can start from the governed route and expand outward to the broader compliance story.

The third improvement is safer scale. Many financial AI issues emerge after the pilot, when a helpful internal workflow gets reused in a customer, advisory, or credit context. A governed route makes those expansions visible instead of accidental.

Key takeaways​

  • US financial AI governance is already shaped by existing SEC, FINRA, and OCC obligations even without a single AI statute.
  • Separate regulated financial workflows into explicit lanes instead of sharing one generic model route.
  • data-routing-policy, mnpi-filter, financial-compliance, and human-oversight are useful together because they answer different supervisory questions.
  • Keeptrusts strengthens runtime control and evidence collection, but it does not replace legal review, supervision, or record-retention policy.
  • Examination readiness improves when control teams can inspect one governed route instead of reconstructing AI usage after the fact.

Next steps​