[Compliance] Review by FINRA/SEC practitioner needed

[shreyas-lyzr]

Summary

We need domain expert review of gitagent compliance schema and audit features by practitioners with FINRA, SEC, or Federal Reserve compliance experience.

Context

gitagent includes first-class compliance support for financial regulations:

• FINRA Rules 3110, 4511, 2210, and Reg Notice 24-09
• Federal Reserve SR 11-7 and SR 23-4
• SEC Reg S-P and CFPB Circular 2022-03

The compliance schema in agent.yaml and the gitagent audit command were designed based on published regulatory guidance, but have not yet been validated by a practicing compliance professional.

What We Need

• Review of spec/schemas/ compliance fields for accuracy
• Validation that audit report output aligns with examination expectations
• Identification of missing requirements or misinterpretations
• Feedback on practical usability for compliance teams

Relevant Files

• spec/SPECIFICATION.md -- full spec
• spec/schemas/agent.schema.json -- JSON schema
• src/commands/audit.ts -- audit command
• examples/full/ -- production compliance example

Who Should Respond

If you work in financial services compliance, risk management, or regulatory technology, your input would be incredibly valuable.

[0xGaziin]

Hi @shreyas-lyzr! I've performed a technical review of the agent-yaml.schema.json and its compliance definitions. Based on the requirements for FINRA/SEC alignment, here are a few observations from a compliance-as-code perspective:
Technical Observations:

Recordkeeping (SEC 17a-4): The immutable: boolean flag is a great addition for WORM (Write Once, Read Many) requirements. However, adding a hash_algorithm field (e.g., SHA-256) to recordkeeping_config would be beneficial for auditors to validate data integrity during examinations.

Supervision (FINRA Rule 3110): While escalation_triggers are well-structured, I suggest adding a mandatory justification_required field. This would ensure that any human-in-the-loop override captures the necessary context for supervisory review.

Model Risk (SR 11-7): Regarding drift_detection, adding a drift_threshold (number) property would allow firms to define automated "kill-switch" alerts before a model's performance degrades beyond compliant levels.

I'm happy to help refine the JSON schema or contribute to the SPECIFICATION.md to clarify these points.

[dahlinomine]

FINRA/SEC Compliance Practitioner Review

I work at the intersection of financial regulation and AI agent infrastructure (ERC-3643/RWA tokenization compliance, Hyperledger contributor). Here’s a practitioner-level assessment of gitagent’s compliance schema.

---

What gitagent gets right

FINRA 3110 (Supervision) — The supervision.human_in_the_loop field is a clean mapping to the supervisory review obligation. FINRA 3110 requires firms to establish procedures for supervising the activities of associated persons. An AI agent that can execute client-facing outputs needs exactly this gate. The escalation_triggers sub-field is a good addition — FINRA Rule 3120 requires a supervisory control system with exception escalation, which this mirrors structurally.

FINRA 4511 / SEC 17a-4 (Books and Records) — The data_governance.retention_years field aligns with the 6-year general retention / 3-year accessible requirement under 17a-4. The audit_trail: immutable annotation is correct in spirit — 17a-4(f) requires WORM (write-once, read-many) storage for electronic records. Worth noting: the spec should probably document that the hook outputs (not just the agent manifest) need to satisfy this requirement.

FINRA 2210 (Communications) — fair_balanced: true and no_misleading: true are correct field names for the principle. FINRA 2210(d)(1) requires communications to be fair and balanced, and 2210(d)(1)(A) prohibits misleading statements. These map well.

Segregation of Duties (SOD) — The segregation_of_duties.conflicts array is the most architecturally significant part of the schema. FINRA Rule 3110 supervision and the Federal Reserve’s SR 11-7 (Model Risk Management) both require SOD between model development, validation, and approval. The [maker, checker] conflict pair is textbook. The handoffs.required_roles and approval_required fields are exactly the right pattern for a four-eyes principle implementation.

---

Gaps and recommendations

1. MiCA (EU) coverage is absent

For European deployments, MiCA (Markets in Crypto-Assets Regulation) is now live and imposes governance requirements on crypto-asset service providers (CASPs) that are directly analogous to FINRA/SEC. Specifically:

• MiCA Article 23: Governance arrangements require documented decision-making procedures — maps to supervision + segregation_of_duties
• MiCA Article 70: Record-keeping for 5 years — maps to data_governance.retention_years
• MiCA Article 82: Conflict of interest policy — maps to SOD

Recommendation: Add framework enum values for MiCA, DORA (Digital Operational Resilience Act), and GDPR alongside the existing FINRA/SEC entries.

2. SR 11-7 Model Risk Management is underspecified

The Federal Reserve’s SR 11-7 guidance on Model Risk Management is referenced in the codebase but the schema doesn’t expose the key SR 11-7 concepts that auditors will actually check:

• Model inventory: Every model must be inventoried with a unique identifier, owner, and use case. The agent.yaml + git SHA gives you this, but it should be explicit.
• Model validation: SR 11-7 requires independent model validation separate from development. The current SOD schema supports this with [developer, validator] roles — but this pair should be documented as a recommended preset.
• Ongoing monitoring: SR 11-7 §IV requires periodic monitoring of model performance. This could map to a monitoring field in the compliance block.

Recommendation: Add a model_risk sub-block under compliance with inventory_id, validation_required: bool, and monitoring_frequency fields.

3. CFPB / fair lending gap

The CFPB reference in the codebase is promising but the schema has no explicit field for fair lending / disparate impact controls. Under ECOA and the Fair Housing Act (both CFPB-enforced), AI systems making or influencing credit decisions must be auditable for disparate impact. The data_governance block is the right home for this.

Recommendation: Add data_governance.bias_testing: required | recommended | not_applicable and data_governance.protected_classes: [age, race, sex, ...] as optional fields.

4. Audit trail scope is too narrow

The current hooks system captures tool call inputs/outputs. But FINRA 4511 and SEC 17a-4 require capturing the full decision chain — not just what tools were called but why (the reasoning trace). For AI agents, this means the system prompt + conversation history + tool calls + model outputs must all be retained together as a single audit record.

Recommendation: The audit_trail field should have a scope sub-field: tool_calls_only | full_reasoning | conversation | all. Compliance deployments should require all.

5. No concept of “regulated output” flagging

FINRA 2210 distinguishes between retail communications, correspondence, and institutional communications — each with different review requirements. An AI agent producing a research report for retail distribution has different compliance obligations than one generating an internal memo. The schema currently treats all outputs uniformly.

Recommendation: Add output_classification to the compliance block: retail_communication | institutional_communication | correspondence | internal. This determines which supervisory review gate applies.

---

Assessment summary

The core compliance architecture is sound and maps correctly to the most important FINRA/SEC requirements. The SOD model is particularly well-designed. The main gaps are:

1. MiCA/DORA/GDPR coverage for EU deployments
2. SR 11-7 model inventory and validation fields
3. Fair lending / disparate impact controls for CFPB-regulated entities
4. Full reasoning-chain audit trail scope
5. Output classification for FINRA 2210 tiered review

Happy to draft specific schema proposals for any of these if useful.

---

Background: I work on ERC-3643 (tokenized RWA) compliance infrastructure and have contributed to Hyperledger/Splice (PR #4474). The intersection of agent infrastructure and financial compliance is exactly where I operate.