For institutional traders

Who this is for and what changes at scale

McCortex OI serves trading desks, family offices and active management teams that need more from a workspace than a single trader typically requires. At scale, the questions change. Instead of asking whether a strategy can be deployed, teams ask how many strategies can run in parallel, how risk limits are coordinated across them, and how the output can be reconciled against internal books. McCortex OI for institutionals addresses that shift by keeping the same underlying workspace but widening its configuration surface: more strategies running concurrently, more granular risk controls per allocation, and reporting built to be exported rather than only viewed on screen.

This is not a separate platform bolted onto the retail product. It is the same execution engine and the same risk gate, opened up so that a desk can run several mandates side by side without losing sight of any one of them. Institutional trading in this sense means predictable behaviour under load: the same rules apply whether one strategy is live or a dozen are, and the workspace does not require a trader to babysit each position individually. What changes is coordination, not the underlying logic.

Adults using this workspace should treat it as a tool for managing exposure, not as a substitute for internal risk policy. Trading digital assets carries substantial risk, including the total loss of capital, and nothing here should be read as investment advice. Institutional users are expected to apply their own governance on top of what the workspace provides.

Execution infrastructure and server-side strategy hosting

Every strategy on McCortex OI runs on our servers rather than on a trader’s device. For an institutional desk this matters in a specific way: a strategy that has been configured, risk-limited and deployed keeps operating on schedule regardless of what is happening on any individual workstation. A laptop can be closed, a connection can drop, a team can rotate through shifts, and the strategy continues to execute according to the parameters it was given.

This server-side model also underpins how multiple strategies coexist. Each one is hosted independently, with its own risk limits and its own execution path, so that an issue affecting one allocation does not cascade into another. We do not publish specific figures for throughput or response times, since these vary with configuration and market conditions, but the architecture itself is built around continuity: strategies are meant to keep running through ordinary operational disruption on the user’s side, not to depend on a single machine staying online.

Execution infrastructure at this scale is deliberately unglamorous. There is no manual intervention step between a strategy’s signal and its order unless the desk has configured one. The value for an institutional user is consistency: the same execution logic applies to the first strategy deployed and the fiftieth, which makes it easier to reason about behaviour across a growing book.

API access and integration

Institutional accounts can connect to McCortex OI through an API layer designed to sit alongside existing internal tooling rather than replace it. Desks that already maintain their own risk dashboards, order blotters or reconciliation scripts can pull position and execution data programmatically instead of relying solely on the browser interface. This is particularly relevant for teams running several strategies at once, where manual checking does not scale well.

The API surface covers the same core actions available in the workspace itself: deploying and adjusting strategies, setting or updating risk limits, and retrieving execution and position data. Access is provisioned per account during onboarding, with credentials scoped to that account rather than shared across a firm’s broader infrastructure. Integration is intended to be additive: a desk can continue using the browser workspace for day-to-day configuration while routing reporting or monitoring through its own systems via the API.

We do not present the API as a substitute for the risk controls built into the workspace itself. Limits configured through the interface or through the API are enforced by the same server-side risk gate before an order is placed, so programmatic access does not bypass the checks that apply to manual configuration. This keeps behaviour consistent regardless of which access method a team prefers to use day to day.

Reporting and oversight

Oversight at institutional scale depends on being able to see everything in one place without hunting across separate tools. McCortex OI consolidates position data, execution history and per-strategy performance into a single reporting view, so a desk running multiple mandates can review them together rather than strategy by strategy. This is designed to support internal review cycles: a team can pull a consistent data set at whatever cadence its own governance requires.

Reporting covers what has actually happened rather than projections. Fills, open positions, applied risk limits and any limit breaches are recorded and made available for export, which matters when a desk needs to reconcile the workspace against its own books or present activity to internal stakeholders. Alerts on fills and limit events are configurable, so oversight does not depend on someone actively watching a screen at all times.

We are deliberately specific about what this reporting is not. It is not a custody statement, and it does not represent a segregated account structure. The workspace reports on activity that took place within it; how a desk classifies and holds the underlying capital remains a matter for its own arrangements outside the platform. Past performance and any illustrative figures shown in reporting do not guarantee future results.

How onboarding works

Onboarding for institutional accounts follows the same basic sequence as a standard account, adjusted for the additional configuration a desk typically needs. An account is created, and a verification step is completed with an account manager who can also discuss how the workspace should be configured for the desk’s intended use, including how many strategies will run and how risk limits should be structured across them.

Once verification is complete, the account is funded and the desk selects which strategies to deploy and at what risk limits, either through the browser workspace or via API once credentials are provisioned. Because configuration at this stage determines how the risk gate behaves later, the account manager conversation is where most of the setup work happens rather than afterward.

Throughout onboarding, the same underlying principle applies as elsewhere on McCortex OI: the workspace provides execution infrastructure, reporting and configurable risk controls, and the desk retains responsibility for the trading decisions built on top of them. Institutional users should treat onboarding as the point to align internal policy with what the platform can and cannot do, rather than an administrative step to move past quickly.