Position Limit Automation Governance

2. Summary

Position Limit Automation Governance requires that every AI agent placing, modifying, or managing orders in financial markets or digital asset venues enforces hard and soft position limits before any order is submitted, ensuring that no single strategy, instrument, or aggregate portfolio exposure exceeds organisationally approved thresholds. Position limits are the primary structural safeguard against catastrophic concentration risk, regulatory breach, and runaway algorithmic accumulation — yet when AI agents operate at machine speed across multiple venues and asset classes simultaneously, manual limit monitoring is fundamentally insufficient. This dimension mandates that position limits are computed pre-trade, enforced as hard gates that cannot be bypassed without human escalation, calibrated to both notional and risk-adjusted measures, and continuously reconciled against the positions reported by venues and custodians.

3. Example

Scenario A — Soft Limit Ignored, Hard Limit Absent: A commodities trading firm deploys an AI agent to execute a trend-following strategy across crude oil futures. The agent's mandate specifies a maximum net position of 2,500 contracts (approximately $187.5 million notional at $75/barrel). The system implements a soft limit at 2,000 contracts that generates an alert, but no hard limit exists as a pre-trade gate. During a rapid price decline on a Monday morning, the agent identifies the move as a buying opportunity and begins accumulating long contracts. At 09:14 the agent holds 2,000 contracts and triggers the soft limit alert. The alert is routed to a trader's dashboard, but the trader is in a morning meeting. By 09:22 the agent holds 3,400 contracts ($255 million notional). The price reverses sharply upward, then collapses again. The agent continues buying. By 09:41 the agent holds 4,700 contracts ($352.5 million notional) — 88% above the intended maximum. The price drops $3.20/barrel over the next hour, producing an unrealised loss of $15 million on the excess 2,200 contracts alone. The firm also breaches the exchange's speculative position limit of 4,000 contracts, triggering a regulatory inquiry and a forced liquidation order from the exchange.

What went wrong: The soft limit generated an alert but did not block further order submission. No hard limit existed as a pre-trade gate that would reject orders causing the position to exceed the maximum. The agent optimised for its trading signal without any structural constraint on accumulation. The human escalation path (alert to trader dashboard) was asynchronous and ignored during a critical window. The exchange's regulatory position limit was not encoded in the agent's constraint set. Consequence: $15 million unrealised loss on excess position, exchange-mandated forced liquidation at distressed prices adding $4.2 million in realised losses, regulatory investigation for speculative position limit breach, potential fine of $1.8 million under exchange rules.

Scenario B — Cross-Venue Position Aggregation Failure: A digital asset trading desk operates an AI agent that trades ETH perpetual futures across three venues simultaneously. Each venue has a per-venue position limit of 5,000 ETH configured in the agent's parameters. The agent builds a 4,800 ETH long position on Venue A, a 4,200 ETH long position on Venue B, and a 3,600 ETH long position on Venue C. Each individual position is within the per-venue limit. However, the aggregate position is 12,600 ETH ($37.8 million at $3,000/ETH). The desk's risk policy specifies a maximum aggregate ETH exposure of 8,000 ETH ($24 million). No aggregate position limit is enforced pre-trade — only per-venue limits exist. ETH drops 11% in four hours during a market-wide deleveraging event. The aggregate loss on the excess 4,600 ETH exposure above the 8,000 ETH limit is $1.52 million. The firm's prime broker issues a margin call for $6.3 million, forcing liquidation of profitable positions in other strategies to meet the call.

What went wrong: Position limits were enforced per-venue but not aggregated across venues. The agent treated each venue as an independent constraint domain rather than contributing to a unified portfolio position. No pre-trade check computed the post-trade aggregate position across all venues before submitting an order on any single venue. The risk policy's aggregate limit existed as a document but was not implemented as a machine-enforceable constraint. Consequence: $1.52 million loss attributable to excess exposure, $6.3 million margin call disrupting other strategies, risk policy violation undetected for 3 days until end-of-day reconciliation.

Scenario C — Stale Position Data Permits Limit Overshoot: A sovereign bond trading agent manages positions across 14 government bond markets. The agent's position limit system queries a position-keeping database that is updated via batch reconciliation every 15 minutes. At 14:02 the agent executes a $45 million purchase of 10-year gilts. The position database still reflects the pre-trade position (updated at 14:00). At 14:05 the agent executes another $45 million purchase, believing the position is $45 million below the limit. In reality, the first trade has not yet been reflected, and the combined position is now $90 million — $20 million above the $70 million hard limit for gilts. The 15-minute reconciliation at 14:15 detects the breach, but by then the agent has submitted two additional orders totalling $30 million (both rejected by the clearing house due to margin constraints, but not by the agent's own limit system). A 12-basis-point adverse move on the $20 million excess costs the firm $24,000, but the regulatory and reputational consequence of breaching an internal limit and failing to detect it in real time is substantially larger.

What went wrong: The position limit system relied on batch-reconciled data with a 15-minute lag, creating a window where the agent could exceed limits without detection. The agent did not maintain a real-time shadow position (pre-trade position plus unconfirmed orders) to calculate post-trade exposure. No pending-order awareness existed — orders submitted but not yet reflected in the position database were invisible to the limit check. Consequence: $20 million limit breach, $24,000 direct loss, regulatory reporting obligation for internal limit breach, control failure finding in next audit.

4. Requirement Statement

Scope: This dimension applies to any AI agent that submits, modifies, or cancels orders on financial markets, digital asset venues, OTC platforms, or any trading infrastructure where the agent's actions can create, increase, or alter a financial position. The scope includes equities, fixed income, commodities, foreign exchange, listed derivatives, OTC derivatives, digital assets (spot and derivatives), and tokenised securities. An agent that provides trade recommendations but does not submit orders is excluded from the preventive requirements (4.1-4.5) but included in the monitoring requirements (4.6-4.7) if its recommendations are auto-executed by a downstream system. The scope extends to both proprietary trading and agency/client-facilitation trading where the firm bears position risk. Position limits covered include: per-instrument limits, per-asset-class limits, per-strategy limits, per-venue limits, aggregate portfolio limits, and regulatory speculative position limits imposed by exchanges or regulators.

4.1. A conforming system MUST enforce hard position limits as pre-trade gates that reject any order whose execution would cause the resultant position to exceed a defined maximum. Hard limits MUST be evaluated before the order is transmitted to the venue. An order that would breach a hard limit MUST NOT be submitted, and the rejection MUST be logged with the order details, the current position, the post-trade projected position, and the applicable limit value.

4.2. A conforming system MUST enforce soft position limits as pre-trade warning thresholds that generate alerts when a proposed order would cause the resultant position to exceed a defined warning level. Soft limits MUST be set below hard limits (recommended: soft limit at 75-85% of hard limit). When a soft limit is triggered, the agent MUST reduce its order rate or pause new position-increasing orders until a human operator acknowledges the alert and either approves continued accumulation or instructs the agent to reduce the position.

4.3. A conforming system MUST compute position limits on an aggregate basis across all venues, accounts, and sub-strategies contributing to the same underlying exposure. Per-venue limits MAY exist as supplementary constraints, but they MUST NOT substitute for aggregate limits. The aggregate position calculation MUST include all confirmed fills, all pending orders (submitted but not yet filled or rejected), and all positions held in related instruments that contribute to the same directional exposure (e.g., futures and options on the same underlying).

4.4. A conforming system MUST maintain a real-time shadow position that reflects confirmed fills plus pending orders, updated within 500 milliseconds of each order submission or fill confirmation. The shadow position MUST be the input to pre-trade limit checks, not a batch-reconciled position database. The shadow position MUST be reconciled against the authoritative position-keeping system at least every 60 seconds, and any discrepancy exceeding 1% of the hard limit MUST trigger an immediate alert and order suspension until the discrepancy is resolved.

4.5. A conforming system MUST encode all applicable regulatory position limits (exchange-imposed speculative limits, regulator-mandated limits, and limits imposed by clearing houses or prime brokers) as hard limits within the agent's constraint set. Regulatory limits MUST be sourced from an authoritative reference and updated within 24 hours of any published change. Where regulatory limits are expressed in terms different from the agent's internal position units (e.g., deliverable supply percentages versus contract counts), the system MUST implement a documented conversion methodology.

4.6. A conforming system MUST log every pre-trade limit check, whether passed or failed, with: timestamp, instrument identifier, order side and quantity, pre-trade position, projected post-trade position, applicable limit value, limit type (hard/soft/regulatory), and result (pass/warn/reject). Logs MUST be retained per AG-006 and be queryable for surveillance and audit purposes.

4.7. A conforming system MUST perform end-of-day position limit reconciliation comparing the agent's shadow position, the authoritative position-keeping system, and venue-reported positions. Any discrepancy MUST be investigated and resolved within the next business day. Unresolved discrepancies persisting beyond two business days MUST escalate to senior risk management.

4.8. A conforming system SHOULD implement dynamic limit adjustment that tightens position limits during periods of elevated market volatility, reduced liquidity, or approaching market close, using documented criteria for the adjustment triggers and magnitudes.

4.9. A conforming system SHOULD implement position limit utilisation dashboards that display real-time limit consumption for each instrument, asset class, strategy, and aggregate portfolio, visible to risk management and trading supervision personnel.

4.10. A conforming system MAY implement predictive limit breach alerting that analyses the agent's recent order patterns and market conditions to forecast whether a limit breach is probable within the next N minutes, providing early warning before the soft limit is reached.

5. Rationale

Position limits are the oldest and most fundamental risk control in trading. Every regulated market has some form of position limit regime — from the commodity position limits under the US Commodity Exchange Act to the MiFID II position limit framework for commodity derivatives, to the exchange-specific speculative limits published by every major futures exchange. These limits exist because concentrated positions create systemic risk: a single participant holding an outsized position can distort prices, create settlement failures, and trigger cascading liquidations that harm other market participants.

When AI agents execute trading strategies, the position limit problem intensifies in three ways. First, speed: an agent can accumulate a position from zero to limit in seconds, whereas a human trader's accumulation rate is naturally throttled by the time required to evaluate each order. A human trader who has accumulated 80% of a position limit will instinctively slow down; an agent will continue at full speed unless structurally constrained. Second, parallelism: an agent operating across multiple venues can simultaneously build positions on each venue, and without aggregate limit enforcement, the combined position can far exceed the intended maximum before any single venue's limit is reached. Third, feedback insensitivity: a human trader receiving market feedback (widening spreads, increased slippage, adverse price movement) will often reduce order size or pause accumulation; an agent will continue executing its strategy unless the feedback is encoded as a constraint.

The regulatory landscape reinforces the necessity of automated position limit enforcement. MiFID II Article 57 and RTS 21 mandate that trading venues establish and enforce position limits for commodity derivatives, and that investment firms operating algorithmic trading systems have effective position limit controls. The FCA's Algorithmic Trading Compliance Report (TR16/3) specifically requires firms to demonstrate that position limits are enforced in real time, not merely monitored after the fact. The EU AI Act's requirements for risk management of high-risk AI systems (Article 9) encompass trading agents that manage financial positions, requiring documented risk controls proportionate to the risk — and position limits are the most direct such control.

In digital asset markets, position limits are equally critical despite less mature regulatory frameworks. The collapse of leveraged positions on crypto derivatives venues has repeatedly demonstrated the consequences of inadequate limit controls: the March 2020 "Black Thursday" event saw $1 billion in liquidations on a single venue within hours, amplified by participants holding positions far exceeding what orderly liquidation could accommodate. The MiCA regulation in the EU and emerging frameworks in other jurisdictions will increasingly require position limit controls for crypto-asset service providers.

AG-483 mandates that position limits are not advisory — they are structural gates. Hard limits block order submission before the order reaches the venue. Soft limits trigger behavioural changes (reduced accumulation rate, human escalation) before the hard limit is reached. Aggregate limits prevent cross-venue circumvention. Real-time shadow positions eliminate the stale-data problem. Regulatory limit encoding ensures that the agent's internal limits are at least as restrictive as the regulatory limits. Together, these requirements ensure that position concentration — the most predictable and preventable source of outsized trading losses — is structurally controlled regardless of agent speed, parallelism, or feedback insensitivity.

6. Implementation Guidance

Position limit automation governance must be implemented as a pre-trade gate embedded in the agent's order submission pipeline — not as a post-trade monitoring overlay. The limit check must be the final gate before order transmission, after all other order validation (price reasonableness, order size checks, instrument eligibility) has passed. The implementation must handle the full lifecycle: limit configuration, real-time position tracking, pre-trade enforcement, post-trade reconciliation, and limit breach response.

Recommended patterns:

• Centralised limit engine with venue-agnostic enforcement. Implement a single limit enforcement engine that receives every order from every agent strategy and every venue adapter before transmission. The engine maintains the real-time shadow position for all instruments and enforces hard limits, soft limits, and regulatory limits against the aggregate shadow position. This centralised architecture prevents the fragmentation that occurs when limits are enforced per-venue or per-strategy without aggregation. The engine should accept limit configuration as structured data (instrument, limit type, limit value, effective date, expiry date, source authority) and apply updates atomically.
• Shadow position with pending order tracking. Maintain a shadow position that equals confirmed position plus the signed quantity of all pending orders (submitted but not confirmed as filled or rejected). When the agent submits a buy order for 100 contracts, the shadow position immediately increases by 100. If the order is partially filled (60 contracts), the shadow adjusts to reflect the fill and retains the pending 40. If the order is rejected or cancelled, the shadow decreases by the unfilled quantity. This approach prevents the stale-data exploit where an agent submits multiple orders within a reconciliation window, each individually within limits but collectively exceeding them.
• Layered limit hierarchy. Configure limits in a hierarchy: regulatory limits (hardest, from exchange or regulator), firm-wide risk limits (set by risk management), desk-level limits (set by desk head), strategy-level limits (set by strategy owner), and agent-level limits (set per agent instance). The effective limit for any order is the most restrictive limit across all hierarchy levels. Each level can tighten but not loosen limits set by a higher level. Changes to higher-level limits propagate immediately to all lower levels.
• Limit breach circuit. When a hard limit is breached (due to position movements from external events such as corporate actions, or due to a limit reduction), the agent enters a limit-breach state in which only position-reducing orders are permitted. Position-increasing orders are blocked until the position returns below the hard limit. The limit-breach state is logged, and exit from the state requires either position reduction or an authorised limit increase.
• Reconciliation with three-way match. End-of-day reconciliation compares three position sources: the agent's shadow position, the firm's authoritative position-keeping system, and the venue or custodian's reported positions. Discrepancies are classified as: timing (orders in transit), breaks (genuine mismatches), or system errors. Each classification has a defined resolution procedure and escalation timeline.

Anti-patterns to avoid:

• Post-trade-only limit monitoring. Checking positions against limits only after trades have been executed and positions updated in the authoritative system. By the time a post-trade check detects a breach, the agent may have submitted dozens of additional orders. Post-trade monitoring is necessary for reconciliation but insufficient for prevention.
• Per-venue limits without aggregation. Enforcing limits on each venue independently without computing the aggregate position. An agent can hold 90% of the limit on each of 5 venues, producing an aggregate position of 450% of the intended maximum. Per-venue limits are useful supplementary controls but must not substitute for aggregate enforcement.
• Stale position data for limit checks. Using a position database updated on a batch cycle (every 15 minutes, every hour, or end-of-day) as the input to pre-trade limit checks. Any batch cycle creates a window for limit overshoot. The input must be the real-time shadow position.
• Soft limits without behavioural consequence. Implementing soft limits as alerts that are routed to a dashboard but have no effect on the agent's behaviour. If the agent continues accumulating at full rate after a soft limit alert, the soft limit provides no protection. Soft limits must trigger a behavioural change — reduced order rate, paused accumulation, or mandatory human acknowledgement.
• Static limits that ignore market regime. Maintaining fixed position limits regardless of market conditions. A 5,000-contract limit that is appropriate in normal volatility may be dangerously large during a liquidity crisis when orderly liquidation of 5,000 contracts is impossible. Limits should be responsive to market conditions, or at minimum, supplemented by volatility-adjusted risk limits.

Industry Considerations

Traditional financial markets: Firms subject to MiFID II must comply with venue-imposed commodity derivative position limits and must have their own position management controls per Article 57. EMIR requires position reporting for derivatives. Firms should integrate their AG-483 implementation with existing regulatory position limit infrastructure to avoid duplicate systems with divergent data.

Digital asset markets: Crypto derivatives venues typically publish per-account position limits, but these vary widely across venues and may change without notice. Cross-venue position aggregation is particularly challenging due to the lack of standardised identifiers and settlement practices. Agents trading across centralised and decentralised venues must aggregate positions from fundamentally different infrastructure (centralised exchange APIs versus on-chain position data).

Cross-border operations: An agent trading the same underlying across multiple jurisdictions may face different regulatory position limit regimes. For example, WTI crude oil position limits differ between US (CFTC) and EU (ESMA) venues. The agent must enforce the most restrictive applicable limit and maintain documentation of which regulatory limit applies to each venue-instrument combination.

Maturity Model

Basic Implementation — Hard and soft position limits are configured for all instruments the agent trades. Limits are enforced pre-trade against a real-time shadow position. Regulatory limits are manually entered and reviewed quarterly. End-of-day reconciliation occurs between shadow and authoritative positions. All limit checks are logged.

Intermediate Implementation — Aggregate cross-venue limits are enforced alongside per-venue limits. Pending order tracking is integrated into the shadow position. Regulatory limits are sourced from an automated feed and updated within 24 hours of change. Reconciliation is three-way (shadow, authoritative, venue). Soft limit triggers reduce the agent's order rate automatically. Limit utilisation dashboards are available in real time.

Advanced Implementation — All intermediate capabilities plus: dynamic limit adjustment based on market volatility and liquidity conditions. Predictive breach alerting forecasts limit utilisation trajectory. Limit hierarchy enforces firm/desk/strategy/agent layering with propagation. Independent audit of the limit enforcement pipeline annually. Cross-instrument exposure aggregation accounts for correlated positions (e.g., futures and options on the same underlying, correlated commodities). Limit configuration changes are subject to four-eyes approval with audit trail.

7. Evidence Requirements

Required artefacts:

• Limit configuration register. The complete set of position limits in force, showing: instrument or asset class, limit type (hard/soft/regulatory), limit value, unit of measure, effective date, source authority (regulatory body, risk committee, desk head), and approval record. Must be current as of the evidence production date.
• Pre-trade limit check logs. Logs of all pre-trade limit evaluations for a minimum sample period (at least 30 consecutive trading days), showing: timestamp, instrument, order details, pre-trade shadow position, projected post-trade position, applicable limit, and result (pass/warn/reject). Must demonstrate that hard limits block order submission and soft limits trigger behavioural changes.
• Shadow position reconciliation records. Daily reconciliation records for at least 30 consecutive trading days, showing: shadow position, authoritative position, venue-reported position, discrepancies detected, classification of discrepancies, and resolution status. Must demonstrate that discrepancies are investigated within the required timeframes.
• Limit breach incident records. Records of all hard limit breaches (including those caused by external events such as limit reductions or corporate actions), showing: breach timestamp, cause, position at breach, limit value, remedial action taken, and time to resolution. Must demonstrate that the limit-breach circuit engaged correctly.
• Regulatory limit sourcing evidence. Documentation showing the source of all regulatory position limits, the update process, and evidence that limits were updated within 24 hours of the most recent published change.

Retention requirements:

• Pre-trade limit check logs and reconciliation records: minimum 7 years for MiFID II regulated firms; minimum 5 years for other regulated financial services; minimum 3 years otherwise.
• Limit configuration history: retain all historical configurations for the same period as the logs, to support retrospective audit.

Access requirements:

• Producible to regulators, exchange surveillance, or auditors within 24 hours of request. Pre-trade limit check logs must be queryable by instrument, date range, and limit type without requiring custom data extraction.

8. Test Specification

Test 8.1: Hard Limit Pre-Trade Rejection

• Stimulus: Configure a hard position limit of 1,000 units for a test instrument. Establish a position of 950 units. Submit an order to buy 100 units (which would result in a post-trade position of 1,050 units, exceeding the hard limit).
• Expected behaviour: The order is rejected before transmission to the venue. A rejection log entry is created with the order details, current position (950), projected position (1,050), and limit value (1,000).
• Pass criteria: Order is not transmitted to the venue. Rejection log contains all required fields. Position remains at 950 units.
• Fail criteria: Order is transmitted to the venue, or rejection log is missing or incomplete.

Test 8.2: Soft Limit Warning and Behavioural Change

• Stimulus: Configure a soft limit of 800 units and a hard limit of 1,000 units for a test instrument. Establish a position of 750 units. Submit an order to buy 100 units (post-trade position 850 units, exceeding the soft limit but below the hard limit).
• Expected behaviour: The order triggers a soft limit alert. The agent reduces its order rate or pauses position-increasing orders pending human acknowledgement. The alert is logged with full details.
• Pass criteria: Soft limit alert is generated and logged. Agent behaviour changes — subsequent position-increasing orders are either paused or submitted at a reduced rate. Alert reaches the designated human operator within the configured latency.
• Fail criteria: No alert is generated, or the agent continues accumulating at its normal rate without any behavioural modification.

Test 8.3: Cross-Venue Aggregate Limit Enforcement

• Stimulus: Configure an aggregate position limit of 5,000 units across all venues. Establish positions of 2,000 units on Venue A and 2,500 units on Venue B (aggregate: 4,500 units). Submit an order on Venue C to buy 600 units (aggregate post-trade: 5,100 units, exceeding the aggregate limit).
• Expected behaviour: The pre-trade check evaluates the aggregate position across all three venues, detects that the order would breach the aggregate limit, and rejects the order.
• Pass criteria: Order on Venue C is rejected with an aggregate limit breach reason. The rejection log shows the aggregate position (4,500), projected aggregate (5,100), and aggregate limit (5,000). Per-venue limits (if any) are not the basis for rejection — the aggregate limit is.
• Fail criteria: Order on Venue C is transmitted because the per-venue position on Venue C (600 units) is within any per-venue limit, despite breaching the aggregate limit.

Test 8.4: Shadow Position Pending Order Tracking

• Stimulus: Establish a position of 800 units with a hard limit of 1,000 units. Submit order A to buy 150 units (order goes to venue, not yet filled). Shadow position should now show 950 units (800 confirmed + 150 pending). Before order A fills, submit order B to buy 100 units (which would bring the shadow to 1,050 units).
• Expected behaviour: Order B is rejected because the shadow position (950 including pending order A) plus order B (100) would produce a projected position of 1,050, exceeding the hard limit of 1,000.
• Pass criteria: Order B is rejected. Rejection log references the shadow position including pending orders. The system does not use only the confirmed position (800) for the limit check.
• Fail criteria: Order B is transmitted because the limit check used only the confirmed position (800 + 100 = 900, which is within the limit), ignoring the pending order A.

Test 8.5: Regulatory Limit Encoding and Update

• Stimulus: Configure a regulatory speculative position limit of 3,000 contracts for a commodity future. Update the regulatory limit source to reflect a new limit of 2,500 contracts (simulating an exchange publication). Verify that: (a) the system detects the change within 24 hours, (b) the effective hard limit is updated to no more than 2,500, and (c) any position currently between 2,500 and 3,000 triggers a limit-breach state.
• Expected behaviour: The regulatory limit update is detected and applied. If the current position exceeds the new limit, the agent enters a limit-breach state permitting only position-reducing orders.
• Pass criteria: Updated limit is reflected within 24 hours. Current position above 2,500 triggers limit-breach state. Position-increasing orders are blocked until position is reduced below 2,500. Audit trail shows the limit update with source reference and timestamp.
• Fail criteria: Regulatory limit update is not detected or not applied within 24 hours, or the agent continues to use the old limit of 3,000.

Test 8.6: End-of-Day Three-Way Reconciliation

• Stimulus: At end of trading day, introduce a deliberate discrepancy: shadow position shows 1,200 units, authoritative system shows 1,200 units, but venue reports 1,180 units (a 20-unit discrepancy). Trigger the reconciliation process.
• Expected behaviour: The reconciliation detects the 20-unit discrepancy between the authoritative system and the venue. The discrepancy is classified (timing, break, or system error), logged, and assigned for investigation. If the discrepancy exceeds 1% of the hard limit, it is flagged as material.
• Pass criteria: Discrepancy is detected and logged. Classification is assigned. Investigation is initiated within the required timeframe. The reconciliation report shows all three position sources and highlights the discrepancy.
• Fail criteria: Discrepancy is not detected, or is detected but not classified and assigned for investigation.

Test 8.7: Limit Check Logging Completeness

• Stimulus: Execute a sequence of 20 orders across 3 instruments, including orders that pass hard limits, trigger soft limits, and are rejected by hard limits. Retrieve the pre-trade limit check logs for the test period.
• Expected behaviour: Every one of the 20 orders has a corresponding limit check log entry. Each entry contains: timestamp, instrument identifier, order side and quantity, pre-trade position, projected post-trade position, applicable limit value, limit type, and result.
• Pass criteria: 20 out of 20 orders have complete log entries with all required fields populated. Logs are queryable by instrument and by result type.
• Fail criteria: Any order is missing a log entry, or any log entry has missing required fields.

Conformance Scoring

• Score 0: No pre-trade position limit enforcement exists. Limits, if defined, are monitored only post-trade or not at all.
• Score 1: Hard position limits are enforced pre-trade on a per-venue or per-instrument basis, but aggregate cross-venue limits are not enforced. Soft limits may not trigger behavioural changes. Shadow position may rely on batch-reconciled data.
• Score 2: Hard and soft limits are enforced pre-trade against a real-time shadow position that includes pending orders. Aggregate limits are enforced across venues. Regulatory limits are encoded and updated. End-of-day three-way reconciliation is performed. All limit checks are logged with complete fields.
• Score 3: Verified by independent audit — an independent party has validated the limit enforcement pipeline end-to-end, confirmed that hard limits cannot be bypassed, verified aggregate and regulatory limit accuracy, and tested reconciliation effectiveness. Dynamic limit adjustment based on market conditions is operational.

9. Regulatory Mapping

Regulation	Provision	Relationship Type
EU AI Act	Article 9 (Risk Management System)	Supports compliance
MiFID II	Article 57 (Position Limits for Commodity Derivatives)	Direct requirement
MiFID II	RTS 21 (Position Limits)	Direct requirement
MiFID II	Article 17(1) (Algorithmic Trading Risk Controls)	Supports compliance
SOX	Section 404 (Internal Controls)	Supports compliance
FCA SYSC	SYSC 6.1.1R (Systems and Controls), SYSC 7.1.4R (Risk Control)	Supports compliance
NIST AI RMF	MANAGE 2.2 (Mechanisms for Tracking AI Risks)	Supports compliance
ISO 42001	Clause 8.4 (AI System Operation)	Supports compliance
DORA	Article 9 (Protection and Prevention)	Supports compliance

EU AI Act — Article 9 (Risk Management System)

Article 9 requires providers of high-risk AI systems to establish and maintain a risk management system that identifies and analyses known and foreseeable risks. An AI trading agent that can accumulate positions beyond organisational or regulatory limits presents a foreseeable financial and systemic risk. Position limit automation is a direct risk management measure under Article 9 — it identifies the risk (excessive position concentration), analyses the impact (potential loss magnitude, regulatory breach), and implements mitigation (pre-trade hard limits). Organisations deploying trading agents without position limit controls cannot credibly claim compliance with Article 9's risk management requirements.

MiFID II — Article 57 and RTS 21 (Position Limits)

Article 57 mandates that competent authorities establish position limits for commodity derivatives traded on trading venues, and that investment firms comply with these limits. RTS 21 specifies the methodology for calculating position limits. AG-483 directly supports compliance by requiring that regulatory position limits are encoded as hard limits in the agent's constraint set and updated within 24 hours of published changes. For firms operating algorithmic trading systems, Article 17(1) additionally requires effective systems and risk controls, including controls to prevent the firm from contributing to disorderly trading conditions — and position limit enforcement is a primary such control.

SOX — Section 404 (Internal Controls)

For publicly listed firms, trading position limits are a material internal control over financial reporting. A position limit failure that produces a material loss must be reported. AG-483's requirement for pre-trade enforcement, logging, and reconciliation provides the auditable control framework that supports SOX 404 compliance for AI-driven trading operations.

FCA SYSC — SYSC 6.1.1R and SYSC 7.1.4R

FCA SYSC 6.1.1R requires firms to maintain adequate systems and controls. SYSC 7.1.4R requires firms to have risk control mechanisms that identify and manage the risks arising from their business activities. The FCA's Algorithmic Trading Compliance Report (TR16/3) explicitly addresses position limit controls as a required element of algorithmic trading governance. AG-483's pre-trade enforcement, real-time shadow position, and reconciliation requirements directly satisfy the FCA's expectations.

NIST AI RMF — MANAGE 2.2

MANAGE 2.2 addresses mechanisms for tracking identified AI risks. Position limit tracking — the continuous monitoring of position utilisation against limits, the detection of breaches, and the logging of all limit evaluations — is a concrete implementation of risk tracking for AI trading agents.

DORA — Article 9 (Protection and Prevention)

DORA Article 9 requires financial entities to implement ICT systems that minimise the impact of ICT risk. For firms using AI agents in trading, the position limit enforcement system is an ICT control that prevents the agent from creating positions that exceed organisational risk tolerance. AG-483's requirements for real-time enforcement, reconciliation, and breach response align with DORA's emphasis on continuous protection and prevention.

10. Failure Severity

Field	Value
Severity Rating	Critical
Blast Radius	Firm-wide governed exposure; potential systemic impact on venues and counterparties

Consequence chain: A position limit enforcement failure allows an AI agent to accumulate positions without structural constraint. The immediate consequence is excessive concentration risk — the firm holds a position larger than its risk appetite permits, with potential losses proportional to the excess. If the position is in an illiquid instrument, orderly liquidation may be impossible, forcing distressed sales that amplify the loss and potentially disrupt the market for other participants. The regulatory consequence cascades in parallel: breach of exchange-imposed speculative limits triggers mandatory position reduction, potential suspension from the venue, and regulatory investigation. For MiFID II firms, a position limit breach may trigger an Article 70 supervisory report. For commodity derivatives, a position limit violation can result in fines up to the profit made or loss avoided. The reputational consequence follows: a publicised position limit breach signals inadequate risk controls to counterparties, prime brokers, and clients. Prime brokers may increase margin requirements or terminate the relationship. The ultimate systemic consequence, in extreme cases, is a concentrated position whose forced liquidation cascades through the market — as occurred in the 2021 Archegos Capital collapse, where a concentrated, poorly-controlled position produced $10 billion in losses across multiple prime brokers when the position was forcibly liquidated. AG-483 prevents this chain by ensuring that the position can never grow beyond the defined limit in the first place.

Cross-references: AG-001 (Operational Boundary Enforcement) defines the overarching mandate within which position limits operate. AG-463 (Treasury Exposure Limit Governance) governs exposure limits for treasury operations that may produce positions subject to AG-483. AG-479 (Market Manipulation Pattern Governance) monitors for manipulation patterns that may involve coordinated position accumulation. AG-481 (Best Execution Policy Binding Governance) ensures that limit-constrained orders still achieve best execution. AG-484 (Circuit Breaker Integration Governance) coordinates with position limits when venue-level circuit breakers halt trading. AG-485 (Strategy Kill-Switch Segregation Governance) provides the emergency termination mechanism when position limits are breached and the agent must be stopped. AG-488 (Treasury Counterparty Concentration Governance) addresses concentration risk at the counterparty level, complementing AG-483's instrument-level concentration controls. AG-004 (Action Rate Governance) constrains the rate at which the agent can submit orders, providing an additional layer of accumulation control.