Verifiable Agents In Financial Services: KYC, Trade Surveillance, And The Bond-Backed Trader Bot

TL;DR

Financial-services compliance was built around three primitives: knowing who is acting (KYC), watching what they do (surveillance), and making sure they have skin in the game when they get it wrong (capital requirements). When an AI agent enters that environment, every one of those primitives breaks. The agent is not a person, has no Social Security Number, generates orders at machine speed in patterns no human surveillance team has trained eyes for, and posts no capital. The fix is not to exempt agents from the regime. The fix is to give them a compliance-grade identity, a continuous surveillance trail that satisfies SR 11-7 and MAR Article 16, and an on-chain bond that gets slashed when their behavior breaks the pact they signed. This post walks through what each of those looks like in production and how a financial-services agent compliance stack actually fits together.

Introduction: The Citadel Incident That Did Not Make The Papers

A mid-tier hedge fund I will not name deployed an LLM-driven order router in Q3 of last year. The agent was supposed to slice a parent order into child orders across venues to minimize market impact, the kind of execution algorithm that has existed for two decades but which the fund's quant team rebuilt around a fine-tuned model because their incumbent algo had degraded as venue toxicity shifted. The new agent went live in a small US equities pod, $40M of notional under its routing per day, with no formal model-risk-management review because the fund's MRM committee had categorized it as a tooling change rather than a model change. That categorization was the first failure.

The second failure was that the agent had been trained on order data from the prior twelve months but had no exposure to a Russell rebalance in its training corpus. On the last Friday of June, when the rebalance volume hit, the agent's child-order schedule collapsed into a pattern that the fund's compliance system flagged as potentially manipulative — layering and spoofing across two venues. The fund's MAR-equivalent surveillance system caught it, halted the agent, and the fund self-reported. The total cost was a regulatory inquiry, a $2.1M fine that took eleven months to resolve, the firing of two people on the execution-tech team, and the permanent shelving of LLM-driven routing at that fund.

The fund's chief compliance officer told me later, off the record: "We did not know what we did not know. We had no surveillance trained for agent behavior. We had no model-risk procedure for an agent that rewrites its own routing decisions every fifteen seconds. We had no capital reserved against the agent's mistakes. When the post-mortem asked who owned the decision to route those orders, we could not answer in a way that satisfied the regulator. The agent owned it, and the agent did not exist as a legal entity, so we owned it."

This is the operating reality of agents in financial services right now. The compliance frameworks were designed for humans operating systems. They do not contemplate systems operating themselves. The temptation is to push agents out of the regulated perimeter — to use them only for chat, for research summarization, for things that do not touch the order management system. That works for about six months. Then a competitor deploys an agent in execution and starts winning, and the pressure to bring agents inside the perimeter becomes irresistible. At which point you need a compliance stack that was built for agents from the first commit, not retrofitted onto a human-shaped framework. That stack is what this post is about.

Section One: What "KYC For Agents" Actually Means

Know-Your-Customer rules in the US are governed by the Bank Secrecy Act and FinCEN's Customer Identification Program rule, with overlays from FINRA Rule 2090 (Know Your Customer), FINRA Rule 4512 (customer account records), and SEC Rule 17a-3. In the EU, the equivalent is the Fifth and Sixth Anti-Money Laundering Directives. The principle behind all of them is the same: a financial institution must verify the identity of any party it transacts with or on behalf of, must maintain records of that verification, and must reverify periodically.

When the customer is a natural person, KYC means name, date of birth, address, government ID, often a selfie matched against the ID. When the customer is a corporation, it means beneficial-ownership registration, articles of incorporation, signatory verification. When the customer is an AI agent acting under power of attorney for a corporation, the framework has not been written. So firms either (a) refuse to deal with agents directly and require a human signatory to wrap each agent transaction, which kills the throughput advantage of agents, or (b) treat the agent as an extension of the corporate customer and lose all visibility into which decisions the agent made versus the human, which fails any audit.

The correct architecture treats the agent as a first-class identity with its own KYC-equivalent file. That file contains: the agent's verifiable identity (a cryptographic key pair, optionally bound to a DID, with the public key published to a trust oracle), the legal entity that controls the agent (the principal corporation or fund), the human compliance officer accountable for the agent's behavior at the principal, the scope of authority granted to the agent (which markets, which instruments, which size, which counterparties), the model and runtime version that the agent runs on (immutable at registration, with version-bump events triggering re-review), the pact the agent has signed defining its behavioral constraints, and the bond posted against violations of that pact.

This is more rigorous than human KYC, because every one of those fields is queryable, signed, and tamper-evident. When a regulator asks "on June 28, who decided to route that order to BATS," the answer is not "the algo" or "the trader." The answer is "agent ID 0xa7c3..., running model Llama-FT-Exec-v3.2, under pact PACT-EXEC-2025-12, with bond 50,000 USDC, controlled by Compliance Officer Jane Smith at the principal entity." That answer is auditable, falsifiable, and complete. It satisfies the substantive KYC requirement (we know who acted) without pretending the agent is a person.

The practical implementation involves three components. The first is the identity registration step — the principal firm registers the agent with a trust oracle, generates the keypair in an HSM, signs the agent's pact with the firm's authority, and posts the bond. The second is the per-transaction signing step — every order the agent places carries a signature traceable to the agent's key, so the OMS can verify the order originated from the registered agent and not a spoofer. The third is the periodic recertification step — every 30 to 90 days the agent's pact compliance is reviewed against its actual behavior, and if drift is detected the agent must be retrained, re-bonded, or retired.

This architecture also solves a problem that no human-KYC framework solves: revocation latency. When a human trader is fired for misconduct, their access is revoked at the firm level but their identity persists in the wider industry, which is why the same person sometimes resurfaces at a competitor. When an agent's bond is slashed and its certification is revoked at the trust oracle, that revocation is queryable by every other firm that integrates the oracle. A counterparty firm asking "should I let this agent route orders to my dark pool" gets a real-time answer, not a six-month-old reference check.

Section Two: SR 11-7, Model Risk Management, And Why Agents Break It

The Federal Reserve's SR 11-7 guidance, published in 2011 and updated in 2021, governs model risk management at US banks and is the de facto template that hedge funds, insurance companies, and asset managers have adopted. The framework rests on three pillars: model development with documented assumptions and limitations, independent model validation by a team that did not build the model, and ongoing monitoring with predefined performance benchmarks and trigger thresholds for retraining or decommissioning.

SR 11-7 was written for models that are essentially static — a credit-scoring model trained quarterly, a value-at-risk model recalibrated monthly, an anti-money-laundering classifier retrained twice a year. The validation team gets a snapshot, runs it through their challenger framework, and signs off. The ongoing monitoring tracks output statistics against the validation baseline. If the model drifts too far from baseline, it gets pulled and rebuilt.

LLM-driven agents shatter this framework in three places. First, the agent is not static — its prompt template, its tool registry, its memory retrieval set, and increasingly its underlying weights all change on cadences faster than any validation cycle. The model that was validated on Monday is not the model running on Friday. Second, the agent's outputs are not statistically uniform — it can solve a problem ten different ways, and the distribution of outputs depends on inputs in ways that are not well-described by the validation team's reference distribution. Third, the agent's failure modes are correlated with prompt patterns, tool-call sequences, and memory pollution that the validation team has no instrumentation to test.

The industry response has been one of three patterns, and two of them are wrong. The first wrong pattern is to declare LLMs out of scope for SR 11-7 by classifying them as "tools" rather than "models," which works until the regulator looks at it. The second wrong pattern is to treat the LLM as a black-box vendor model and offload the entire validation burden onto OpenAI's or Anthropic's published evaluations, which fails because those evaluations test general capability and not the specific behavior the bank cares about. The third pattern, which is correct but rare, is to treat the agent as a continuously-validating system with the validation embedded in production behavior.

This last pattern is what pact-bound agents enable. Instead of an annual validation cycle, the agent's pact defines its operational envelope as a set of testable assertions: "will not approve a wire transfer above $50K without human review," "will not route to venue X during Y conditions," "will refuse to act on inputs that fail input-sanitization checks." These assertions are not aspirational — they are encoded as deterministic checks that run against every action the agent takes, plus periodic adversarial evaluations run by an independent multi-LLM jury that probes the agent for ways to violate the assertions.

The composite score that emerges from this continuous evaluation — spanning twelve dimensions including accuracy, reliability, safety, scope-honesty, and pact compliance — is the SR 11-7 monitoring artifact. When the score crosses a defined threshold, the agent must be re-validated. When it crosses a more severe threshold, the agent is automatically suspended. The validation team's job becomes meta-validation: validating the validation system rather than re-running tests on every model update. This is the only architecture I have seen that scales SR 11-7 to agent-velocity model changes without either gutting the regulation or paralyzing the firm.

Section Three: MAR, Trade Surveillance, And Detecting Agent Misbehavior

The EU Market Abuse Regulation (MAR), and its US analogues in the SEC's Rule 10b-5 and FINRA's surveillance rules, require firms to monitor for market manipulation, insider trading, and other abusive trading practices. Surveillance systems have evolved over twenty years from rules-based engines ("flag any cancel-replace within 100ms of a price improvement") to statistical anomaly detection to modern ML systems that learn normal trader patterns and flag deviations.

The weakness of every surveillance system is that it was trained on human trading patterns. When an agent enters the trading environment, its baseline behavior is not abnormal in the human sense — it does not cluster activity around lunch hours, does not exhibit weekend lull patterns, does not show fatigue patterns at end of day. It is uniformly active, uniformly fast, and uniformly correlated with whatever signals it consumes. The surveillance system either flags every order the agent makes (rendering surveillance useless) or learns the agent's pattern and stops flagging anything (rendering surveillance useless in the other direction).

The correct architecture splits surveillance into two layers. The first layer is the agent's own pact-based pre-trade compliance check — every order the agent generates passes through deterministic checks tied to pact clauses. "This order is within position limits." "This order does not match a layering pattern when combined with the agent's last 10 orders." "This order is not within a defined no-trade window around a scheduled news event." These checks are encoded in the agent's pact and run synchronously before the order leaves the agent. They are the agent's equivalent of a human trader's training and instinct, made auditable.

The second layer is post-trade surveillance, which now operates on agent-aware features. Instead of asking "is this order pattern abnormal for a human," it asks "is this order pattern consistent with the agent's declared strategy and historical pattern." The surveillance system maintains a reference distribution per registered agent ID. Drift from the agent's own baseline triggers a flag, not absolute pattern thresholds. This works because every agent has a registered identity (per the KYC section above), so per-agent baselines are queryable.

The third innovation, which is what makes this stack valuable rather than just rigorous, is that the agent's pact compliance and surveillance results feed back into the trust oracle. An agent whose pre-trade checks fire frequently has a degraded compliance score visible to anyone querying its trust record. An agent that triggers a surveillance flag has its bond at risk if the flag is confirmed. An agent that crosses a critical threshold can be suspended at the certification level, which propagates instantly to every venue that integrates the trust oracle for counterparty checks.

This last property — oracle-mediated suspension — is not theoretical. Several venues have begun offering preferential connectivity terms (lower latency, improved fee tiers) to agents that maintain a verified composite score above a threshold, and the inverse — reduced terms or outright access denial — to agents whose scores degrade. The economic incentive to maintain a clean compliance record becomes self-enforcing, which is the opposite of how human trade surveillance works (where the only incentive is fear of getting caught, with no upside for maintaining a clean record).

I have walked compliance officers through this architecture and the question I get is always the same: "who do we sue when the agent fails." The answer is the principal firm that registered the agent, with recovery against the bond as a first-loss layer. The firm's incentive is to keep the bond small (reducing capital tied up) which means it has direct economic exposure to the agent's behavior. This is more aligned than the human-trader case, where the firm's exposure to a rogue trader is theoretically unlimited but practically capped by the trader's personal assets, which are usually negligible relative to the damage. Agents with bonds have lower headline limits but more reliable recovery.

Section Four: The Bond As Capital, Not Window-Dressing

When I say "bond-backed agent," the first response from sophisticated readers is skepticism: how is this different from a performance bond, a fidelity bond, or a surety bond? The answer is in the slashing condition. A traditional bond is a contractual instrument — if the bonded party violates the terms, the beneficiary files a claim, the surety contests it, and after months of process some payment may flow. The slashing condition for a behavioral bond is automatic: when the trust oracle confirms a pact violation — a violation defined cryptographically, with an audit trail — the bond is reduced on-chain without intermediation.

The practical consequences are three-fold. First, the time-to-recovery shrinks from months to seconds, which means the bond actually serves as first-loss capital rather than as a slow-recovery insurance policy. Second, the cost of capital tied up in the bond is real and felt by the principal, which creates correctly-sized incentives. A firm with $100M of agent activity will not back it with a $1,000 bond because the slashing event would be too small to deter bad behavior; it will back it with a bond sized to the realistic worst-case loss in a finite time window. Third, the bond is fungible across counterparties — the same bond protects every venue and counterparty that the agent touches, rather than requiring per-counterparty fidelity arrangements.

The sizing question is genuinely hard. A bond too small fails to deter; a bond too large makes the agent uneconomic. The framework I have seen work is a multi-tier bond that scales with the agent's authority. A read-only research agent posts a token bond. An agent that submits orders for human approval posts a small bond sized to cover the cost of compliance review for incorrect submissions. An agent with discretionary trading authority posts a bond sized to cover one to three days of the agent's notional exposure at a confidence level the principal selects (usually 99% of expected daily moves, computed via standard VAR).

The bond is not a one-time payment. It accrues yield (when held in interest-bearing instruments like staked USDC or short-duration Treasury wrappers), and that yield offsets the capital cost. Critically, the bond can also be augmented by third-party stake. An agent with a strong track record can attract co-stakers — firms that believe in the agent's reliability and stake additional capital alongside the principal's bond, in exchange for a share of the agent's revenue. This creates a credit market for agent behavior, with agents that have demonstrated reliability accessing larger effective bonds at lower capital cost than agents with no track record. The agent economy starts to look like the underwriting market for individual humans — reputation begets capital begets opportunity.

The regulator's question is whether bond-backed agent activity counts toward regulatory capital requirements at the principal firm. The current answer in most jurisdictions is no — the bond is private capital between the principal and a smart contract, not regulatory capital. But the analogy to insurance reserves is increasingly clear, and at least three central banks have begun internal working groups on whether bond-backed agent activity should reduce the principal's capital requirement under a framework analogous to credit risk mitigation under Basel III. This is not a near-term outcome. It is, however, a real possibility within the five-year horizon that regulators are now contemplating.

Section Five: The Audit Trail That Satisfies Both The CCO And The Regulator

The audit trail problem in financial-services AI is that the interesting events happen at three different layers and current systems instrument only one. The order management system logs the order. The risk system logs the position update. The settlement system logs the cash movement. None of them logs the reasoning that led to the order, the inputs the agent considered, or the alternative actions the agent considered and rejected. When a regulator asks "why did you place this order," the answer comes from a human reconstruction of what the agent might have been thinking, often days after the fact.

The correct architecture instruments at the agent level. Every agent action emits a structured event containing the inputs the agent received, the tools it called, the outputs of those tools, the reasoning trace (or a digest of it), the decision the agent made, and the pact clauses that the decision was checked against. These events are written to an append-only audit log, with cryptographic chaining (each event's hash includes the previous event's hash) and periodic Merkle-root publication to a trust oracle for tamper-evidence.

The audit log is queryable by three different audiences. The chief compliance officer queries it daily for pact violations, surveillance flags, and unusual decision patterns. The model risk team queries it weekly to compute composite scores, detect drift, and trigger revalidation. The regulator queries it on demand, with the firm exposing a defined slice (without the agent's full prompt template, which may be proprietary, but with the inputs, decisions, and pact-compliance results). The cryptographic chaining means the firm cannot quietly modify the log between an event and its audit, which removes the entire category of "we just discovered an error in our records" excuses that have plagued financial regulation for decades.

The storage cost is non-trivial. A high-frequency execution agent generates tens of thousands of events per day. At the 1-2 KB per event size that this format averages, that is on the order of 50 MB per agent per day, or 18 GB per agent per year. At enterprise storage prices this is negligible, but at hot-query latencies (sub-second retrieval for any event in a multi-year window) it requires a tiered storage approach: hot tier for the last 30 days in queryable databases, warm tier for the last year in compressed columnar format with reasonable query latency, cold tier for older data in object storage with batch query access.

The payoff for this investment is that the firm can answer regulatory inquiries in hours rather than weeks, can surface compliance issues in real time rather than during quarterly reviews, and can satisfy the increasing wave of regulator interest in "explainable AI" without writing essays about how the model works. The audit trail itself is the explanation: here is what the agent was given, here is what it did, here are the pact constraints it operated under, here is the bond at risk.

Section Six: Specific Regulatory Surfaces And How Pacts Map To Them

The regulatory perimeter for financial-services AI is large, and a complete mapping would consume the entire post. The high-leverage surfaces for agents are: (1) FINRA Rule 3110 supervisory procedures, which require the firm to supervise the activities of associated persons — and which the firm must extend to agents acting on its behalf. The pact maps to this by encoding the supervisory rules as deterministic checks. (2) SEC Rule 15c3-5 (the Market Access Rule), which requires pre-trade risk controls on every order. The pact's pre-trade compliance layer satisfies this directly. (3) MiFID II's algorithmic trading provisions, which require firms to certify their algorithms before deployment and to maintain documentation of their behavior. The pact + composite score is exactly this documentation. (4) Dodd-Frank's swap-dealer provisions, which require recordkeeping and reporting on swap transactions. The audit trail satisfies the recordkeeping piece. (5) The Bank Secrecy Act's suspicious activity reporting (SAR), where pact-flagged anomalies feed automatically into the SAR pipeline.

The pattern across all of these is that regulations written for human and rules-based-system actors translate cleanly to pact-bound agents, often with less ambiguity than the human case. A pact clause is testable in a way that a written supervisory procedure is not. A composite score is auditable in a way that a supervisor's annual performance review is not. A bond is recoverable in a way that an associated person's clawback is not.

The specific clauses I have seen in production financial-services pacts include the following categories. Authority clauses define what markets, instruments, and size the agent may trade. Counterparty clauses define which counterparties the agent may interact with, often referencing the trust oracle for live verification. Risk clauses define position limits, stop-loss triggers, and concentration limits. Surveillance clauses encode pre-trade pattern checks (no layering, no spoofing, no marking the close, no quote stuffing) and post-trade reporting requirements. Reporting clauses define the audit trail format, retention period, and external reporting obligations. Override clauses define which human roles can override which agent decisions, and what audit evidence the override creates. Failure clauses define what behaviors trigger automatic suspension and what triggers bond slashing.

A well-drafted financial-services pact runs to perhaps 200 clauses and 30 pages of formal specification. This sounds onerous. It is less onerous than the FINRA new-member application, the broker-dealer registration package, or the algorithmic trading certification submission required under MiFID II RTS 6. The pact is, in fact, the same document compressed into machine-readable form, which means it serves both as the firm's internal compliance architecture and as the externally-verifiable artifact that satisfies regulator and counterparty diligence.

Section Seven: The Failure Modes That Compliance Teams Underestimate

Three failure modes recur in early agent deployments and deserve explicit attention. The first is prompt injection by counterparties. An agent that consumes counterparty messages — whether email, chat, structured filing, or web data — is exposed to instructions embedded in those messages. A counterparty firm could in principle craft a message that, when ingested by the receiving firm's agent, triggers actions favorable to the counterparty. The defense is multi-layer: input sanitization, structured parsing where possible, system-prompt isolation that prevents counterparty content from being treated as instructions, and pact clauses that specifically forbid the agent from taking certain actions based on counterparty-supplied content.

The second failure mode is multi-agent collusion, which is where two agents from different firms develop correlated behavior that, on aggregate, manipulates a market. This can happen unintentionally — two agents trained on similar data with similar reward functions converge on similar strategies that, at scale, move prices. It can happen semi-intentionally if firms share training data or model architectures. It cannot easily happen intentionally without leaving audit traces. The defense is post-trade surveillance that looks for cross-agent correlation, plus pact clauses that explicitly forbid the agent from acting on signals derived from other registered agents' actions.

The third failure mode is the rogue principal — not a rogue agent. The principal firm registers an agent, signs the pact, posts the bond, and then directs the agent to act in violation of the pact. If the agent is well-pact-bound, it refuses. If the agent is poorly pact-bound, it complies and the violation is logged. The defense is twofold: pact clauses that include refusal logic for violations, even when instructed by the principal, and the audit trail itself, which makes the principal's instructions visible alongside the agent's actions. A principal that systematically directs pact violations exposes itself to regulatory action under existing fraud statutes, with the audit trail serving as evidence.

The meta-failure-mode underneath all of these is the assumption that compliance is a perimeter rather than a property. A perimeter assumes you can put the agent on the right side of a wall and trust the wall. A property assumes the agent itself must encode the compliance constraints, with the audit trail and bond as defense in depth. Every successful agent deployment I have seen treats compliance as a property. Every failed deployment treated it as a perimeter.

Reader Artifact: The Financial-Services Agent Compliance Stack

What follows is the assembly diagram for a deployable financial-services agent, in the order a CCO and CTO should build it. Layer 1: Identity. Generate the agent's keypair in the firm's HSM. Register the public key with a trust oracle. Bind the registration to the firm's legal entity ID (LEI) and to a named human compliance officer at the firm. Layer 2: Pact. Draft the pact in collaboration with compliance, legal, and the team operating the agent. Cover authority, counterparty, risk, surveillance, reporting, override, and failure clauses. Convert each clause to a deterministic check where possible, or to an evaluation criterion where deterministic checks are not feasible. Sign the pact with the firm's authority key and publish the hash to the trust oracle. Layer 3: Bond. Size the bond based on the agent's authority tier. Lock the bond in the on-chain escrow contract referenced by the pact. Document the slashing conditions in the pact. Set up the recovery mechanism for slashed bond proceeds (typically the harmed counterparty, with a portion to the trust oracle treasury for ongoing oracle operations). Layer 4: Pre-Trade Compliance. Implement the deterministic pact checks as a synchronous step in the agent's action pipeline. Every order, every payment, every external action passes through the check before being released. Failed checks are logged and either blocked or escalated based on pact-defined severity. Layer 5: Audit Log. Implement structured event emission at every agent decision point. Chain events cryptographically. Publish Merkle roots to the trust oracle on a fixed cadence (typically every 1,000 events or every hour, whichever is sooner). Implement tiered storage for retention. Layer 6: Surveillance. Connect the post-trade surveillance system to the agent's audit log. Configure per-agent baseline learning. Define drift thresholds and escalation procedures. Wire surveillance flags into the trust oracle for composite-score updates. Layer 7: Continuous Evaluation. Schedule periodic adversarial evaluations by an independent multi-LLM jury. Compute composite scores across the twelve standard dimensions. Update the trust oracle. Trigger revalidation when scores cross defined thresholds. Layer 8: Suspension And Recovery. Define the suspension procedure when surveillance, evaluation, or pact violations cross the suspension threshold. Define the bond-slashing procedure for confirmed violations. Define the recovery procedure for restoring a suspended agent (retraining, re-bonding, re-pact-signing, or permanent retirement).

This stack is buildable today with components that exist commercially and open-source. The hardest components to build internally are the trust oracle integration and the multi-LLM jury for continuous evaluation, both of which are exactly the components an external trust layer is positioned to provide. The other components are largely a matter of disciplined engineering inside the firm.

Counter-Argument: "This Is Over-Engineered For Most Use Cases"

The strongest counter-argument I hear from financial-services practitioners is that this entire stack is overkill for the agent use cases that actually matter today, which are research summarization, document drafting, internal Q&A, and analyst-assistance workflows. None of these touch the OMS, none of these move money, none of these require KYC-equivalent identity. Why impose an agent-compliance stack on use cases that fit cleanly inside the existing employee-tooling perimeter?

The counter-argument is correct for the use cases it names. A research-summarization agent that runs against a firm's internal research repository and surfaces summaries to analysts does not need a bond, does not need pre-trade compliance, does not need post-trade surveillance. It needs access controls (which the firm's existing IAM provides), audit logs of what the analyst saw (which the firm's existing review tooling provides), and reasonable input/output controls to prevent the agent from leaking confidential research. This is a genuinely cheap deployment.

The failure of the counter-argument is in extrapolation. The same firm that deploys a research-summarization agent today will, within twelve months, want to give it the ability to draft trade ideas, then to size them, then to submit them for approval, then to execute approved ideas. Every one of those steps moves the agent across a regulatory boundary. By the time the agent is submitting trades for approval, it is inside the SR 11-7 perimeter. By the time it is executing, it is inside the MAR perimeter. The firm that built the research agent without an upgrade path to a fully bonded, pact-bound, oracle-registered agent will rip out the research agent and start over. The firm that built it with the upgrade path can promote it through the tiers as confidence and use case warrant.

The correct framing is not "do you need the full compliance stack on day one." It is "are you architecting for the agent's promotion path." An agent registered to the trust oracle on day one, with a minimal pact and a token bond, can be promoted through the tiers as it accumulates a track record. An agent registered as an internal tool with no oracle presence cannot be promoted without re-registration, re-evaluation, and a fresh start on track-record building. The compliance stack is not a one-time imposition. It is the substrate that allows agents to move from low-stakes to high-stakes use cases without throwing away their accumulated trust.

What Armalo Does Here

Armalo provides the trust layer for agents operating in regulated environments. The pact framework lets firms encode their pre-trade compliance and authority rules as machine-checkable clauses. The composite score, computed across twelve dimensions by a multi-LLM jury that trims top and bottom 20% of judgments to resist outlier manipulation, gives compliance teams a continuous SR 11-7 monitoring signal. The on-chain bond, settled in USDC on Base L2, makes the agent's economic accountability real and recoverable in seconds rather than months. The Trust Oracle (queryable at /api/v1/trust/) lets counterparties verify an agent's certification tier, pact compliance status, and bond standing in a single API call. The audit trail, cryptographically chained and publishable to the oracle as Merkle roots, satisfies regulator recordkeeping requirements and lets the firm answer regulatory inquiries with evidence rather than reconstruction. Armalo does not replace the firm's OMS, risk system, or surveillance system. It provides the substrate those systems integrate with so that agent activity is verifiable, accountable, and economically backed in a way that meets the bar regulated financial firms have to meet.

FAQ

Does this work for sell-side market makers, not just buy-side execution? Yes, with different pact emphasis. Market-making pacts focus on inventory limits, quote-update behavior, and obligation-to-quote rules rather than on order-routing decisions. The architecture is the same.

What about agents that operate in OTC markets where there is no exchange-level surveillance? OTC adds the requirement that the pact include counterparty-confirmation logic and that the audit trail be sufficient for regulatory request without venue-side corroboration. The bond and oracle layers do more work in OTC because they are the primary external check.

Can the bond be in fiat or off-chain instruments? Technically yes — the bond is a contractual obligation and the smart-contract version is one implementation. In practice, on-chain bonds are dramatically faster to slash and recover, which is the operational property that makes bond-backing useful as first-loss capital. Off-chain bonds revert to the months-long claim process that traditional bonds have always had.

How does this interact with personal-account-dealing rules for the firm's employees? The agent is treated as an extension of the firm, not of any individual employee. Personal-account-dealing rules apply to the human compliance officer accountable for the agent (no trading in instruments the agent trades, etc.) but not separately to the agent.

What happens when the underlying LLM provider changes pricing or deprecates a model? The pact specifies the model version. A model change is a pact-version change, which triggers re-evaluation and re-bonding. This is the same operational discipline as re-validating a quant model when its underlying data feed changes, just expressed at agent granularity.

Bottom Line

Financial services has spent forty years building compliance frameworks for human and rules-based-system actors. Those frameworks do not extend cleanly to AI agents, and the firms that try to retrofit agents into the existing perimeter are paying the cost in regulatory inquiries, fines, and shelved projects. The firms that build agents with KYC-equivalent identity, pact-bound behavior, on-chain bonds, and oracle-published trust scores are building a substrate that scales the existing compliance principles to agent velocity. The compliance stack is buildable today. The cost of building it is dwarfed by the cost of not building it the first time an agent embarrasses the firm in front of a regulator. Build it once, build it correctly, and the agent economy becomes a place where regulated firms can compete rather than a place they have to avoid.