← Glossary

Devancore Post-Trade Glossary

Chat-Based Trade Capture

Chat-based trade capture converts trade details from messages into structured trade records with instrument resolution, account context, validation, review, and audit evidence.

Definition

Chat-based trade capture is the controlled workflow that converts a trade message into a structured trade record. The message may arrive through chat, voice transcript, broker conversation, internal desk note, or another collaboration channel. The capture workflow turns that unstructured instruction into fields that a trade capture system, order management system, execution management system, brokerage API, or post-trade platform can validate.

This page is narrower than natural language trading. Natural language trading covers the broader path from plain-language intent to staged order, control review, routing, execution, and post-trade record formation. Chat-based trade capture focuses on the first operating problem: preserving the original message while creating a clean trade record from it.

Message to trade record fields

Message to trade record fields

Capture quality depends on resolving the text into controlled data, not only extracting words.

Field group Captured data Control question
Source message Channel, sender, timestamp, conversation ID, message text, attachment, and thread context Can the trade record be traced to the original instruction?
Economics Side, instrument wording, quantity, notional, price, currency, order type, and time condition Are the economics complete enough for a structured draft?
Instrument identity Ticker, ISIN, CUSIP, FIGI, DTI, issuer, maturity, option terms, or internal security ID Has the intended instrument been resolved without ambiguity?
Account context Fund, account, portfolio, sleeve, strategy, custodian, clearing account, and allocation method Does the captured trade point to the right operating book?
Settlement intent Counterparty, broker, SSI, settlement date, cash leg, security leg, delivery method, and fail risk Can downstream post-trade enrichment proceed?
Review evidence Parsed fields, missing data, reviewer, approval, correction, route, and final capture status Can the capture decision be reconstructed later?

The source message matters because it explains how the trade entered the workflow. A captured trade should retain the sender, timestamp, channel, thread, attachment, and source identifier. If the resulting record is later disputed, the firm should not need to reconstruct the original instruction from screenshots or separate communication archives.

Field extraction is only the first step. The workflow should identify side, quantity, notional, price, instrument wording, account clue, counterparty, trade date, settlement date, order type, and instruction type. Some messages contain exact trade economics. Others contain partial intent. The capture state should show what was explicit, what was inferred, and what is missing.

Instrument and account resolution are the highest-risk parts of the workflow. A short name can refer to a security, issuer, fund, strategy, account, counterparty, or internal code. The workflow should resolve against governed instrument master data and account records. When the match is ambiguous, the item should move to clarification or review rather than becoming a booked trade.

Chat capture also needs settlement context. A record that has side, quantity, and price may still be operationally incomplete if it lacks counterparty, custodian, SSI, settlement date, delivery method, cash leg, security leg, fee, tax-lot, or allocation data. Weak capture becomes a post-trade break when it reaches enrichment, confirmation, or settlement.

How it works

Chat-based trade capture works by preserving a lineage chain from message to reviewed trade record. The workflow should show how the message was parsed, which fields were extracted, which masters were used, which exceptions were raised, who reviewed the record, and where the captured trade was published.

Chat capture workflow

Chat capture workflow

The workflow should move from message to reviewed record before downstream processing begins.

Step Record created Failure mode
Ingest message Original text, sender, timestamp, channel, thread, attachment, and source ID The captured trade loses the message that created it
Extract fields Side, quantity, price, instrument wording, account clue, counterparty, date, and instruction type The system treats incomplete text as a complete record
Resolve identity Instrument master match, account mapping, portfolio, strategy, custodian, and route context A similar ticker, issuer, fund, or account is selected incorrectly
Enrich record Allocation, SSI, settlement date, fees, tax-lot context, restrictions, and reference data The trade reaches post-trade with missing settlement or accounting fields
Review exception Missing fields, ambiguity, override, approval, correction, and owner A weak extraction bypasses human review
Publish capture Trade record, blotter entry, downstream ID, audit trail, and post-trade status The booked record cannot be tied back to the chat instruction

Message ingestion stores the raw instruction and source metadata. The channel can be a chat system, voice transcript, email-like message, broker note, or internal conversation. The capture event should carry a source ID so the final trade record can point back to the message.

Extraction converts language into proposed fields. The system should separate trade economics from commentary. "Buy 10mm five-year notes for income sleeve if price is inside limit" contains side, size, instrument clue, strategy context, and price condition. Each element should become a visible field or review item.

Resolution maps the proposed fields to governed records. Instrument identity should connect to the security master. Account and portfolio context should connect to internal books. Counterparty and broker context should connect to known relationships. Settlement fields should connect to standing settlement instructions and custody records.

Enrichment prepares the record for downstream processing. Allocation rules, settlement route, fees, tax-lot context, restrictions, confirmation fields, and reference data can be attached before the trade reaches post-trade operations. Early enrichment makes missing data visible while the trader or operations user still has context.

Review handles ambiguity. Missing quantity, unclear instrument, conflicting account name, uncertain allocation, stale SSI, or unsupported security type should create a pending state. A reviewer can confirm, correct, reject, or request clarification. The final record should preserve the original extraction, the correction, and the reviewer decision.

Publication closes the capture step. Once reviewed, the trade can enter the blotter, OMS, post-trade workflow, reconciliation queue, or downstream API. Execution report, confirmation, settlement instruction, and break status should remain linked back to the original message.

In Devancore™

Devancore supports chat-based trade capture as a controlled operating-record workflow. It should be framed as the layer that preserves message source, parsed fields, enrichment context, review state, publication event, and downstream post-trade evidence.

Devancore should not be framed as a trading venue, broker, custodian, clearing broker, adviser, or autonomous execution system. The product value is in turning an unstructured instruction into a reviewable record that can feed trade capture, enrichment, confirmation, reconciliation, settlement, books-and-records evidence, and reporting inputs.

In a Devancore-style workflow, a chat message becomes a capture event. The platform can preserve the source message, identify proposed trade fields, connect the instrument to reference data, connect the account to the right operating book, attach settlement intent, flag missing or ambiguous data, and route the record for review.

That gives the front office and operations team a shared record. The trader sees what was captured. Operations sees what is missing before settlement pressure builds. Compliance and supervision can see the original message, parsed fields, reviewer decision, correction history, and final trade record.

Chat-based trade capture is therefore a bridge between conversational finance and the trade lifecycle. Conversational finance provides the interface. Natural language trading describes the broader order path. Chat-based trade capture defines how the message becomes a controlled trade record.