← Glossary

Devancore Post-Trade Glossary

AI Generated Trade Instructions

AI-generated trade instructions are structured order or settlement drafts prepared from user intent, model outputs, files, or messages, then validated and approved before routing.

Definition

AI-generated trade instructions are structured order or workflow drafts prepared from a prompt, trade message, portfolio model, rebalance file, operating record, or other source input. The generated draft may contain instrument identity, side, quantity, notional, price terms, account, allocation, route, time-in-force, settlement intent, and destination payload fields.

The useful boundary is draft state. An AI-assisted workflow may prepare an instruction, but the draft should not become a routed order simply because it contains complete-looking fields. Institutional workflows need validation, entitlement, review, approval, and retained evidence before a generated instruction leaves the controlled environment.

Generated instruction record

Generated instruction record

The draft is useful only when every generated field can be validated before routing.

Instruction area Generated data Control question
Source intent Prompt, message, model rebalance, spreadsheet row, user, timestamp, and workflow context Can the instruction be traced to the request that created it?
Instrument Ticker, CUSIP, ISIN, FIGI, issuer, maturity, share class, option terms, token ID, or internal security ID Has the security been resolved without ambiguity?
Economics Side, quantity, notional, price, order type, limit, currency, time-in-force, and strategy notes Are the fields complete and internally consistent?
Account and allocation Fund, account, sleeve, model, allocation method, custodian, clearing account, and eligibility Can the draft reach the right operating book?
Route and payload OMS, EMS, FIX message, brokerage API request, broker, venue, route, and client order ID Does the generated payload match the destination contract?
Evidence Parsed fields, validation result, reviewer, checker, route decision, downstream response, and final outcome Can the instruction lifecycle be replayed later?

The source intent is part of the record. A portfolio manager's note, a rebalance file, a chat message, or a model output explains why the instruction exists. If the generated order later creates a dispute, allocation error, settlement break, or supervisory question, the firm needs the original request and the generated interpretation side by side.

Instrument resolution is the highest-risk field group. A short name can map to an issuer, equity, bond, ADR, option, share class, token, or internal security. The workflow should resolve against governed reference data and show the selected identifier. If several candidates match, the draft should stop for clarification or review.

Account and allocation context matter as much as instrument identity. A generated instruction must know which portfolio, fund, account, sleeve, strategy, clearing account, custodian, and allocation method apply. Otherwise, the draft may look tradable while pointing to the wrong operating book.

Destination readiness is a separate control. A valid human-readable draft still needs to match the receiving system's contract: OMS fields, EMS route rules, FIX tags, brokerage API schema, required identifiers, time-in-force values, and downstream response handling. Generated text is not a message protocol.

The final record should preserve the entire chain: source request, parsed fields, resolved records, validation result, review edits, approval, routed payload, downstream response, execution state, allocation, settlement intent, and post-trade evidence.

How it works

AI-generated trade instructions work by turning intent into a structured draft, then forcing that draft through the same operating controls that govern ordinary trade instructions. The workflow should reduce manual entry without creating a shortcut around entitlement, supervision, or routing controls.

Draft to routed instruction

Draft to routed instruction

AI can prepare the payload. Workflow controls decide whether it moves.

Step Record created Failure mode
Capture source Original prompt, rebalance file, model output, chat message, or portfolio instruction The draft loses the source that explains why it exists
Parse intent Proposed action, security wording, account context, side, size, price, timing, and constraints Model hallucination or context misalignment creates plausible but unsupported fields
Resolve records Instrument master match, account, portfolio, strategy, allocation, route, and settlement context A similar issuer, share class, account, or token is selected incorrectly
Validate controls Entitlement, restrictions, risk limits, cash, margin, account eligibility, and destination schema The instruction bypasses controls because it was machine-generated
Review draft Human confirmation, maker-checker rule, edits, rejection reason, and approval evidence A draft is treated as approved because the fields look complete
Route and record FIX or API payload, order ID, downstream response, execution status, allocation, and audit trail The routed order cannot be tied back to the generated draft

The workflow begins with a source input. The input can be a natural-language request, chat message, spreadsheet, rebalance model, exception workflow, or portfolio instruction. The source is stored before parsing because it is the evidence for why the draft was created.

Parsing separates action from commentary. The system extracts side, size, security wording, account clues, price language, timing, constraints, and requested action. It should also show missing fields. A vague instruction should become a pending draft, not a fully routed order.

Resolution maps extracted fields to governed records. Instrument master, account master, portfolio structure, strategy labels, broker routes, settlement instructions, and restriction data decide whether the draft points to a real operating object. Silent mapping is dangerous when several securities or accounts share similar names.

Validation applies the control stack. Entitlement determines whether the user may stage, edit, approve, or submit the instruction. Pre-trade checks test restrictions, limits, cash, margin, concentration, account eligibility, and market access. For broker-dealer workflows, market-access controls should remain hard gates around credit, capital, order size, and route permissions before any generated draft can be submitted. Destination validation tests whether the generated payload can be accepted by the OMS, EMS, FIX session, or brokerage API.

Review converts the machine-prepared draft into a governed instruction. The user sees what was explicit, what was inferred, what changed during review, and which controls passed or failed. If AI prepares the draft, the human reviewer is the checker. If a human uses AI while acting as maker, a second human or segregated control should validate the final state where policy requires separation of duties.

Routing happens only after approval. The instruction may become a FIX message, brokerage API request, OMS ticket, EMS route, allocation instruction, or downstream workflow event. The routed payload, response, order ID, execution report, allocation, confirmation, settlement instruction, and audit trail should point back to the generated draft.

AI-generated instruction — field validation

Devancore · message matrix

Rail Message Purpose Record
Intent source request capture prompt, message, file, model output, user, timestamp, and requested action
Draft structured fields prepare instrument, side, size, account, allocation, order type, price, route, and settlement intent
Control validation result gate entitlement, restrictions, risk, account eligibility, payload schema, and review state
Approval human decision authorize reviewer, checker, edits, rejection reason, approval, and timestamp
Route FIX / API payload submit destination, client order ID, downstream response, execution state, and audit trail

In Devancore™

Devancore supports AI-generated trade instructions as a controlled draft-and-record workflow. The platform should be framed as an operating layer that preserves source intent, generated fields, validation results, approval state, routed payloads, downstream responses, and post-trade evidence.

Devancore should not be framed as an autonomous trading system, execution venue, broker, custodian, clearing broker, investment adviser, compliance officer, or legal authority. The product value is in making generated instructions governable before they touch execution or settlement infrastructure.

In a Devancore-style workflow, the draft instruction becomes an event. The event is tied to user, account, instrument, allocation context, route, settlement intent, permission state, control results, and source evidence. If the draft is ambiguous, it remains pending. If it fails a restriction or account eligibility check, it is blocked or routed to review. If approved, the routing event and downstream response stay linked to the original draft.

This matters for conversational finance because natural language can make trade entry faster while also creating new ambiguity. A controlled instruction layer lets the firm see the exact step where language became fields, fields became a draft, the draft passed controls, and the approved payload entered the trading route.

The same discipline applies after execution. Generated instructions should feed the trade lifecycle, allocation, confirmation, reconciliation, settlement, books-and-records, and supervision trail. The firm should be able to reconstruct why the instruction was generated, what it contained, who approved it, where it routed, and what happened next.