← Glossary

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.

Conversational finance — interface to control map

Devancore · message matrix

Rail Message Purpose Record
Front office intent and context staged workflow portfolio question, order intent, exposure view, account scope, restrictions, and user permission
Post-trade operating state exception control positions, cash, confirmations, settlement status, reconciliation breaks, and workflow owners
Compliance review evidence supervision policy, approval, exception, surveillance item, disclosure support, and audit trail
Reporting cited output explain record report line, calculation run, source version, as-of time, adjustment, and signoff
Action layer draft or block control boundary query-only answer, staged action, maker-checker approval, downstream event, and retained evidence

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.

In Devancore™

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.