Devancore Inc.
Devancore Post-Trade Glossary
Glossary
Natural Language Trading
Natural language trading converts a user's plain-language trade intent into a structured order draft, validation record, human review step, routing instruction, and audit trail.
Document source: https://devancore.com/glossary/natural-language-trading/
Devancore Post-Trade Glossary
Natural Language Trading
Natural language trading converts a user's plain-language trade intent into a structured order draft, validation record, human review step, routing instruction, and audit trail.
Definition
Natural language trading is the controlled workflow that converts a user's plain-language trade intent into a structured order draft. The workflow should identify the user, account, instrument, side, quantity, order type, price terms, allocation context, routing destination, and required approvals before anything is submitted.
The institutional value is not that a sentence can "trade." The value is that a sentence can be captured, parsed, validated, reviewed, routed, and retained as part of the trading and post-trade record. Natural language becomes useful when it reduces entry friction without weakening order controls.
Prompt to order record
Prompt to order record
The key control is converting language into fields that can be validated before anything is routed.
| Field | Example input | Control question |
|---|---|---|
| User and permission | Trader, portfolio manager, adviser, desk, role, and account scope | Is the user allowed to stage or submit this type of order? |
| Instrument | Ticker, ISIN, CUSIP, FIGI, issuer name, option contract, bond, token, or internal security code | Has the instrument been resolved without ambiguity? |
| Order economics | Side, quantity, notional, order type, limit, stop, time-in-force, currency, and strategy instruction | Are the order fields complete and internally consistent? |
| Account and allocation | Account, fund, sleeve, model, block order, allocation method, and custodian context | Does the draft point to the right books and downstream records? |
| Validation | Restrictions, limits, concentration, cash, margin, settlement, and market-access checks | Can the order proceed to review or should it be blocked? |
| Evidence | Original prompt, parsed fields, clarification, reviewer, route, execution report, and outcome | Can the trade record be reconstructed from intent through post-trade? |
Trade intent is not the same as an executable order. "Buy Treasuries for the income fund" may be a useful instruction, but it lacks instrument, maturity, quantity, account, price, route, settlement, and allocation detail. A natural language trading workflow should either ask for the missing fields or create a draft that clearly shows what still needs review.
Entity resolution is the core risk. A name can refer to an issuer, ticker, bond, option, fund, account, strategy, or internal code. The system should not silently guess when the instruction is ambiguous. It should preserve the original wording, proposed mapping, confidence or rule basis, and user confirmation.
The order management system, execution management system, brokerage API, or FIX route remains the control surface for trading. Natural language is the input mode. The resulting order still needs entitlement checks, restrictions, risk limits, market-access checks, order review, and a record of who confirmed the instruction.
Natural language trading — intent to order fields
Devancore · message matrix
| Rail | Message | Purpose | Record |
|---|---|---|---|
| Prompt | raw intent | capture | user, time, account context, security wording, side, size, price language, and action verb |
| Resolver | structured entities | disambiguation | instrument ID, account, portfolio, strategy, allocation target, currency, and venue or route context |
| OMS / EMS | order draft | validation | side, quantity, order type, limit, time-in-force, restrictions, risk result, and review state |
| Routing | instruction | controlled submission | human confirmation, route, FIX or API message, order ID, timestamp, and downstream response |
| Post-trade | operating record | evidence | execution report, fill, allocation, confirmation, settlement intent, break state, and audit trail |
How it works
Natural language trading works by separating language capture from order submission. A prompt enters the workflow. The system extracts intent. Entities are resolved. A structured draft is created. Controls run. A human reviews. The approved instruction moves through the firm's normal trading route.
Natural language trading workflow
Natural language trading workflow
The workflow should preserve the bridge from human words to trading and post-trade records.
| Step | Record created | Failure mode |
|---|---|---|
| Capture intent | Prompt, speaker, time, context, portfolio, account, and requested action | The instruction is treated as a complete order when key fields are missing |
| Resolve entities | Instrument, account, portfolio, strategy, allocation target, broker, and routing destination | The model maps a name to the wrong security, account, or strategy |
| Build draft | Order ticket, side, quantity, order type, price, time-in-force, allocation, and notes | A fluent prompt becomes an invalid or incomplete order ticket |
| Validate controls | Entitlement, restrictions, risk limits, buying power, cash, margin, and market-access result | The trade bypasses pre-trade controls because it arrived through chat |
| Review and route | Human confirmation, maker-checker where required, route, FIX or API instruction, and timestamp | A draft is submitted without review or with weak approval evidence |
| Record outcome | Execution report, order status, fill, allocation, confirmation, settlement intent, and audit trail | The post-trade record cannot link back to the original intent |
Intent capture stores the original prompt with user, time, account context, and requested action. That original wording matters because it is the source record for how the order began. Voice, chat, or typed entry should all resolve to a retained intent record.
Entity resolution maps the prompt to financial objects. Instrument identifiers, account codes, portfolio names, strategy labels, allocation targets, broker routes, and currencies should be confirmed against governed reference data. If the prompt uses a nickname or incomplete identifier, the workflow should clarify before creating a final ticket.
Draft construction converts the instruction into order fields. Side, quantity, notional, price, order type, time-in-force, venue, route, allocation, settlement context, and notes should be visible to the user. The draft should show what was inferred and what was explicitly stated.
Control validation prevents the language interface from becoming a bypass path. Entitlement, restricted lists, concentration limits, cash, margin, account eligibility, market access, and workflow policy should run before route release. Rejections and warnings should return to the user in plain language but stay tied to the underlying control result.
Review and routing complete the handoff. The user confirms the structured draft. A checker approves when required. The instruction then moves through the OMS, EMS, FIX session, or brokerage API. Execution reports, order status, fills, allocation results, and settlement intent should remain linked to the original prompt.
The audit trail is the golden thread: prompt, parsed fields, clarifications, user confirmation, control results, route, execution report, allocation, settlement instruction, and post-trade status. Without that thread, natural language trading creates a shadow record beside the real trading record.
Natural language trading — controlled order path
Devancore · roadmap
- 01
Intent
Plain-language instruction is captured with user, time, context, and requested action.
- 02
Resolve
Instrument, account, portfolio, allocation, route, and order fields are mapped or clarified.
- 03
Validate
Entitlement, restrictions, risk limits, cash, margin, and market-access checks run before submission.
- 04
Review
The user or checker confirms the structured order draft before it leaves the controlled workflow.
- 05
Record
Order, execution, allocation, settlement intent, and audit trail stay linked to the original prompt.
In Devancore™
Natural language trading — control responsibilities
Devancore · responsibility matrix
| Work | User | AI | OMS | Checker | Record |
|---|---|---|---|---|---|
| State intent | R | C | I | I | E |
| Resolve fields | C | R | C | I | E |
| Validate controls | I | C | R | C | E |
| Confirm order | A | I | C | C | E |
| Approve exception | C | I | C | A | E |
| Route instruction | A | I | R | C | E |
| Retain trail | C | C | C | C | A |
Devancore should be framed as the controlled operating-record and workflow layer around natural language trading, not as an execution venue, broker, adviser, custodian, clearing broker, or autonomous trading system. Its role is to preserve the bridge from intent to structured records.
In a Devancore-style workflow, the prompt becomes an operating event. The event is mapped to user, account, instrument, allocation context, and order draft fields. The workflow can carry control results, review status, approvals, route identifiers, execution reports, settlement intent, and downstream post-trade evidence.
This connects the front-office interface to the post-trade record. A sentence may start the workflow, but the resulting trade still needs capture, enrichment, confirmation, allocation, reconciliation, settlement instruction, books-and-records evidence, and supervision. Devancore's value is keeping those states connected rather than letting the chat transcript sit apart from the trade lifecycle.
The same model can support traditional and digital asset workflows if the instrument and settlement records are explicit. A prompt should resolve to the right identifier, account, custody path, route, and settlement instruction before it becomes an order. The control principle does not change because the asset is tokenized or the route is API-based.
Natural language trading sits below the broader conversational finance category. Conversational finance defines the interface. Natural language trading applies it to order intent. Chat-based trade capture and AI-generated trade instructions can then describe narrower parts of the same chain.
Related terms
- Conversational Finance
https://devancore.com/glossary/conversational-finance/
Conversational finance is a controlled natural-language interface for financial records, workflow intent, approvals, and evidence across trading, post-trade, compliance, and reporting.
- Conversational Finance Ops
https://devancore.com/glossary/conversational-finance-ops/
Conversational finance for investment operations is a permissioned natural-language interface over operating records: the question, the entitled sources, the cited evidence, and a workflow action that still needs approval.
- AI Agent Post-Trade Ops
https://devancore.com/glossary/ai-agent-post-trade-operations/
AI agent post-trade operations use controlled agents to detect exceptions, assemble evidence, draft actions, route approvals, and record outcomes without bypassing human supervision.
- Trade Capture System
https://devancore.com/glossary/trade-capture-system/
The system that books an executed trade into the firm's official records and initiates the post-trade processing workflow from enrichment and matching through to settlement instruction.
- FIX Protocol Trade Capture
https://devancore.com/glossary/fix-protocol-trade-capture/
Open financial messaging standard where MsgType 8 Execution Reports trigger real-time trade capture and settlement pipeline processing for broker-dealers.
- Maker-Checker Workflow
https://devancore.com/glossary/maker-checker-workflow/
A two-person segregation of duties control requiring that any action entered by one operator must be reviewed and approved by a second before it takes effect.
- Broker-Dealer Audit Trail
https://devancore.com/glossary/broker-dealer-audit-trail/
The immutable, chronologically linked record of every trade lifecycle event — from order receipt through settlement — maintained to satisfy SEC Rules 17a-3 and 17a-4, FINRA clock synchronization requirements, and CAT reporting obligations.
- Segregation of Duties (SoD)
https://devancore.com/glossary/segregation-of-duties-financial-software/
Segregation of duties (SoD) is the internal control principle that no single operator can book, approve, and settle a transaction — enforced through conflict matrices, maker-checker workflows, and access certification reviews to satisfy SOX Section 404.
- System of Record Securities Operations
https://devancore.com/glossary/system-of-record-securities-operations/
The authoritative single source of truth for a firm's positions, trades, and accounts — the system of record that all other systems, reports, and compliance functions derive from.
- Operational Risk Management Securities
https://devancore.com/glossary/operational-risk-management-securities/
The identification and mitigation of risks from failed processes, human errors, technology failures, and external events that disrupt securities operations or cause financial loss.
- Brokerage API Post Trade
https://devancore.com/glossary/brokerage-api-post-trade/
Brokerage API post trade integration turns API orders, fills, journals, transfers, and account events into a controlled operating record with mapping, status, exceptions, reconciliation, and evidence.
- OMS To Post Trade Integration
https://devancore.com/glossary/oms-to-post-trade-integration/
OMS to post-trade integration is the controlled handoff from order and execution records into allocation, confirmation, enrichment, settlement instruction, reconciliation, supervision, and reporting workflows.
- Trade Enrichment Automation
https://devancore.com/glossary/trade-enrichment-automation/
The automated augmentation of a raw trade capture with settlement instructions, counterparty identifiers, and regulatory fields required for clearing and settlement.
- Trade Confirmation Matching
https://devancore.com/glossary/trade-confirmation-matching/
The automated comparison of trade details between counterparties to verify both sides recorded the same economics before settlement instructions are generated.
- Trade Allocation
https://devancore.com/glossary/trade-allocation/
Post-execution process that splits a block trade into account-level positions, each generating a separate confirmation and settlement obligation.
- Standing Settlement Instructions
https://devancore.com/glossary/standing-settlement-instructions/
Pre-agreed instructions specifying how a counterparty's securities and cash should be delivered or received, applied automatically to every qualifying trade.
- Settlement Instruction Automation
https://devancore.com/glossary/settlement-instruction-automation/
Automatically generating and transmitting settlement instructions to custodians and CSDs using pre-loaded SSI data — replacing manual entry, enabling STP, and making T+1 compliance operationally viable.
- FIX Engine Connectivity for Broker-Dealers
https://devancore.com/glossary/fix-engine-connectivity/
The software layer managing FIX session state, message sequencing, heartbeats, and failover for broker-dealers connecting to brokers, venues, and ECNs.
- FIX Protocol in Securities Trading
https://devancore.com/glossary/fix-protocol-securities-trading/
The open messaging standard governing order routing, execution reporting, and allocation between broker-dealers, buy-side firms, and trading venues — upstream of SWIFT.
- Trade Blotter Post Trade Workflow
https://devancore.com/glossary/trade-blotter-post-trade-workflow/
A trade blotter post-trade workflow turns blotter rows into governed operating records for allocation, enrichment, confirmation, settlement instruction, exception management, reconciliation, supervision, and audit evidence.
Contact
Request a briefing or platform walkthrough with the Devancore team.
Request access https://devancore.com/access/