How do you implement a broker dealing desk copilot?

Choose a desk workflow with a clear decision boundary

A dealing desk copilot should answer a precise operational question: what changed in exposure, which execution exceptions need investigation, or what must the next shift know? Start with one workflow and name the desk owner who will accept the result. An unrestricted chat box over every brokerage system makes it difficult to prove whether an answer is complete, current or within the user's authority.

Discovery should follow an actual shift. Observe how dealers move between the trading platform, bridge, liquidity-provider reports, risk dashboards and incident notes. Record the questions they ask, the evidence they consult and the actions they may take. Separate factual retrieval from calculations, interpretation and decisions. A useful first release can assemble an investigation pack while leaving trade handling and risk decisions with authorised staff.

Define the source contract before connecting a model

The following is a design checklist, not a promise that every broker or platform exposes these fields. Confirm the available interfaces, licence terms and identifiers during discovery.

Agree the source of truth for each field and show its freshness in the copilot interface.

Build a retrieval and tool layer the desk can inspect

Use an ingestion layer to normalise platform events without losing the original identifiers or timestamps. Store operational facts separately from indexed documents. A trade query should call an approved, parameterised tool; a question about an escalation procedure should retrieve the relevant runbook passages. The assistant combines those results into an explanation and links back to the evidence, rather than treating a language model's recollection as an operational record.

Keep the model outside the calculation boundary. Exposure, limits and exception rules belong in tested services that return structured results. The model can explain a limit breach returned by that service, but it should not invent a threshold or infer a missing position. Include the reporting currency, valuation time, selected accounts and any excluded records alongside the answer so a dealer can reproduce its scope.

Permission checks must run for every tool request and retrieved document. Do not rely on a prompt telling the assistant which accounts it may see. Apply the user's desk, entity and account permissions before returning data, then retain an audit record of the request, tool inputs, source versions and answer. Minimise personal data in both the interface and model input.

Design the answer around an investigation

A desk answer should make the next human action clear. Use a consistent evidence panel rather than a paragraph that sounds confident but cannot be checked.

• State the question, time window and account or instrument scope before the conclusion.
• Show the relevant calculation output, supporting events and direct links to the originating records.
• Distinguish observed facts, possible explanations and missing evidence. A suggested cause remains a hypothesis until investigated.
• Show stale or incomplete feeds prominently. Refuse a definitive current-state answer when the required source is unavailable.
• Offer a draft escalation or shift note with an owner and evidence references; require a person to review and send it.

Keep actions behind explicit operating controls

The first release should not change account groups, routing rules, limits or live orders. If later work introduces actions, define each one as a narrow tool with an explicit permission check, validated inputs, a preview and human approval. Approval must refer to the exact proposed action; a general instruction to 'manage risk' is not a usable authorisation boundary.

Treat retrieved text, client messages and imported incident notes as data. They must not override system instructions or authorise tool calls. Test malicious or misleading text inside those sources, and confirm that the assistant cannot reveal another entity's records. Legal and compliance owners should determine the relevant obligations and retention requirements; the implementation should provide the controls and evidence they specify.

Agree acceptance tests before the pilot

Create an evaluation set from approved historical investigations and realistic synthetic edge cases. Cover a normal shift, partial fills, amended records, duplicate events, delayed prices, an unavailable counterparty feed and an account outside the user's permissions. Have desk reviewers define what a correct answer must contain and when the assistant must decline. Keep sensitive examples in an approved environment with the same access controls as the underlying records.

Measure answer correctness, evidence coverage, freshness handling and permission enforcement separately. Set acceptable response times and escalation behaviour against the desk's actual workflow rather than copying a generic AI benchmark. A fluent explanation that cites the wrong account is a failed test. Record failures, repair the relevant tool or retrieval rule, and rerun the affected cases before widening the pilot.

Hand over the operating system, not just the chat screen

The handover should identify who owns source connectors, calculation services, runbooks, evaluation cases and model configuration. Provide a runbook for stale data, connector failure, incorrect answers and access changes. Include a kill switch that disables the assistant while leaving the desk's established systems available, and a documented process for reviewing incidents and restoring service.

After launch, review rejected answers and dealer corrections with the desk owner. Version prompts, tools and source mappings, and evaluate changes before release. Monitor whether investigations can be completed with evidence and whether handovers preserve context. These observations help decide what to improve next without claiming that the copilot can replace dealer judgement or guarantee a trading outcome.