Devancore Inc.
Devancore Post-Trade Glossary
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.
Document source: https://devancore.com/glossary/conversational-finance/
Devancore Post-Trade 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.
Definition
Conversational finance is a controlled natural-language interface for financial records and workflows. It lets an authorized user ask a question, express intent, retrieve cited records, stage an action, route approval, and preserve evidence across institutional finance workflows.
The parent concept is broader than post-trade operations. It covers front-office questions, order intent, portfolio context, post-trade exceptions, compliance review, finance evidence, reporting support, and controlled workflow actions. Conversational finance ops is one child of this category. AI agent post-trade operations is another child, focused on agents that prepare multi-step work.
Conversational finance control layers
Conversational finance control layers
Natural language becomes useful only when it resolves to records, permissions, actions, and evidence.
| Layer | What it controls | Operating question |
|---|---|---|
| Intent | User question, workflow request, portfolio scope, account, instrument, date, and action type | What is the user trying to know or do? |
| Entitlement | Role, desk, account scope, portfolio access, record permission, and action right | Can this user see or stage this workflow? |
| Retrieval | System of record, book of record, report, file, message, exception, or API result | Which source records support the answer? |
| Citation | Record key, as-of time, version, owner, calculation run, and source lineage | Can the answer be replayed from controlled records? |
| Action | None, draft, annotate, assign, escalate, approve, instruct, or post | Is the request informational or a state change? |
| Evidence | Prompt, retrieved records, answer, proposal, approver, downstream event, and outcome | Can the conversation be supervised later? |
The operating problem is that financial work often starts with a question that crosses systems. A portfolio manager asks for exposure. Operations asks why a trade failed. Compliance asks who approved an override. Finance asks which records support a report line. A useful interface should resolve those questions to records, not to unsupported prose.
Natural language is only the entry point. The system still needs intent parsing, entitlement, source retrieval, citation, action classification, approval routing, and retained evidence. A plain answer may be enough for a query. A proposed order, correction, instruction, or approval requires a controlled workflow state.
Conversational finance should be designed around deterministic records. A model may translate language and summarize context, but the answer must point back to books of record, systems of record, reports, transaction IDs, calculation runs, messages, and workflow events. The record is the source. The conversation is the interface.
How it works
Conversational finance works by turning language into structured financial intent. The first task is to identify what the user is asking about: a portfolio, account, security, cash balance, trade, settlement fail, reconciliation break, report line, approval, restriction, or action request.
From prompt to governed workflow
From prompt to governed workflow
The same interface can answer, draft, or block depending on entitlement and workflow state.
| Step | Data required | Control failure |
|---|---|---|
| Parse intent | Question, object type, action verb, date, account, portfolio, instrument, and workflow context | The system answers a vague prompt from model memory rather than a named record |
| Check permission | User role, account scope, desk, record access, action rights, and approval limits | The interface exposes records or actions outside the user's authority |
| Retrieve records | Books of record, trade records, positions, cash, breaks, reports, messages, and API responses | The answer mixes stale, unentitled, or unmatched sources |
| Cite answer | Source key, as-of time, version, calculation, report line, and exception ID | A fluent answer cannot be reconstructed from the underlying records |
| Classify action | Query-only, draft, approval request, escalation, instruction, correction, or block | The interface treats a state change as a normal answer |
| Retain trail | Prompt, sources, answer, draft, approver, downstream event, and final status | The firm cannot show what was asked, shown, proposed, and done |
Permissioning comes before retrieval. A user should not receive a summary of records they could not access in the source system. The same principle applies to actions. Seeing a break, drafting a note, approving a correction, and posting an instruction are different permissions.
Retrieval must be grounded in source records. The interface should identify the relevant operating records and preserve source keys, as-of time, calculation version, file version, message ID, or report line. Without that context, the answer may sound useful while being impossible to supervise.
The system then separates query from action. "Show open settlement fails" is retrieval. "Assign these fails to an analyst" is workflow state. "Submit this instruction" is a downstream action. Those paths should be classified before any response is returned.
Human review is the boundary for sensitive work. A conversational interface may stage an order, draft a settlement message, prepare a correction, assign an exception, or assemble an evidence pack. The firm still needs approval rules, maker-checker where required, segregation of duties, and a trail that shows what changed.
The retained trail is part of the operating record. Prompt, retrieved records, cited answer, proposed action, approver, downstream system response, and final outcome should remain available for supervision, audit, and issue reconstruction.
Conversational finance — operating standard
Devancore · control state
Before
Chat over finance data
- Answers are separated from source records
- Permissioning is handled outside the conversation
- Query, draft, approval, and posting blur together
- Transcript exists without structured operating evidence
After
Controlled finance interface
- Every answer carries source keys, as-of time, and record lineage
- Entitlement is checked before retrieval or action
- State changes are staged, routed, and approved
- Prompt, citation, proposal, approval, and outcome form the trail
In Devancore™
Devancore — conversational finance evidence chain
Devancore · evidence stack
Intent
The prompt is mapped to a financial object, workflow request, date, portfolio, account, instrument, or report context.
Entitlement
The same access boundaries used by source systems decide which records can be retrieved and which actions may be staged.
Grounded answer
Positions, cash, settlement status, breaks, reports, approvals, and source files remain cited with keys and as-of time.
Controlled action
Drafts, assignments, escalations, instructions, or corrections enter workflow state before any downstream change occurs.
Audit trail
Prompt, sources, answer, draft, approver, downstream response, and final outcome remain attached to the operating record.
Devancore supports conversational finance as a controlled interface over institutional operating records and workflows. The platform should be framed as a record, workflow, evidence, and integration layer around financial operations, not as a broker, custodian, clearing broker, adviser, compliance authority, or autonomous execution system.
In a Devancore-style workflow, a user can ask a question over entitled records. The system maps the prompt to a financial object, retrieves controlled data, cites the source, and shows whether the request is informational or action-oriented. If the request implies an action, the action is staged into workflow state rather than silently posted.
This creates one operating thesis across front office, middle office, back office, compliance, and reporting. The front office may ask about exposure or draft intent. Operations may ask about breaks, settlement, cash, and positions. Compliance may ask about approvals, surveillance items, and evidence. Reporting may ask which records support a figure. Each answer should resolve to source records and workflow state.
Devancore does not need to own every upstream or downstream system to support this model. The practical value is connecting source records, permissions, citations, staged actions, approvals, and outcomes so that conversational access strengthens the operating record rather than creating a side channel.
That is the standard for the broader conversational finance cluster. Conversational finance defines the interface. Conversational finance ops applies it to post-trade operations. AI agent post-trade operations applies it to prepared multi-step work. Later pages can cover natural-language trading, chat-based trade capture, conversational books and records, AI audit trails, and controlled tool access.
Related terms
- 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.
- 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.
- Post-Trade Operations Software
https://devancore.com/glossary/post-trade-operations-software/
Technology automating post-execution back-office workflows — trade capture, confirmation, settlement, reconciliation, position management, and regulatory compliance.
- 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.
- 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.
- 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.
- 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 Break Management
https://devancore.com/glossary/trade-break-management/
The exception workflow for identifying, classifying, and resolving post-trade discrepancies before they breach the T+1 affirmation cutoff or trigger CSDR cash penalties.
- Trade Reconciliation
https://devancore.com/glossary/trade-reconciliation/
The systematic comparison of internal trade and position records against external sources to identify breaks and resolve them before they become settlement failures.
- Failed Trade Settlement
https://devancore.com/glossary/failed-trade-settlement/
A trade that does not settle on its contractual settlement date because one party cannot deliver the required securities or cash, triggering penalties and buy-in procedures.
- Investment Book of Record
https://devancore.com/glossary/investment-book-of-record/
The IBOR — a real-time position record used by investment managers, capturing unsettled trades, accruals, and corporate actions ahead of custodian confirmation and ABOR settlement.
- Position Management Securities
https://devancore.com/glossary/position-management-securities/
The real-time tracking of a firm's securities holdings across all accounts and custodians, updated as trades execute, settle, and corporate actions are applied.
- Cash Reconciliation Software
https://devancore.com/glossary/cash-reconciliation-software/
Software that matches a broker-dealer's internal cash ledger against bank statements and clearing utility records in real time, surfacing breaks for resolution before they create reserve formula errors, missed sweeps, or Rule 15c3-3 violations.
- Regulatory Reporting — Securities
https://devancore.com/glossary/regulatory-reporting-securities/
The post-trade obligation to submit structured trade data — transactions, positions, and order lifecycle events — to regulators under MiFID II, EMIR, Dodd-Frank, and CAT to establish the supervisory record of each trade.
- Financial Transaction Reconciliation
https://devancore.com/glossary/financial-transaction-reconciliation/
The three-way match between sub-ledger, general ledger, and external statement that validates balance sheet integrity — with every break tracked as gross exposure for Rule 17a-5 and Rule 15c3-1 compliance.
- 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.
Contact
Request a briefing or platform walkthrough with the Devancore team.
Request access https://devancore.com/access/