The Intelligence Developer Platform is infrastructure for building AI trading applications: a trading harness, MCP connectivity, model orchestration, and tool connectors governed by permissions, guardrails, and audit logs. It is the developer-facing layer beneath Coiny's AI trading intelligence platform — the same models and the same connectors, exposed as something your engineers build on rather than a product they consume.
A runtime that hands a model a bounded set of tools, checks every call against the agent's scope and the operator's limits, and holds the credentials the model never sees.
Market data, portfolio, research, risk, trading and operations exposed as Model Context Protocol servers, so any MCP-capable client or agent framework reaches them without a bespoke integration.
Deny by default per tool, venue, instrument and size, with pre-trade checks, rate limits, approval gates and a kill switch enforced by the platform rather than by the prompt.
Runs in your VPC or a dedicated tenant, with every prompt, tool call, argument, verdict and approver written to an exportable audit trail as the run happens.
An agent that can trade is only as trustworthy as what sits between it and the matching engine. That middle is the product: four layers your team configures, none of which a model can talk its way past.
A router picks the model for each task by capability, cost and latency, and falls back when a provider is unavailable. GPT, Claude, Gemini and Grok are all available, and swapping the model behind a workflow changes neither its tools, nor its permissions, nor the shape of its audit record.
Models on the left, the harness in the middle holding permissions, guardrails, approvals and the audit log, MCP connectors on the right, and the exchange core underneath — reachable only through the REST and WebSocket APIs.
Every connector ships as an MCP server with typed tools and read-only resources. Registering one makes it available to the harness; granting it to a role makes it visible to that role's model. Nothing is exposed by default, and an internal MCP server your team writes lands under the same scoping, rate limits, approval rules and audit trail as the connectors below.
Order books, trades, candles, instruments and funding for every market your platform runs, at the resolution the exchange stack records them.
Positions, balances, open orders and P&L, scoped to the accounts a given agent is bound to rather than to the whole book.
News, on-chain metrics, filings and your own internal documents, so an agent builds context without anything leaving the permission boundary.
Pre-trade checks, exposure and limit queries. An agent can price and screen a proposal against the deployment envelope before a person ever sees it.
Place, amend and cancel orders through the same engine your traders use. Scoped per agent by venue, instrument and size, and gated by the operator's approval threshold.
Internal transfers, settlement preparation, and promoting or halting a strategy. Write tools that always sit behind a named human approval, whatever the agent proposes.
The question this page has to answer is not whether an agent can trade. It is what stops it. Every control below is enforced by the platform rather than by instructions in a prompt — a model told to ignore a limit still cannot exceed it.
| # | Control | Where it is enforced | What happens when it binds |
|---|---|---|---|
| 1 | Tool visibility | Harness, before the model sees the tool listdeny by default | A tool the role was never granted does not appear, so the model cannot request it |
| 2 | Scope check | Harness, on every callvenue, instrument, account | The call is refused, the connector is never reached, and the model is told why |
| 3 | Pre-trade limits | Risk service, before an order is stagedsize, notional, exposure | The proposal is rejected with the failing check named in the result |
| 4 | Price band | Exchange core, at order entrydistance from mid | The order is refused rather than quietly repriced |
| 5 | Call rate limit | Harness, per tool and per agentper minute | Further calls are throttled and the run is flagged for review |
| 6 | Approval threshold | Harness, before a write tool executesoperator-set | The action queues for a named approver and nothing leaves the harness |
| 7 | Kill switch | Harness and exchange coreone action | The agent halts and its working orders are cancelled |
| 8 | Audit write | Harness, as the run happensnot reconstructed later | Call, arguments, verdict and approver are recorded, refusals included |
Everything here is also an API call, so teams that live in code never have to open it. It exists so the people accountable for the money can see what the agents are permitted to do, and what they did.
A workflow is a sequence of steps, and each step declares the tools it is allowed to reach. The drafting step of a rebalance agent has no write tool at all; the submitting step has one, and it is marked as requiring approval.
Permissions are the product surface here, not a settings page buried three menus deep. An agent's role decides which tools exist for it at all, and every grant, change, call and approval belongs to one history.
The buyer here is the person who has to sign off on an agent touching the order book.
Engineers with a working agent prototype and no safe path to production. The harness supplies credential isolation and approval routing.
Quant teams that want models reading live market and portfolio state without handing them trading keys.
Operators already running the trading stack who want to offer agent tooling to their clients — no second integration, no second set of credentials.
The people who answer for what an automated system did: grants they can read, thresholds they set, a kill switch they hold, and a full run trace.
The intelligence layer is not a separate product bolted to the side. It reaches the same engines, the same market data and the same venue connectivity that the rest of Coiny's stack runs on.
MCP, the Model Context Protocol, is an open standard for connecting AI models to external tools and data through a common interface, so an application does not need a bespoke integration for every system it touches. In trading, Coiny Exchange exposes market data, portfolio, research, risk, trading and operations as MCP servers. An MCP-capable client or agent framework calls them as typed tools, while the harness hosting the connection decides which tools that agent is allowed to see.
You connect an AI agent to an exchange safely by never giving the model direct access: put a trading harness between them that holds the credentials, exposes only the tools that agent's role grants, checks every call against operator-defined scope and limits, and requires a named human approval above a set threshold. Coiny Exchange ships that harness with MCP connectors, pre-trade guardrails, rate limits, a kill switch, and an audit trail written as the run happens.
AI trading agents should have guardrails at four levels: tool permissions that are deny by default, scope limits on venue, instrument and account, pre-trade checks on order size, notional, exposure and price band, and a human approval gate above a threshold the operator sets, backed by call rate limits and a kill switch. On Coiny Exchange's Intelligence Developer Platform each of these is enforced by the platform rather than by prompt instructions, and every refusal is logged.
A trading harness is the runtime that sits between an AI model and a trading system. It assembles the model's context, presents a bounded set of tools, holds the API credentials the model never sees, checks each tool call against permissions and risk limits, routes anything above a threshold to a human approver, and records the whole run. Coiny Exchange's harness is the core of its Intelligence Developer Platform and hosts the MCP connections to the exchange.
Agents run autonomously only inside limits the operator defines, and any action above the approval threshold waits for a named person before it executes. Coiny Exchange's harness enforces scope, size, exposure and rate limits on every call, refuses anything outside them, and gives the operator a kill switch that halts the agent and cancels its working orders. Research and analysis workflows can run unattended; write actions stay governed.
Yes. Coiny Exchange deploys the Intelligence Developer Platform inside your own VPC or a dedicated tenant, so prompts, market context, portfolio data and internal documents stay within your boundary. Model orchestration, the MCP connectors, the permission model and the audit store all run in that environment, and the operator decides which model providers are reachable from it and how long run records are retained.
Model orchestration routes each task to a model chosen by capability, cost and latency, with a fallback when a provider is unavailable. Coiny Exchange's platform supports GPT, Claude, Gemini and Grok, and the model behind a workflow can be swapped without altering that workflow's tools, permissions or audit format, because the harness rather than the model owns the connection to the exchange.
Every action an AI agent takes on Coiny Exchange's platform is written to an audit trail as it happens rather than reconstructed from logs afterwards: the prompt and context, each tool call with its arguments, the harness verdict, refused calls and the reason for them, any approver who signed, and the resulting orders or fills. Records are exportable as structured data and retained for the period the operator configures.
Walk through the architecture with our engineers: the MCP connectors, the permission model, the guardrails and approval gates, private deployment, and what the audit trail hands your risk committee. Bring the prototype you already have.
Book a Demo
