FINRA vs Reg S-P vs NYDFS Part 500: a control matrix for Copilot Studio agents in financial services

Why a domain-based matrix works better than a regulation-by-regulation reading

Each framework has a different anchor. FINRA centers on supervision: a supervisory system and written supervisory procedures, including for functions performed by third-party vendors. Reg S-P centers on safeguarding customer information, and as amended in May 2024 it requires a program reasonably designed to detect, respond to and recover from unauthorized access to or use of customer information. NYDFS Part 500 centers on a cybersecurity program based on the entity's risk assessment, with access controls, multi-factor authentication and a written policy for third-party service providers.

An agent built in Copilot Studio touches all three at once. It reads from knowledge sources, calls connectors and actions, produces outputs and sometimes hands off to a person. Reading three regulations in sequence tends to produce three parallel control lists for the same behavior. Organizing by control domain gives one set of agent-level controls with each framework's hook noted beside it.

Scope decides which columns apply. A FINRA member, a Reg S-P covered institution (broker-dealers including funding portals, investment companies, registered investment advisers and transfer agents) and a Part 500 covered entity, including one with a section 500.19(a) limited exemption, each carry a different mix. As of November 2026, both Reg S-P compliance dates have passed: December 3, 2025 for larger entities and June 3, 2026 for smaller entities.

One caution applies to every row below. The regulatory basis is what the rules say. The agent-level mapping is interpretation. FINRA Regulatory Notice 24-09 (June 2024) reminds members that their obligations apply when they use generative AI, but the rules were not written around agent runtime behavior, so the firm should document its reasoning.

Control matrix by domain

Each row separates the regulatory basis from the agent-level control. The control descriptions are the firm's interpretation, not regulator statements.

• 1. Data access and customer information protection: Basis: FINRA reviews access management and data loss prevention. Reg S-P requires safeguarding policies with a program to detect and respond to unauthorized access to or use of customer information. Part 500 requires access controls, identity management and multi-factor authentication for individuals accessing covered information systems, subject to the limited exemption. Agent control: scope each agent's knowledge sources to the minimum, redact sensitive fields in outputs, block out-of-scope retrieval. Applying identity and access rules to agent identities and service accounts is interpretation. Runtime enforceable: largely yes.
• 2. Agent actions and tool use: Basis: no rule addresses tool calls directly. Reg S-P safeguards and Part 500 access controls apply by extension. Agent control: an explicit allow list of connectors and actions per agent, with blocking and rate limiting for calls outside it. Runtime enforceable: yes, at the level of each tool call. The decision about which actions an agent may take at all is an organizational one.
• 3. Human oversight and supervision: Basis: FINRA requires a supervisory system and written supervisory procedures, which cover the Rule 3110 context. Agent control: named owners for each agent, procedures covering agent activity, and escalation for human approval before consequential actions. Runtime enforceable: the approval step, yes. The procedures, ownership and review of outcomes are organizational.
• 4. Third-party and platform oversight: Basis: FINRA expects a supervisory system for vendor-performed functions. Its effective practices include asking whether vendors incorporate generative AI, amending contracts to prohibit customer sensitive information being ingested into a vendor's open-source generative AI tool, and reviewing vendor default settings. Part 500 requires written policies for third-party service providers. Agent control: one shared review of platform settings and contract terms. Runtime enforceable: partly. Contracts and due diligence are organizational.
• 5. Recordkeeping and audit evidence: Basis: FINRA cites SEA Rules 17a-3 and 17a-4 alongside Rule 3110 as potentially implicated, and its vendor practices include checking whether communications are captured for supervisory review. Agent control: retain interaction records, policy decisions, blocked or redacted events and approvals, with retention and residency the firm controls. Which agent outputs count as required records is a firm determination. Runtime enforceable: evidence generation, yes. Classification and retention policy are organizational.
• 6. Incident response: Basis: Reg S-P requires procedures to assess the nature and scope of an incident, contain and control it, and notify affected individuals as soon as practicable and no later than 30 days after the firm becomes aware of actual or reasonably likely unauthorized access or use. FINRA also reviews incident response. Agent control: detection signals and per-interaction records that make scoping possible. Runtime enforceable: signals and containment, yes. The incident program and notification decisions are organizational.

Where the frameworks overlap, diverge or leave interpretation to the firm

The strongest overlap is access and third-party oversight. FINRA's access management reviews, Reg S-P's safeguarding requirement and Part 500's access controls all point to the same question: what can this agent reach, and who approved that? A single scoped-access control with one evidence trail can answer all three. The same holds for vendors. FINRA's vendor supervision expectation and Part 500's third-party service provider policy are better served by one shared control set than by two parallel reviews.

The frameworks diverge in emphasis. FINRA looks at supervision and communications, so the question is whether agent activity is reviewable by a supervisor. Reg S-P is event-driven, so the question is whether the firm can detect, scope and notify within its timeline. Part 500 is program-driven and risk-based, so the question is whether agent controls follow from the firm's own risk assessment.

Interpretation is left to the firm in three places: whether agent identities fall under identity and access rules written for individuals, which agent outputs are records under SEA Rules 17a-3 and 17a-4, and what supervisory review of agent communications must look like. Write the position down, with the rationale, before an examiner asks.

What can be enforced at runtime and what cannot

Runtime enforcement works at the level of an individual interaction or tool call. In that path a policy can allow a request, redact sensitive content from a response, block a call that falls outside the agent's scope, rate limit repeated calls, or escalate an action for human approval. This matters most in domains 1, 2 and 3, because these are the places where an examiner will ask whether a control operated at the moment of the action, not only whether a policy existed.

Runtime enforcement does not discharge organizational duties. It does not write supervisory procedures, assign owners, negotiate vendor contract terms, decide what is a required record or decide when to notify customers. For Reg S-P incidents it supplies detection signals and a record of what the agent accessed, which feeds the firm's assessment of scope and nature. The incident response program and the notification decision still belong to the firm, and a 30-day outer limit makes the quality of that record important.

Platform-native settings, such as the authentication, data policies and transcript options of the agent platform, are a useful baseline. Verify each against the obligations above, as FINRA's effective practice suggests for vendor defaults, and note where they stop short of per-call policy decisions or retention the firm controls.

Evidence an examiner would expect for agent-level controls

Examiners tend to ask for two things: what the agent was permitted to do, and what it did. The first is configuration evidence: the agent inventory, knowledge sources and tools in scope, the policy that governed each, and the named owner. The second is activity evidence: interactions, tool calls made and refused, content redacted, approvals requested and granted, and who approved them.

The two should connect. A record of a blocked tool call is far more useful when it points to the policy version that blocked it. The same records should serve more than one purpose. For FINRA supervisory review they show reviewable agent communications. For Reg S-P they help establish the scope of an incident. For Part 500 they show that access controls were applied under the firm's risk-based program. Retention period and data residency should be settings the firm chooses and can show, because evidence held only in a vendor's default store is harder to produce on request.

This is also a model risk management question. Firms already expect to show that a model-driven process operates within defined limits. Agent-level evidence extends that discipline to tool use and customer data access.

Where Trussed fits

Trussed is one way to cover the runtime rows of this matrix. It enforces policy in the execution path across models, agents, tools and MCP servers, with allow, redact, block, rate limit and escalate for human approval at the level of individual interactions and tool calls. Enforcement produces audit-ready evidence, mapped to frameworks including NYDFS, and deployment is self-managed in the customer cloud with configurable retention and data residency. Trussed has run 18+ months in continuous production in a regulated enterprise.

The limits are worth stating. Trussed is deepest in insurance and does not have financial-services customers or deployments to point to. It does not provide transaction-level governance, model lineage or end-to-end tracing of agentic workflows, and it does not provide regulatory compliance by itself. Supervision, vendor oversight, record classification and incident notification stay with the firm.