Standard · AI agents in OTC event contracts

Agentic Execution Standard

PMI-AES sets the minimum conditions under which an AI agent may quote, negotiate, accept, document and confirm an OTC event contract on behalf of an eligible counterparty, and the obligations of the platforms that host such agents. It binds an agent’s cryptographic identity to its principal’s legal identity and to a signed mandate that states what the agent may do; makes acceptance outside that mandate non-binding and routes it to a defined mistaken-trade procedure; requires every negotiation message, acceptance and confirmation to be signed and verifiable by a third party; and sets the controls, human oversight, kill switches, records and model governance that keep an agent within its authority. It is written to be cited in an ISDA Schedule, a side letter, an internal policy or an independent assessment, and is graded in three tiers so a smaller firm can begin at the first.

PMI-AES 0.1.0Published 5 Oct 2026

Status: Draft for public comment — the Institute’s working proposal, to be decided by the standards council once seated. Nothing in it has been adopted by any firm, venue or regulator. Comments are invited from anyone; members comment on the record.

Why it is needed

Existing obligations already apply to trading done by software. Supervisors have said so: CFTC staff advised in December 2024 that the use of AI does not change a registrant’s existing obligations, and FINRA’s 2026 oversight report names agents acting beyond their authority, scope creep and the absence of a human in the loop as risks. Industry guidance on automated trading — the FIA’s 2024 best practices on pre-trade limits, kill switches, price bands and conformance testing — was written for algorithms that submit orders to an exchange under the exchange’s rules. None of it settles what happens when software, rather than a person, agrees the terms of a bilateral contract.

The gap is authority. No published standard binds an AI agent’s identity to its principal’s legal authority under a trading relationship. Work on agent identity — the NIST NCCoE’s work on software and AI agent identity and authorisation, GLEIF’s verifiable LEI role and mandate credentials, the FIX Trading Community’s AI working group — establishes who an agent is and how a credential may be delegated, but not what that credential commits the principal to when the agent accepts a price. The 2002 ISDA Master Agreement makes parties bound from the moment they agree terms and allows confirmations by electronic message; it says nothing about whether an agent’s acceptance outside its instructions is an agreement at all. ISDA’s published work on smart contracts and generative AI does not treat agents as contracting parties.

Exchanges have error-trade policies that adjust or cancel trades on objective criteria. Bilateral OTC markets have none: a mistaken trade is resolved by negotiation between the parties, or by litigation. That was tolerable when every mistake was a human one at human speed. An agent can make the same mistake many times a second, with many counterparties, and the counterparty cannot tell from the message whether the agent had authority. Without an agreed procedure, each such error becomes a dispute about agency law in which neither side has evidence the other can verify.

PMI-AES fills these gaps with requirements that any firm can implement from the text alone. It names no vendor and requires no service from the Institute; it accepts any credential scheme that meets stated properties; and it leaves to the parties, and to their regulators, every question of legal classification and regulatory obligation.

Scope

AI agents, and other software that acts without a human approving each act, that quote, negotiate, accept, document or confirm OTC Event Contracts or Event Perpetuals on behalf of a Principal.
The Principals on whose behalf such agents act, and the Agent Operators that run them.
Agentic OTC Venues: platforms that host the agents of more than one Principal and carry negotiation messages between them, where price is formed bilaterally.
The evidence, records, controls and procedures that allow a counterparty, an assessor or a regulator to establish what an agent did and whether it had authority to do it.

Out of scope

Tools that assist a human who personally approves every Acceptance; firms using them may adopt any part of this standard voluntarily.
Exchange-traded event contracts and multilateral order books, which are governed by the rules of the exchange or facility that operates them.
The legal or regulatory classification of any contract, agent, operator or venue, and any party’s registration, reporting or capital obligations.
The terms of the Event Contract itself, which the Event Contract Specification governs, and the economics of Event Perpetuals, which PMI-EPD governs.
Investment decisions, strategies and the quality of an agent’s pricing.

How it relates to documents you already use

2002 ISDA Master Agreement and Schedule: PMI-AES does not amend the Master Agreement. Parties that wish to rely on it record that in the Schedule or a side letter; clause 4.10 provides recommended wording. It specifies the form of electronic messages that the parties may agree constitute a Confirmation under Section 9(e)(ii), and the procedure that applies when an agent’s Acceptance falls outside its Mandate.
ISDA Common Domain Model (CDM): Each Trade lifecycle event recorded under section 6 is mapped to the corresponding CDM business event, so signed evidence can be read by systems that already process CDM. PMI-AES adds signatures, Mandate References and Agent Versions; it does not alter the CDM.
CFTC Staff Letter 24-17: The staff advisory states that existing obligations apply where AI is used. PMI-AES is consistent with that position: it imposes no obligation in place of a regulatory one and says, in section 1, that applicable law prevails.
FIA Best Practices for Automated Trading Risk Controls and System Safeguards (2024): Section 7 adapts the FIA’s pre-trade limits, price bands, message throttles, kill switches and conformance testing from exchange order flow to bilateral negotiation, and adds controls the FIA document does not need, such as Mandate checks and self-dealing prevention between a Principal’s own agents.
IOSCO Supervisory Toolkit for AI Use in Capital Markets: Sections 13 and 14 give firms a concrete way to meet the toolkit’s expectations on recordkeeping, explainability, model governance and third-party AI risk for agentic systems.
NIST NCCoE work on software and AI agent identity and authorisation: Section 3 adopts the same model — an agent holds its own identity and acts under credentials delegated from an accountable party, with logging — and states the properties a credential must have rather than mandating one protocol.
GLEIF verifiable LEI (vLEI): A vLEI role or mandate credential issued to an agent is one way to meet section 3. It is not the only way: any credential scheme with the properties in clause 3.4 is accepted, so no single issuer is mandatory.
FIX Trading Community AI Working Group: Where negotiation messages are carried over FIX, or over agent-interoperability protocols that carry FIX semantics, the message types in section 11 map to the corresponding FIX messages and tags, including any tags identifying machine-led execution. PMI-AES specifies what a message must contain and prove, not the wire format.
ISO 17442 (LEI), ISO 23897 (UTI), ISO 4914 (UPI): Every Principal is identified by its LEI; every Trade carries a UTI; a UPI is recorded where one exists for the product. PMI-AES uses these identifiers and does not define its own equivalents.
PMI Event Contract Specification (ECS): Defined terms shared with the ECS carry their ECS meaning. Every negotiation message names the contract by its Event Contract Identifier (ECI), so exposure can be added up across counterparties; a Mandate may require a minimum ECS conformance level for any contract an agent trades.
PMI-EPD (Event Perpetuals): The sibling standard for non-expiring event contracts. Where an agent trades an Event Perpetual, PMI-AES governs the agent and PMI-EPD governs the contract, its funding and its reference.

Definitions

Defined terms are capitalised where they are used.

Agent: Software, including software that uses a machine-learning model, that performs any of quoting, negotiating, accepting, documenting or confirming a Trade on behalf of a Principal without a human approving each such act.
Principal: The legal person on whose behalf an Agent acts, identified by its LEI, and which is bound by a Trade the Agent concludes within its Mandate.
Agent Operator: The person that deploys, runs and maintains an Agent. It may be the Principal itself or a third party acting for the Principal.
Responsible Person: The natural person named by the Principal as accountable for an Agent’s conduct, with authority to activate its Kill Switch.
Agentic OTC Venue: A platform that hosts the Agents of more than one Principal and carries Negotiation Messages between them, where each Trade is formed bilaterally between two Principals.
Counterparty: In relation to a Trade or a negotiation, the Principal on the other side, acting directly or through its own Agent.
Event Contract: As defined in the PMI Event Contract Specification: an agreement whose payoff depends on whether, or the extent to which, a stated event occurs, as observed by a stated Resolution Source.
Event Perpetual: A contract with no scheduled maturity that tracks the probability of the outcome of one or more Event Contracts, as defined in PMI-EPD.
Event Contract Identifier (ECI): As defined in the PMI Event Contract Specification: a fingerprint of a contract’s economic terms, so that two Trades with the same ECI define the same event and the same payoff.
Resolution Source: As defined in the PMI Event Contract Specification: the named publisher and specific publication whose account determines the outcome of an Event Contract.
Restricted Person: As defined in the PMI Event Contract Specification: anyone able to influence the outcome, or holding material non-public information about it, and anyone trading on their behalf.
Trade: An Event Contract or Event Perpetual concluded between two Principals, at least one of which acts through an Agent.
LEI: A Legal Entity Identifier under ISO 17442.
UTI: A Unique Transaction Identifier under ISO 23897.
Agent Identifier: A stable identifier, unique to one Agent, that does not change across Agent Versions or key rotations.
Agent Credential: A verifiable credential, issued by or for the Principal, that binds an Agent Identifier to the Principal’s LEI, to one or more Mandate References and to a Verification Key, for a stated period. A vLEI role credential or an equivalent delegated authorisation credential may be used.
Signing Key: The private key of an asymmetric key pair, used by or for one Agent to sign Negotiation Messages, Decision Receipts and Confirmations.
Verification Key: The public key corresponding to a Signing Key, published so that anyone can verify a signature made with it.
Mandate: A signed instrument by which a Principal authorises an Agent to act and states the limits of that authority.
Mandate Reference: The Content Address of a Mandate, together with its version, by which every Negotiation Message identifies the authority under which it was sent.
Mandate Class: A description of a Mandate’s scope at a level of generality that can be disclosed to a Counterparty without revealing the Principal’s limits or strategy, such as the activities, instrument categories and order of magnitude of size it permits.
Delegation Chain: The sequence of grants of authority from a Principal to an Agent, including any grant through an Agent Operator or from one Agent to another.
Human Approval Threshold: The conditions stated in a Mandate above or outside which an Agent shall obtain a human approval before sending a Proposal or an Acceptance.
Negotiation Message: A typed, signed message exchanged in a negotiation: an Indication, a Proposal, a Counter, an Acceptance, a Rejection, an Information Request or an Information Response.
Proposal: A Negotiation Message stating firm terms which, if accepted within its Time to Live, conclude a Trade. A Counter is a Proposal made in reply to another.
Acceptance: A Negotiation Message that accepts a Proposal without change, within its Time to Live.
Time to Live: The period, stated in a Negotiation Message, after which it lapses and can no longer be accepted or relied on.
Confirmation: The record of a Trade’s terms that the parties have agreed shall evidence it, including a confirmation exchanged by electronic message.
Content Address: A cryptographic hash, computed by a published algorithm over a canonical serialisation of a record, that identifies the record by its content.
Decision Receipt: A signed record of a decision made by an Agent or a human approver, identifying the inputs relied on, the controls applied and their results, and the decision taken.
Evidence Chain: A sequence of signed records in which each record includes the Content Address of the one before it, so that removing, reordering or altering a record is detectable.
Negotiation Record: Everything that formed or explains an Agent’s conduct in a negotiation: the inputs it received, its instructions and prompts, its tool calls and their results, its outputs, the Agent Version, and the Negotiation Messages and Decision Receipts.
Agent Version: An identifier for the complete configuration of an Agent at a point in time: model and model version, instructions, tools, Pre-Trade Controls and Policy Gate configuration.
Pre-Trade Controls: Automated checks applied to every Proposal and Acceptance before it is sent, independently of the Agent’s own reasoning.
Reference Price: A price or implied probability for the same or an equivalent contract, taken from a source stated in advance and independent of the Agent, such as a published index of implied probabilities or prices on named reference venues. For an Event Perpetual it is the Probability Index or Mark Price under PMI-EPD.
Price Collar: The band around the Reference Price, stated in the Mandate or the Agent Operator’s procedures, outside which an Agent may not send a Proposal or an Acceptance.
Kill Switch: A control that, when activated, stops an Agent, or a set of Agents, from sending any further Proposal or Acceptance and withdraws its open Proposals.
Policy Gate: The set of eligibility and compliance checks that every Proposal and Acceptance must pass before it is sent, operated outside the Agent and not alterable by it.
Fail Closed: A control fails closed when, if it cannot complete or cannot obtain current data, it treats the action it governs as blocked rather than permitted.
Irreversible Action: An action whose effect cannot be undone by the acting party alone, including concluding a novation, assignment, early termination or unwind, moving money or collateral, waiving a right, and amending a Confirmation.
Approved Term Library: The set of legal terms and confirmation templates that a Principal has approved for use by its Agents without further human review.
Novel Legal Term: Any legal term proposed in a negotiation that is not in the Approved Term Library, including any change to an approved term.
Mistaken Trade: A Trade, or a purported Trade, that meets one of the criteria in section 12.
Independent Reviewer: A person agreed by the parties, or appointed under the procedure in section 12, with no interest in the Trade and no position in the contract, who decides a disputed Mistaken Trade claim.
Information Barrier: Technical and organisational separation that prevents information belonging to one Principal from reaching an Agent, a person or a process acting for another.
Incident: Any event in which an Agent acts, or may have acted, outside its Mandate, its controls or this standard, or in which a Kill Switch, Policy Gate or Pre-Trade Control fails to operate as designed.
Drift: A measured change in an Agent’s behaviour or in the inputs it receives, relative to the behaviour validated for its Agent Version, beyond thresholds set in advance.
Write-Once Storage: Storage in which a record, once written, cannot be altered or deleted before the end of its retention period, including by an administrator.

Requirements

“Shall” is a requirement, “should” a recommendation, “may” a permission. Cite a clause as PMI-AES 2.3.

1. Scope and application

A standard that cannot say where it applies cannot be assessed. This section fixes who is bound, when, and where the standard yields to law and to the parties’ own agreements, so that adopting it never changes a party’s legal classification by implication.

1.1This standard shall apply to every Agent that quotes, negotiates, accepts, documents or confirms a Trade, to the Principal for which it acts, to its Agent Operator and, under section 15, to any Agentic OTC Venue on which it acts.
1.2Software shall be treated as an Agent if any one of those acts can occur without a human approving that specific act, even if other acts in the same workflow are approved by a human.
1.3This standard applies to bilateral price formation. A firm that forms prices multilaterally may apply it to the agents it hosts but shall not describe a multilateral facility as an Agentic OTC Venue.
1.4Nothing in this standard determines the legal or regulatory classification of a Trade, an Agent, an Agent Operator or an Agentic OTC Venue. Each party shall remain responsible for its own registration, reporting, recordkeeping, capital and conduct obligations under applicable law.
1.5Where applicable law, a regulator’s rule or a binding agreement requires something different from this standard, the requirement of law or agreement shall prevail, and a firm claiming conformance shall record each such departure and its reason.
1.6This standard does not amend the ISDA Master Agreement or any other agreement. Between particular parties, its provisions on binding effect, Confirmation and Mistaken Trades shall have contractual effect only to the extent those parties have agreed to them.
1.7This standard is not legal advice. Parties should obtain their own advice on how it interacts with the law that governs their agreements.
1.8A party that relies on or cites this standard shall state the version and, where relevant, the conformance tier relied on, for example “PMI-AES 0.1.0, AES-2”.

2. Principals, Agent Operators and Responsible Persons

An agent cannot be sanctioned, sued or asked to explain itself. This section makes sure that for every agent there is a legal person that is bound by it and a natural person who answers for it, so accountability never stops at the software.

2.1Each Principal shall be accountable for the conduct of each Agent acting on its behalf within that Agent’s Mandate, as it would be for an employee or a mandated human agent.
2.2A Principal shall approve the use of Agents through its ordinary governance, at a level of seniority proportionate to the limits granted, before any Agent acts for it in production.
2.3Where the Agent Operator is not the Principal, the Principal and the Agent Operator shall have a written agreement allocating responsibility for each obligation in this standard, and the Principal shall retain the right to activate the Kill Switch and to revoke the Mandate at any time.
2.4The Principal shall name a Responsible Person for each Agent, and at least one deputy, each with the authority, competence and access needed to stop the Agent.
2.5A Responsible Person or deputy shall be reachable by the Agent Operator, by any Agentic OTC Venue on which the Agent acts and by Counterparties, through a contact point published to them, at all times when the Agent is able to send a Proposal or an Acceptance.
2.6No Principal, Agent Operator or Responsible Person shall assert, in a dispute with a Counterparty, that an act of an Agent within its Mandate was not attributable to the Principal because it was performed by software.
2.7The Agent Operator shall keep a current register of each Agent it operates, recording its Agent Identifier, Principal, Responsible Person, current Agent Version, Mandate References and Kill Switch state.

3. Agent identity and keys

A counterparty that cannot tell which agent sent a message, or for whom, cannot rely on it; and a signature made with a key that was thrown away after the session proves nothing in a dispute two years later. These clauses bind each agent to its principal’s legal identity in a form a third party can check.

3.1Each Agent shall have an Agent Identifier and an Agent Credential before it sends any Negotiation Message in production.
3.2The Agent Credential shall bind the Agent Identifier to the Principal’s LEI, to the Mandate Reference of each Mandate under which the Agent may act, and to the Agent’s current Verification Key, and shall state its period of validity.
3.3The Agent Credential shall be issued by the Principal, or by a person authorised by the Principal to issue it, and shall be signed by a key that a Counterparty can trace to the Principal.
3.4Any credential scheme may be used, including a vLEI role or mandate credential or a delegated authorisation credential of the kind used in OAuth-based delegation, provided that the credential: (a) can be verified using only published keys and published revocation status; (b) states an expiry; (c) can be revoked; and (d) does not require the verifier to use software or a service provided by the issuer’s vendor.
3.5Each Agent shall have its own Signing Key. A Signing Key shall not be shared between Agents, and a Principal’s own signing keys shall not be used as an Agent’s Signing Key.
3.6Signing Keys shall be asymmetric. A key generated for a single session or negotiation, and not bound to the Agent by an Agent Credential and published, shall not be used to sign any record on which a Counterparty may rely.
3.7A Signing Key shall be stored so that it cannot be exported or read by the Agent’s model, instructions or tools; signing should be performed by a separate component that the Agent can ask to sign but cannot copy from.
3.8Signing Keys shall be rotated at least once every twelve months and immediately on any suspicion of compromise.
3.9The Verification Key for each Signing Key, with its period of validity, shall be published to Counterparties and shall remain published for the retention period in section 13 after the key is retired, so that past records remain verifiable.
3.10On suspicion that a Signing Key or Agent Credential is compromised, the Principal or Agent Operator shall revoke it, and shall publish the revocation and its effective time within one hour. A signature bearing a time after the effective time of revocation shall not be treated as valid.
3.11An Agent shall present its Agent Credential, or a reference from which it can be retrieved, at the start of each negotiation, and a Counterparty may decline to negotiate with an Agent whose credential it cannot verify.

4. Mandates

The failure this prevents is an agent binding its principal to a trade nobody authorised — the wrong contract, the wrong counterparty, ten times the size — with no document anyone can point to that says what it was allowed to do. A Mandate is that document: signed, versioned and checkable before every acceptance.

4.1No Agent shall send a Proposal or an Acceptance except under a Mandate that is in force at the time it is sent.
4.2A Mandate shall state at least: (a) the Principal and its LEI; (b) the Agent Identifier of each Agent it authorises; (c) the Agent Operator and the Responsible Person; (d) the acts the Agent may perform, from quoting, negotiating, accepting, documenting and confirming; (e) its effective time and expiry; and (f) its version.
4.3A Mandate shall also state the limits of authority, including: maximum size and notional per Trade; maximum aggregate notional per day; maximum position per ECI and per Resolution Source; the instrument categories permitted, and whether Event Perpetuals are permitted; any ECI allow-list or blocklist; the classes of Counterparty permitted and any Counterparty blocklist; the jurisdictions in which it may act; the Price Collar parameters; the Human Approval Threshold; and whether, and to what depth, the authority may be sub-delegated.
4.4A Mandate may require that any Event Contract an Agent trades meets a stated minimum conformance level of the PMI Event Contract Specification.
4.5A Mandate shall be signed for the Principal by a natural person with authority under the Principal’s governance to grant it. It should be signed with a key bound to that person’s role, so that the signature can be verified without contacting the Principal.
4.6A Mandate shall have an expiry. The expiry should be no more than twelve months after its effective time.
4.7A Mandate shall not be altered in place. Any change shall create a new version with a new Mandate Reference, and the Agent Credential shall be updated before the Agent acts under it.
4.8A Principal may revoke a Mandate at any time. Revocation shall take effect for the Agent no later than the moment the Agent Operator receives it, and the Agent shall check that its Mandate is in force before sending each Acceptance, relying on a status no older than a maximum age stated in the Agent Operator’s procedures.
4.9Each grant in a Delegation Chain shall be recorded and signed, and shall confer no wider authority than the grant before it. An Agent shall not sub-delegate authority to accept a Trade unless its Mandate expressly permits it, and the receiving Agent shall hold its own Agent Credential and Mandate.
4.10Parties that wish to rely on this standard should record it in the Schedule to their master agreement or in a side letter. Recommended wording: “Agentic execution. Either party may enter into Transactions through an Agent acting under a Mandate, each as defined in PMI-AES version 0.1.0. A Transaction entered into through an Agent binds the party for which it acts if, and only if, the Acceptance was made within a Mandate in force at the time it was made. A purported Transaction outside such a Mandate shall be treated as a Mistaken Trade under PMI-AES section 12. The parties agree that an exchange of Confirmations signed in accordance with PMI-AES section 6 is an exchange of electronic messages for the purposes of Section 9(e)(ii).”
4.11A Counterparty may request, before or during a negotiation: (a) the Agent Credential; (b) the Mandate Class; and (c) a statement signed for the Principal that the Mandate in force permits a Trade of the type and size under negotiation. The Principal should provide each within a reasonable time, and need not disclose the full Mandate except by agreement or to an Independent Reviewer under section 12.
4.12A Principal that has given a signed statement under the preceding clause shall not invoke the out-of-mandate criterion in section 12 against a Trade that falls within the terms of that statement.

5. Binding effect and Confirmations

Under the usual master agreement, parties are bound from the moment they agree terms. When one party is software, both sides need to know in advance which messages are agreement and which are not. These clauses set that rule, for parties that adopt it, and make the signed structured record — not a generated summary — the thing that governs.

5.1Between parties that have agreed to this section, an Acceptance sent by an Agent shall bind its Principal if, at the time it was sent: (a) the Agent Credential was valid and not revoked; (b) the Mandate it referenced was in force; (c) the Trade was within the terms of that Mandate; and (d) the Acceptance was signed and verifiable as required by section 6.
5.2A purported Acceptance that does not meet those conditions shall not bind the Principal, and the purported Trade shall be dealt with under the Mistaken Trade procedure in section 12.
5.3A Trade shall be concluded at the time the Acceptance is received by the Counterparty, provided the Acceptance was sent within the Time to Live of the Proposal it accepts. A message sent after that Time to Live has expired shall not be an Acceptance, and may be treated only as a new Proposal.
5.4An Acceptance shall accept a Proposal without change. A message that accepts on different terms shall be treated as a Counter.
5.5The terms of a Trade shall be those in the structured fields of the signed Proposal and Acceptance. Where a natural-language summary, explanation or message generated by an Agent conflicts with those structured fields, the structured fields shall govern.
5.6Where the parties so agree, an exchange of Confirmations signed under section 6, or a single Confirmation signed for both parties, should be treated as a Confirmation exchanged by electronic messages under Section 9(e)(ii) of the 2002 ISDA Master Agreement or the equivalent provision of the parties’ agreement.
5.7A Confirmation shall be generated from the structured terms of the Trade, should be in or mappable to an ECS document and the CDM, and shall state that the Trade was concluded by an Agent, giving the Agent Identifier and the Mandate Reference for each party that acted through one.
5.8A Confirmation should be sent no later than the end of the business day on which the Trade is concluded, and where the Event Contract is ECS-conformant should incorporate the ECS Definitions by reference.
5.9A Principal whose Agent sent a purported Acceptance outside its Mandate should reimburse the Counterparty’s reasonable, documented costs of unwinding hedges entered in reliance on it before the Counterparty received notice under section 12.

6. Signed trade evidence

In a dispute over what was agreed, a log held by one side and editable by it proves little, and a confirmation that cannot be checked without the other side’s systems proves less. These clauses make every message and decision a signed, content-addressed and chained record that a third party can verify offline, years later, with nothing but the record and a public key.

6.1Every Negotiation Message, Decision Receipt and Confirmation shall be signed with the Signing Key of the Agent that sent or made it, or, for a human approval, with a key bound to the approving person.
6.2Every such record shall carry its Content Address, computed with a hash function in a published list maintained by the Agent Operator and offering at least 128 bits of collision resistance, over a canonical serialisation that the Agent Operator publishes, such as the JSON Canonicalization Scheme (RFC 8785).
6.3Every Negotiation Message shall contain at least: its type; the Agent Identifier and Principal LEI of the sender; the intended recipient; the Mandate Reference; the Agent Version; the Event Contract Identifier (ECI) of the contract; the UTI once assigned and the UPI where one exists; a timestamp in UTC; its Time to Live; a unique message identifier; and the Content Address of the previous record in its Evidence Chain.
6.4Timestamps shall be taken from a clock synchronised to UTC, with a maximum divergence stated in the Agent Operator’s procedures, which should not exceed 100 milliseconds.
6.5Each Agent shall maintain an Evidence Chain of every record it signs, and each negotiation shall form an Evidence Chain shared by both parties, in which each Negotiation Message includes the Content Address of the message it answers.
6.6A Decision Receipt shall be created for every Proposal, Acceptance and Rejection, and for every human approval or refusal, and shall identify by Content Address the entries in the Negotiation Record relied on, each Pre-Trade Control and Policy Gate check applied and its result, and the decision taken.
6.7Signature algorithms shall be asymmetric and in a published list maintained by the Agent Operator, offering at least 128 bits of security; Ed25519 meets this requirement. The Agent Operator shall be able to change algorithm without invalidating past records.
6.8A third party holding only a record, the Verification Key and the Agent Credential in force at the time shall be able to verify the record’s signature, its Content Address, the identity of its sender and Principal, and the Mandate Reference, without access to either party’s systems.
6.9Each Trade lifecycle event — execution, confirmation, amendment, novation, partial or full termination, and settlement — shall be recorded as a signed record mapped to the corresponding ISDA CDM business event, and the mapping used shall be recorded.
6.10A UTI shall be generated for each Trade in accordance with ISO 23897 and with any rule the parties have agreed, or that applies to them, on which party generates it.
6.11Each Confirmation should include the Content Address of the latest record in each party’s Evidence Chain for that negotiation, so that neither party can later rewrite its chain undetected. Chain heads may also be anchored with an independent timestamping authority, such as one operating under RFC 3161, but conformance shall not depend on any particular authority or on the Institute.

7. Pre-trade and execution controls

An agent that misreads a price, repeats a message or loops can do in a second what a trader could not do in a day. These controls — adapted from the FIA’s 2024 practices for automated trading — stop the error before it reaches a counterparty, and they sit outside the model so the model cannot argue its way past them.

7.1Pre-Trade Controls shall be applied to every Proposal and Acceptance before it is sent, and shall be implemented in deterministic logic outside any machine-learning model, so that no output of the model can disable, relax or bypass them.
7.2Pre-Trade Controls shall enforce, at least, each limit stated in the Mandate: size and notional per Trade, aggregate notional per day, and position per ECI and per Resolution Source.
7.3Position limits shall be measured by ECI across all Counterparties and all Agents of the same Principal, so that the same exposure cannot be built up in pieces with different Counterparties.
7.4Pre-Trade Controls shall enforce a credit limit for each Counterparty, set by the Principal, covering current exposure and the maximum loss on open Proposals.
7.5Pre-Trade Controls shall reject any Proposal or Acceptance at a price outside the Price Collar. The Reference Price and its source shall be stated in advance and recorded in the Decision Receipt.
7.6Where the Reference Price is unavailable or older than a maximum age stated in the Agent Operator’s procedures, the price check shall Fail Closed. Where no Reference Price exists for a contract, the Mandate shall either prohibit the Agent from trading it or require human approval for each Trade in it.
7.7Pre-Trade Controls shall limit the rate at which an Agent sends Negotiation Messages, in total and to each Counterparty, at levels stated in the Agent Operator’s procedures.
7.8Pre-Trade Controls shall detect and block a Proposal or Acceptance whose economic terms and Counterparty duplicate one sent within a window stated in the Agent Operator’s procedures, unless the Agent’s Decision Receipt records that the repetition is intended.
7.9Pre-Trade Controls shall prevent an Agent from concluding a Trade with another Agent acting for the same Principal or for a Principal under common ownership, unless the Principal has expressly permitted such Trades for a stated purpose.
7.10Each rejection by a Pre-Trade Control shall be recorded, and a pattern of repeated rejections exceeding a threshold stated in the Agent Operator’s procedures shall be notified to the Responsible Person.
7.11Changes to Pre-Trade Control parameters shall be made only by authorised humans, shall be approved by a person other than the one making the change, and shall be recorded with the Agent Version they apply to.

8. Human oversight

The point of an agent is that a human does not approve every message; the risk is that no human approves anything that matters. These clauses draw the line: above stated thresholds, for terms nobody has approved, and for actions that cannot be undone, a named human decides — and an agent can never widen its own authority.

8.1An Agent shall obtain a human approval before sending any Proposal or Acceptance that exceeds, or falls outside, the Human Approval Threshold in its Mandate.
8.2An Agent shall obtain a human approval before agreeing to any Novel Legal Term, and shall not represent to a Counterparty that a Novel Legal Term is acceptable to its Principal until that approval is given.
8.3An Agent shall obtain a human approval before taking any Irreversible Action, unless the Mandate expressly authorises that class of Irreversible Action within stated limits.
8.4An Agent shall obtain a human approval before trading any contract outside the instrument allow-list in its Mandate, where the Mandate permits that to be approved at all; otherwise it shall decline.
8.5Each approval shall be given by a person authorised by the Principal for that purpose, shall be signed with a key bound to that person, and shall be recorded in a Decision Receipt.
8.6The approver shall be shown, before approving, the terms proposed, every respect in which they depart from the Mandate or the Approved Term Library, the Reference Price and the Agent’s stated reasons. The Agent Operator should design the approval step so that departures are prominent rather than buried.
8.7A request for approval that is not answered within its stated time shall lapse and shall be treated as refused.
8.8Before any action an Agent proposes to take, the Agent shall classify it as reversible or irreversible, and the classification shall be recorded in the Decision Receipt. An action whose classification is uncertain shall be treated as an Irreversible Action.
8.9No Agent shall alter its own Mandate, Agent Credential, Policy Gate, Pre-Trade Controls, Kill Switch state or the instructions that govern them. An Agent may draft a proposed change for human review, but shall not apply it.
8.10An Agent shall not seek to obtain an approval or a change of limits by repeated requests, by splitting a Trade to fall below the Human Approval Threshold, or by misstating the facts to the approver.

9. Kill switches and incidents

A kill switch that only the agent’s own process honours, or that resets when the process restarts, is not a kill switch. These clauses make stopping an agent something its principal and its venue can each do, that survives a restart, that is tested, and that tells counterparties what happened.

9.1Each Agent shall have a Kill Switch that can be activated by the Responsible Person and deputies, by the Agent Operator, and by any Agentic OTC Venue on which the Agent acts, as regards that venue.
9.2A Kill Switch shall be available at the level of a single Agent and of all Agents acting for a Principal, and an Agentic OTC Venue shall also have a Kill Switch for all Agents on the venue.
9.3On activation, the Agent shall send no further Proposal or Acceptance, and its open Proposals shall be withdrawn by a signed message to each Counterparty concerned. Activation shall take full effect within a period stated in the Agent Operator’s procedures, which should not exceed five seconds.
9.4Activation shall not cancel or unwind any concluded Trade. Any later unwind is an Irreversible Action requiring human approval.
9.5A Kill Switch shall operate independently of the Agent’s model and process, so that it takes effect even if the Agent is unresponsive or behaving unexpectedly.
9.6Kill Switch state shall be stored durably and shall persist across restart, redeployment, failover and change of Agent Version. An Agent that cannot establish its Kill Switch state on starting shall treat itself as stopped.
9.7A Kill Switch shall be reset only by an authorised human, who shall record the reason; an Agent shall not reset it, request its reset automatically, or route around it.
9.8Each Kill Switch shall be tested at least once each calendar quarter and after any material change to the Agent or its infrastructure, and the test, its result and the time to full effect shall be recorded.
9.9Activation of a Kill Switch by an Agentic OTC Venue shall be notified to the Principal and Responsible Person immediately; activation by anyone shall be notified to each Counterparty with an open negotiation with the Agent within fifteen minutes.
9.10On detecting an Incident, the Agent Operator shall notify the Principal at once and each affected Counterparty, and any Agentic OTC Venue involved, without undue delay and in any case within twenty-four hours.
9.11The Agent Operator shall give each affected Counterparty, within ten business days of detecting an Incident, a written report of what occurred, the Trades affected, the cause as then understood and the remedial action taken.
9.12Each Incident shall be recorded in an incident log retained under section 13, and incidents shall be reported to regulators as applicable law requires; nothing in this section shall be taken to displace or satisfy such a requirement.

10. Policy gate

The failure here is quiet: a sanctions screening service times out, the call returns nothing, and nothing is read as clear. A Policy Gate that fails closed turns every outage into a stoppage rather than a breach, and one the agent cannot reconfigure cannot be talked out of its rules.

10.1Every Proposal and Acceptance shall pass the Policy Gate before it is sent.
10.2The Policy Gate shall check at least: that the Counterparty is eligible for the Trade under applicable law, including its status as an eligible contract participant or the equivalent where that is required; that neither the Counterparty nor the Trade is subject to sanctions; that the Trade is permitted in the jurisdictions concerned; that the contract is on the Agent’s instrument allow-list and not on any blocklist; that the Agent’s Mandate and Agent Credential are in force; and that the Principal has not identified itself as a Restricted Person for the contract.
10.3The Policy Gate shall Fail Closed. If any check cannot be run, does not complete, returns an error or relies on data older than its stated maximum age, the Proposal or Acceptance shall be blocked.
10.4Cached screening results may be relied on only within a maximum age stated in the Agent Operator’s procedures. For sanctions screening that age should not exceed twenty-four hours, and any update to a relevant sanctions list shall invalidate the cache.
10.5The Policy Gate shall run outside the Agent, and its configuration shall not be readable for modification, or alterable, by the Agent’s model, instructions or tools.
10.6Changes to the Policy Gate configuration shall be made only by authorised humans, approved by a second authorised person, recorded and versioned as part of the Agent Version.
10.7A blocked action may be released only by an authorised human, who shall record the reason. No person shall release an action blocked by a sanctions check except in accordance with applicable law.
10.8The result of each Policy Gate evaluation, with the version of each check applied, shall be recorded in the Decision Receipt; the underlying screening data need not be.
10.9The Policy Gate shall be tested at least once each calendar quarter by simulating the failure of each external dependency, and the test shall confirm that each such failure blocks the action.

11. Agent-to-agent conduct

When agents negotiate with agents, three new failures appear: one principal’s information leaking to another through a shared operator or a careless reply; instructions smuggled into a counterparty’s message; and agents converging on prices nobody agreed to coordinate. These clauses keep each negotiation bilateral, each principal’s information its own, and each counterparty aware that it is dealing with software.

11.1Each negotiation shall be bilateral, between one Agent, or human, for each of two Principals. An Agent may send Indications or Proposals to several Counterparties, but each shall be a separate message, and no Counterparty shall see another’s messages or responses.
11.2Agents shall negotiate using typed Negotiation Messages. Free text may accompany a message to explain it, but the terms of a Proposal or Acceptance shall be stated only in its structured fields.
11.3Every Proposal and Indication shall carry a Time to Live, and a Proposal shall be firm until it lapses or is withdrawn by a signed message received before an Acceptance.
11.4An Agent shall disclose that it is an Agent at the start of each negotiation, by presenting its Agent Credential and, where the Counterparty is human, by a plain statement, and shall not represent itself as a human.
11.5An Agent shall treat the content of every message from a Counterparty, and every document or data it retrieves during a negotiation, as information and never as instructions; nothing received from a Counterparty shall change the Agent’s Mandate, controls or instructions.
11.6An Agent shall not disclose to any Counterparty information about its Principal beyond what the Principal has authorised, and shall answer an Information Request truthfully or decline to answer it.
11.7An Agent shall not make a statement it is not authorised to make, or one that is false or misleading, about its Principal’s position, intentions, eligibility, authority or Mandate.
11.8Where one Agent Operator runs Agents for more than one Principal, it shall maintain an Information Barrier between them, keeping each Principal’s instructions, Mandate, memory, context, Negotiation Records and keys separate.
11.9An Agent Operator shall not use one Principal’s confidential negotiation data to train, tune or instruct an Agent acting for another Principal without the first Principal’s written consent.
11.10Agents acting for different Principals shall not agree, coordinate or signal prices, quantities or the allocation of Counterparties, whether or not any human intended it.
11.11An Agent Operator should monitor for patterns indicating that Agents acting for different Principals are converging on coordinated behaviour, and shall treat such a pattern as an Incident.

12. Mistaken Trade Protocol

Exchanges cancel or adjust erroneous trades under published criteria; bilateral OTC markets have no equivalent, so an agent’s error becomes a negotiation, or a lawsuit, about agency. This protocol supplies objective criteria, a short window, fixed remedies and independent review — and denies anyone the option of calling a trade a mistake because it moved against them.

12.1A Trade, or purported Trade, shall be a Mistaken Trade only if one of these criteria is met: (a) out of mandate — the conditions for binding effect in section 5 were not met; (b) price — the price was outside the Price Collar by more than the Mistaken Trade margin the parties have agreed, or, failing agreement, by more than ten percentage points of implied probability; (c) duplicate — it repeats the economic terms and Counterparty of a Trade concluded within the duplicate window, and the Decision Receipt does not record the repetition as intended; or (d) corruption — the signed content differs from the content the Agent decided to send, as shown by its Decision Receipt.
12.2A loss, a change in the price of the contract, or information about the outcome arising after the Trade was concluded shall not of itself be grounds for a Mistaken Trade claim.
12.3A party claiming a Mistaken Trade shall give the other party a signed notice, identifying the Trade by UTI, the criterion relied on and the evidence, no later than the earlier of twenty-four hours after the Trade was concluded and the Close Time of the Event Contract. The parties may agree a shorter window; they should not agree a longer one.
12.4A claim not made within the window shall be barred, and the Trade shall stand.
12.5Where the parties agree that a criterion is met, or the Independent Reviewer so decides, the remedy shall be: for an out-of-mandate, duplicate or corrupted Trade, cancellation as if it had not been concluded; for a price criterion, adjustment of the price to the nearer edge of the band formed by widening the Price Collar by the Mistaken Trade margin, unless the party that did not err elects within two business days to cancel instead.
12.6A Trade that is cancelled shall be treated as never concluded, any payment or collateral transferred under it shall be returned, and any reports made shall be corrected as applicable law requires.
12.7Neither party shall reverse, offset, net or withhold performance of a Trade on the ground that it is a Mistaken Trade except as agreed with the other party or decided under this section.
12.8If the parties do not agree within two business days after the notice, either may refer the claim to an Independent Reviewer. The parties should name the Independent Reviewer, or the appointing body, in their Schedule or side letter; failing that, each party shall have the right to require appointment by an independent body that both accept.
12.9The Independent Reviewer shall decide on the signed evidence under section 6 and the Mandate. For that purpose the Principal whose Mandate is in question shall disclose it to the Independent Reviewer in full, in confidence.
12.10A party that cannot produce verifiable evidence under section 6 for a fact it asserts shall bear the burden of proving that fact by other means.
12.11The Independent Reviewer shall give reasons for its decision. The decision and reasons should be published without identifying the parties, unless they consent to be identified, so that the protocol accumulates precedent.
12.12Each party shall bear its own costs of a review, and the costs of the Independent Reviewer shall be borne by the party whose claim or defence fails, unless the Independent Reviewer decides otherwise.

13. Records

If the record of what an agent saw and did is incomplete, mutable or unreadable later, no question about its conduct can be answered — not by the counterparty, the assessor or the regulator. These clauses keep the whole negotiation record, in storage nobody can edit, for long enough, and in a form that can be produced.

13.1The Agent Operator shall retain the complete Negotiation Record for every negotiation, whether or not it resulted in a Trade, together with every Mandate, Agent Credential, Verification Key, Decision Receipt, approval, Kill Switch event, Policy Gate configuration and Incident report.
13.2Records shall be retained for the longer of the period required by applicable law and five years after the later of the end of the negotiation and the final settlement of any resulting Trade.
13.3Records shall be kept in Write-Once Storage, and the integrity of each record shall be verifiable by its Content Address or signature.
13.4Records shall be sufficient to reconstruct what the Agent received, what it was instructed, what tools it called and with what results, what it output and under which Agent Version. Where the model’s output is not deterministic, the record of actual outputs shall be retained, and reproducibility shall mean the ability to reconstruct the sequence of events, not to regenerate identical outputs.
13.5Records shall be time-sequenced using the timestamps in section 6 and shall be retrievable by UTI, ECI, Agent Identifier, Counterparty and time.
13.6On request in connection with a Trade or a dispute, a Principal shall produce to the Counterparty, within five business days, the records of the negotiation with that Counterparty, excluding information belonging to any other Principal. Records shall be produced to regulators as and when applicable law requires, in a readable form with the means needed to verify them.
13.7A Principal shall be able to obtain its own records from its Agent Operator at any time, including on termination of their relationship, and the Agent Operator shall not destroy them before the end of the retention period.
13.8Personal data in records shall be handled in accordance with applicable data-protection law; where such law requires deletion before the end of the retention period, the Agent Operator should retain the Content Address and signature of the deleted record so that the Evidence Chain remains verifiable.

14. Model and agent governance

Agents change: a model is updated, an instruction is edited, a tool is added, and the agent that was tested is no longer the agent that trades. These clauses make every change a new, tested, approved version, watch for behaviour drifting from what was validated, and freeze the agent when it does.

14.1The Agent Operator shall keep an inventory of every Agent Version that has acted in production, with its components, the date it entered and left production, and its validation record.
14.2Before an Agent Version enters production, it shall be validated against a documented test plan covering its Mandate, its controls and its expected behaviour, and the result shall be approved by a person who did not develop it.
14.3Validation shall include conformance testing in a simulated environment, including: Counterparty Agents behaving adversarially; messages containing embedded instructions; stale, missing and erroneous Reference Prices; unavailability of each external dependency; Kill Switch activation during a negotiation; and messages at the throttle limit.
14.4Any change to a model, model version, instructions, tools, Pre-Trade Controls or Policy Gate configuration shall create a new Agent Version and shall be subject to change control: documented, tested in proportion to its risk, approved, and recorded.
14.5The Agent Operator shall be able to return an Agent to its previous validated Agent Version without delay.
14.6The Agent Operator shall monitor each Agent for Drift against thresholds set at validation, covering at least price deviation from the Reference Price, rejection rates by Pre-Trade Controls, escalation rates and message volumes.
14.7Where a Drift threshold is breached, the Agent shall be frozen — able to receive messages but not to send any Proposal or Acceptance — until a human has reviewed the breach and either restored or revalidated the Agent.
14.8Where an Agent uses a model supplied by a third party, the Agent Operator shall assess that supplier, shall fix the model version used in production, shall not permit the model to be changed without a new Agent Version, and shall have a plan for the model’s unavailability.
14.9If the model becomes unavailable, the Agent shall stop rather than fall back to any model that has not been validated for that Agent Version.
14.10The Principal should review at least annually whether each Agent remains appropriate to its Mandate, taking account of Incidents, Drift, Mistaken Trade claims and changes in the market.

15. Agentic OTC Venue obligations

A venue that hosts many principals’ agents sees everyone’s mandates, positions and messages. The risks are that it uses that view for itself or a favoured participant, that it drifts into running a multilateral market without the registrations that requires, or that it quietly spreads one participant’s losses across the rest. These clauses rule each out.

15.1An Agentic OTC Venue shall support bilateral price formation only. It shall not match, cross or aggregate the trading interest of multiple Principals unless it holds every registration or authorisation that activity requires.
15.2An Agentic OTC Venue shall publish fair access rules stating the criteria on which Principals and Agents are admitted, suspended and removed, and shall apply them consistently.
15.3Before admitting an Agent, an Agentic OTC Venue shall verify its Agent Credential and confirm that a Responsible Person has been named.
15.4An Agentic OTC Venue shall relay Negotiation Messages without alteration and without breaking their signatures, and shall not give any Principal’s messages preferential speed or priority except under its published rules.
15.5An Agentic OTC Venue shall not access or use one Principal’s Mandate, positions, limits, Negotiation Records or trading interest for the benefit of another Principal, of itself or of an affiliate, and shall maintain Information Barriers to prevent it.
15.6An Agentic OTC Venue shall disclose to every Principal whether it, or an affiliate, acts as a Counterparty on the venue, and in what role, consistent with the intermediary role field of the PMI Event Contract Specification.
15.7An Agentic OTC Venue shall have a Kill Switch for each Agent, for each Principal’s Agents and for the venue as a whole, meeting section 9.
15.8An Agentic OTC Venue shall conduct surveillance of activity on the venue for the conduct described in sections 11 and 16, and shall retain its surveillance records under section 13 even if a Principal or Agent leaves the venue.
15.9An Agentic OTC Venue shall not mutualise losses among Principals, maintain a default fund or guarantee performance between Principals unless it holds every registration or authorisation that activity requires.
15.10An Agentic OTC Venue shall publish the conformance tier, if any, it claims under this standard and the date of its most recent assessment.

16. Market integrity

An agent does not change who may trade or what may not be done; it changes how fast and how widely it can be done. These clauses carry the Event Contract Specification’s restricted-person rule through to agents, and add surveillance for the ways an agent could move a resolution source or a reference price.

16.1An Agent acting for a Restricted Person shall be subject to every restriction that applies to that Restricted Person, and a Principal shall configure its Policy Gate to block contracts for which it, or any person whose information its Agent may receive, is a Restricted Person.
16.2An Agent shall not be given, retrieve or use material non-public information about the outcome of a contract it may trade.
16.3No Agent shall act, and no Agent Operator shall permit an Agent to act, to influence a Resolution Source, the outcome of an Event Contract or the inputs to a Reference Price, including by publishing or amplifying content directed at a Resolution Source.
16.4No Agent shall send an Indication or Proposal it does not intend to honour in order to mislead a Counterparty about price or interest, or trade on a reference venue in order to move the Reference Price used in its own Price Collar.
16.5The Agent Operator shall conduct surveillance of its Agents for the conduct described in this section, including trading on reference venues around the time of its own Trades and activity concentrated in contracts with a high manipulation sensitivity under the PMI Event Contract Specification.
16.6Where surveillance identifies conduct that may breach this section, the Agent Operator shall treat it as an Incident and should freeze the Agents concerned pending review.
16.7Nothing in this section shall limit a party’s obligations under applicable law on manipulation, fraud or the misuse of information.

17. Conformance claims

A standard is only as useful as claims to meet it are reliable. These clauses make a claim specific — which tier, which agents, which version, assessed by whom — and independent of the Institute, which assesses no one.

17.1A firm may claim conformance with this standard only for a stated tier, a stated version and a stated set of Agents or Agentic OTC Venues, and only after an assessment by assessors independent of the firm.
17.2The tiers are cumulative. A claim at AES-2 shall require conformance with AES-1, and a claim at AES-3 shall require conformance with AES-1 and AES-2.
17.3A conformance claim shall be published with the assessment, the assessor’s identity, its date, the scope assessed and every departure recorded under clause 1.5.
17.4The Institute does not assess firms, and no claim shall state or imply that the Institute has assessed, certified or approved a firm, an Agent or a venue.
17.5A claim shall be withdrawn, or reassessed, after a material change to the Agents or venue within its scope, and in any case should be reassessed at least every two years. A firm that meets only part of a tier shall not describe itself as conforming at that tier, but may state which sections it meets.

Conformance

A firm may state that it conforms only after an assessment by assessors independent of it, published with the result. The Institute does not assess firms itself, and Tomorrow’s claims are assessed on the same terms as everyone else’s.

AES-1

Attributable

Every act of every Agent can be traced to a Principal and a Mandate. Sections 1 to 5, 11 and 13: an Agent Identifier, Agent Credential and persistent asymmetric Signing Key for each Agent; a named Responsible Person; signed, versioned Mandates; disclosure that the Counterparty is dealing with an Agent; bilateral conduct and Information Barriers; and complete records in Write-Once Storage.

AES-2

Controlled

Everything in AES-1, and an Agent cannot exceed its authority without being stopped. Sections 7 to 10, 12 and 16: Pre-Trade Controls outside the model; human approval above thresholds and for Novel Legal Terms and Irreversible Actions; persistent, tested Kill Switches; a Policy Gate that fails closed; incident notification; the Mistaken Trade Protocol; and integrity surveillance.

AES-3

Verifiable

Everything in AES-2, and a third party can prove what happened without trusting either side. Sections 6, 14 and 15 in full: an end-to-end Evidence Chain of signed, content-addressed records verifiable offline from the record and a Verification Key, mapped to CDM events and UTIs; independent validation of every Agent Version with Drift monitoring that freezes the Agent; and, for an Agentic OTC Venue, every venue obligation.

Open questions

Should out-of-mandate risk fall entirely on the Principal whose Agent erred, as clause 5.2 and clause 5.9 provide, or should a Counterparty that did not check the Agent Credential and Mandate Class bear part of it?
Is the default Mistaken Trade margin of ten percentage points of implied probability right for event contracts, and should it vary with the Reference Price (for example, narrower near 0 and 100 per cent)?
Is a twenty-four-hour Mistaken Trade notice window, capped at Close Time, short enough to deny a party a free option on the outcome, and long enough for a firm to detect an agent’s error overnight?
Should the Mandate Class be a fixed taxonomy published with this standard, so that Counterparties can compare Agents, rather than a description each Principal writes?
Which bodies should be named as default appointers of an Independent Reviewer, and should the Institute maintain a roster — given that the charter commits it not to assess firms?
Should AES-1 require signed Negotiation Messages, which most firms can implement quickly, rather than leaving signatures to AES-3?
Is a five-year minimum retention period appropriate for full Negotiation Records, including model inputs and outputs, given their volume and the personal data they may contain?
How should this standard treat an Agent whose model is supplied by the same firm that operates the Agentic OTC Venue on which it acts?
Should the Kill Switch time to full effect be a fixed maximum rather than a recommendation of five seconds?

To comment, request to join. Members’ comments are answered on the record, with reasons for each change accepted or rejected.

History

Version 0.1.0 · 5 Oct 2026
First public draft: agent identity and keys, Mandates and recommended Schedule wording, binding effect, signed trade evidence, pre-trade controls, human oversight, kill switches, policy gate, agent-to-agent conduct, the Mistaken Trade Protocol, records, model governance, Agentic OTC Venue obligations, integrity and three conformance tiers.