To build a modern buy-side equity trading desk, heads of trading and trading COOs should connect portfolio instructions, execution systems, analytics, and decision ownership. Start with the orders the firm needs to execute, then organize systems, controls, and team coverage around them.

That work includes resolving everyday problems, such as the following:

• A target position changes while an order is active.
• An account restriction delays execution.
• Updated cash balances have not reached the trading system.
• A connectivity problem prevents traders from accessing their systems.
• A regional handoff loses context.

Reviewing those problems gives leaders specific requirements for technology investment and clearer responsibilities for the people using it.

Define the desk's operating model

The trading operating model describes how people, systems, and controls turn investment instructions into executed positions. It covers order preparation, execution authority, allocations, and the review of outcomes.

Begin with the firm's strategies and order mix. A low-turnover asset manager working large positions over several days will have different requirements from a desk that manages frequent rebalances. Use those differences to set automation priorities, choose benchmarks, and plan staffing.

Assign responsibility for each stage. For example, portfolio updates need an owner, exceptions need an escalation route, and execution findings need a way to reach portfolio managers and broker reviews. Document these responsibilities before changing the systems that support them.

A good first exercise is to follow several representative orders from instruction to allocation. Record where traders wait, re-enter information, or ask colleagues to clarify what should happen next.

What should the O/EMS get right?

The order management system and execution management system, collectively O/EMS, should give traders current information and a reliable way to act on it. Test whether positions, cash availability, and account restrictions remain consistent as portfolios change.

During a public panel at Equity Leaders Summit (ELS) 2026, a Head of Trading and Operations at an asset manager suggested others treat accurate positions and updated cash flows as their start-of-day requirements. The practitioner also described how inconsistent trade dates across time zones could affect portfolio records and pricing.

Those requirements continue throughout the day. The same participant explained that revised allocations and targets could change active multi-day orders, creating substantial manual work when updates did not flow smoothly through the system.

Include the following cases in an O/EMS review:

• Portfolio changes: A cash flow or revised target alters the quantity required for an active order.
• Account restrictions: Accounts within a combined order have different handling requirements.
• Cross-market trading: Trade dates and position records remain consistent across regions.
• Unusual instructions: The trader can identify instructions that require review before execution.
• System interruptions: The desk can establish the current order state and follow an agreed recovery process.

Record the outcome of each test and assign unresolved problems to a business owner. This produces a better requirements list than asking users which features they would like.

Preserve the order's context

Execution records should retain the information needed to explain how an order was handled. Decide which instructions and handling choices analysts will need when reviewing costs or discussing results with portfolio managers.

Urgency, intended benchmark, and participation limits may be practical fields, depending on the order mix. Agree on their definitions and check that they remain available after the order passes between systems.

Public discussion at ELS 2026 addressed the need to transmit data throughout the day for trading, TCA, portfolio management, reporting, and compliance. Someone working a desk that reviews those connections needs to know whether a change made in one system has reached everyone who relies on it.

Test that continuity with completed orders. Compare the original instruction, subsequent amendments, and final analytics record. Where information disappears, identify whether the problem lies in the source field, the integration, or the reporting process.

Make global analytics comparable

A global desk should standardize the definitions it uses for oversight purposes, but it must do so while retaining the local detail needed to interpret results. Some good standards are to document benchmark methodology, timestamp treatment, and order classifications before comparing regional performance.

Then examine where market conditions require additional analysis. Auction structures, liquidity availability, and execution horizons can affect what a result means. Analysts should be able to explain those differences to the people using their reports.

One open discussion at ELS 2026 highlighted the operating costs of obtaining and interpreting market data, alongside the execution friction caused by limited visibility. Data budgets should therefore include the work required to maintain definitions, investigate gaps, and support users.

Smaller desks can start with a limited set of dependable reports. Prioritize analysis that informs a broker discussion, changes an execution choice, or identifies an exception worth investigating. Review whether each report still serves that purpose.

Include market structure in desk management

During a public ELS 2026 panel, a Head of Trading at an asset manager discussed how differences in trading hours and market development could increase demands on traders covering several regions.

Review market access alongside routing policies, analytics, and staffing. A desk needs to understand the conditions under which it can execute and the information available to assess the result. Traders need to have an in-depth understanding of the market structures in each country.

Identifying legal requirements

US-based desks planning to trade in another country should review both the trading arrangements and the legal requirements. Traders and market specialists should assess where orders can be executed, how those venues operate, and whether enough liquidity is available. Compliance staff should separately confirm which rules apply to the firm and what it must do to meet them.

Obtaining market data

The desk also needs enough market data to judge whether it can buy or sell the required quantity. This can be difficult with small-cap stocks, where trading activity may be limited or spread across venues.

During a public panel at ELS 2026, a trading leader at an asset manager explained that an incomplete view of available liquidity could lead the investment team to overlook a stock or decide it was unsuitable for the portfolio.

Confirming system support

Before giving traders access to an additional market, check that the desk's systems, data, and staffing can support it. Confirm that order checks are in place, market data is available, and support staff can respond during the relevant trading hours. Decide who has authority to approve or change an order when the portfolio manager or regional specialist is unavailable.

Learn from migrations and failures

There were a significant number of presentations and conversations about technology at the Equity Leaders Summit in 2026. However, two recommendations for technology projects are worth highlighting:

• Review accumulated requirements before migrating
• Test recovery arrangements before relying on a service.

Removing unneeded data

A Head of Trading and Operations at an asset manager described an OMS conversion as an opportunity to remove unnecessary work, beginning with "looking at all the historical processes and data that you don't need."

Apply that review to reports, manual adjustments, and recurring checks. Establish who uses each item and what control or decision it supports. Before retiring it, check downstream dependencies and applicable record-retention requirements.

"Design for fallback"

In a separate public fireside chat, a data-engineering and analytics director at an investment manager advised: "You always need to design for a fallback." The discussion also addressed event logging, capacity for activity surges, and testing before migration.

A recovery plan should explain how traders establish the current order state, which activity may continue, and who authorizes resumption. Rehearse those steps with trading, operations, and technology staff.

Prioritize investment by operating need

Each technology proposal should identify the task affected and the improvement expected. An integration that reduces repeated order amendments gives the desk a specific result to test.

Assess what the implementation is dependent upon and determine your potential ongoing support costs for the project alongside the proposed benefit. Include any period during which old and new systems must run together, and identify who will reconcile their outputs.

Leaders at ELS 2026 recommended examining existing problems before selecting a replacement architecture. They also suggested you distinguish between which situations are better suited to available products and which ones have specialized requirements that might justify internal development.

Apply the same discipline to AI proposals. A public panel at the event demonstrated leaders' interest in reporting assistance and better access to order information, while also describing capabilities that had yet to be implemented.

Treat those ideas as candidates for controlled testing, each with defined users and acceptance criteria.

Develop skills and realistic coverage

Team planning should specify which markets each trader can cover and which decisions they are authorized to make. Assess market knowledge, system competence, and escalation judgment separately.

During an Equity Leaders Summit 2026 panel, a Head of Trading described having colleagues spend time on other regional shifts to learn local market practices. The participant also discussed educating portfolio managers about the execution opportunities available outside their usual trading hours.

Use a skills matrix to identify primary and backup coverage. Pair less experienced staff with regional specialists, and test their understanding through representative orders and exception scenarios.

Review workload alongside those capabilities. Identify tasks that depend on one person, project work that competes with market coverage, and responsibilities that repeatedly fall outside scheduled hours.

Assigning backup staff is only effective if they have the access, knowledge, and authority to act.

A practical desk-review sequence

Use the following sequence to turn the review into a manageable programme of work:

1. Map representative orders. Follow instructions through controls, execution, allocations, and review. Record manual work and unclear ownership.
2. Check information continuity. Verify that portfolio changes and relevant order context reach each system that depends on them.
3. Examine analytics. Confirm definitions, comparison groups, and data coverage. Identify reports that lead to decisions.
4. Review market and staffing requirements. Compare execution capabilities with regional knowledge and backup coverage.
5. Test disruption scenarios. Include a data interruption, a system-access failure, and a handoff during an active order.
6. Select the next changes. Assign business owners, budgets, and acceptance criteria before approving development or procurement.

Keep the resulting priority list short enough to resource. Measure each change against its original purpose, such as reducing amendment effort, shortening exception-resolution time, or improving the completeness of order records.

Address problems before expanding

Finally, keep in mind that a migration can carry unnecessary steps into a replacement system if you accept every historical requirement without review. Ask who uses each output and what would happen if it were removed.

Aggregate analytics can also mislead. Investigate differences in order urgency, investment instructions, and local market conditions before using desk-wide averages to change broker allocations or execution guidance.

Include exceptions in automation testing. An unfamiliar instruction should become visible to a named reviewer, with a clear process for resolving it.

To begin, choose one representative order journey and correct the data gaps and unclear responsibilities it reveals. Use the findings to set the next O/EMS, analytics, and staffing priorities.

Frequently asked questions

Should a desk replace its OMS and EMS together?

The decision depends on system dependencies and the problems being addressed. Map the integrations and test whether a staged change can preserve order-state accuracy and controls. Agree on migration and recovery arrangements before choosing a sequence.

How can a desk judge whether a report is still useful?

Identify its user and the decision or control it supports. If its purpose is unclear, investigate downstream use before retiring it. A report may have oversight or retention requirements even when traders rarely consult it.

Can global desks compare execution performance across regions?

They can compare consistently defined measures while accounting for differences in order mix and market conditions. Document local adjustments and data coverage. Avoid treating a numerical difference as evidence of better execution until those factors have been examined.

What should an O/EMS acceptance test include?

Use ordinary orders alongside amendments, account-specific restrictions, and unusual instructions. Test data interruptions and system-access failures as well. The desk should know how exceptions become visible and who resolves them.

How should technical specialists learn trading requirements?

Pair them with traders who can explain representative orders and execution constraints. Use actual workflow cases to test their understanding of quantity, timing, and risk. Traders should also learn enough about system dependencies to report problems precisely.

What belongs in a desk modernization business case?

Describe the operating problem, the affected users, and the expected improvement. Include data dependencies, testing, support costs, and business ownership. Define acceptance criteria that can be checked after implementation.