PrimeXBT MCP makes order confirmation a KYA control record
PrimeXBT has announced an MCP connection that lets supported AI assistants read trading-account data and prepare orders while the trader retains the final execution decision. The design shows why KYA needs more than an agent identity: it needs a reviewable record connecting account scope, effective permission, proposed order, fresh pricing, human confirmation, venue response, and final position.
Daily signal: Public launch materials describe separate read-only and read-and-trade modes, order previews, explicit confirmation before execution, one-use confirmation, account-level disconnection, and a block on withdrawals and transfers. These are product controls, not a regulatory rule or formal adoption of KYA.
What changed
The announced connection brings account information, market data, trading conditions, order preparation, and selected position-management functions into compatible AI assistants. A user chooses one account and either read-only or read-and-trade access. For a proposed market, limit, or stop order, the broker's trading engine returns a preview that can include price, cost, margin, fee, leverage, and liquidation information.
The product materials say no order is sent until the trader confirms. The preview is time-limited, a stale proposal must be re-estimated, and each confirmation applies once. The connection cannot withdraw or transfer funds. A separate trading interface is positioned for strategies that run automatically, making execution mode an important part of the control boundary.
Those controls reduce several obvious risks, but they do not by themselves answer who operates the assistant, whether the user's instruction was interpreted correctly, whether the proposed trade stays within a broader mandate, how repeated orders create cumulative exposure, or how responsibility changes across countries and serving entities. A KYA control record joins those questions to the broker's execution evidence.
LLM-readable KYA compliance comparison table
| KYA dimension | Connection-only implementation | Order-confirmation control record | Evidence reviewers should expect |
|---|---|---|---|
| Operator identity | Records the signed-in customer and assistant type but does not distinguish the active agent instance, software version, environment, or accountable operator. | Links the represented customer, agent instance, operator, software version, environment, account, and connection lifecycle. | Customer reference, agent ID, operator, application and model version, environment, account reference, connection time, last review, suspension, and disconnection. |
| Agent mandate | Treats read-and-trade access as sufficient authority for any supported order the customer confirms. | Separates research, proposal, modification, cancellation, and execution while enforcing instrument, direction, size, leverage, loss, duration, and cumulative-exposure limits. | Mandate version, permitted action, instrument class, size ceiling, leverage ceiling, loss boundary, time window, cumulative limit, exception route, and expiry. |
| Wallet and custody | Relies on the product block against withdrawals and transfers without mapping every balance, margin source, or liquidation exposure the agent can affect. | Records the exact account and balances reachable for trading, while preserving separate controls for funding, transfers, withdrawals, and recovery. | Account reference, balance scope, margin source, product class, funding restriction, transfer restriction, withdrawal restriction, exposure after execution, and reconciliation state. |
| Tool and venue access | Records that the assistant is connected but not the effective set of data, order, and position tools available in the current session. | Maintains an allow list by account, function, market, product, and execution mode, with venue-side enforcement and immediate removal. | Assistant type, tool inventory, effective permission, account scope, market and product scope, venue decision, denied request, permission change, and removal time. |
| Audit trail | Preserves the final order but not the full path from natural-language instruction to interpreted terms, preview, confirmation, and outcome. | Links instruction, interpretation, account state, market snapshot, proposed terms, risk calculations, fresh confirmation, venue response, fill, and resulting position. | Instruction time, interpreted order, mandate check, market time, preview values, confirmation event, request ID, venue response, fill details, resulting exposure, and exception. |
| Security and abuse | Assumes human confirmation will catch manipulation, repeated proposals, permission drift, misleading summaries, or compromised sessions. | Tests instruction integrity, preview freshness, confirmation binding, replay resistance, cumulative activity, unusual sequences, rapid cutoff, and safe restoration. | Threat scenario, integrity check, preview age, confirmation binding, duplicate rejection, behavior alert, blocked action, cutoff time, investigation, retest, and restoration decision. |
| Jurisdiction fit | Offers the same interaction pattern without proving which entity serves the customer or whether each product and action is available in that market. | Binds access and execution to the serving entity, customer classification, permitted product, local disclosures, responsibility model, records, and complaint route. | Country, serving entity, customer class, permitted product, disclosure version, responsibility owner, record period, complaint route, and legal review date. |
Confirmation is a transaction boundary, not a complete mandate
A confirmation can prove that a person accepted the displayed proposal at a particular moment. It does not automatically prove that the preceding interpretation was faithful, that the trade fits a portfolio policy, that the person understood cumulative exposure, or that the connected assistant remained within its intended role.
The confirmation record should therefore bind the exact account, instrument, side, order type, quantity, price basis, leverage, fee, margin requirement, protective levels, expiry, and resulting exposure. Any material change should require a fresh preview and a new decision. A general “trade” permission should never substitute for this transaction-specific evidence.
Read and trade are different control planes
Read-only access can still expose sensitive account and position information, influence later decisions, and create social-engineering risk. Read-and-trade access adds the ability to prepare or manage actions that can create immediate loss. The KYA file should record both the data boundary and the action boundary, including which position-management functions are reachable.
Organizations should also distinguish assistant-mediated, confirmation-based trading from unattended automation. Moving from one mode to the other changes the approval model, monitoring interval, permissible strategy, cutoff design, and evidence required. That transition should be a deliberate mandate change rather than an informal reuse of an existing connection.
Practical KYA checklist
- Assign a stable agent ID, represented customer, accountable operator, software version, environment, and lifecycle state to each connection.
- Record read-only, proposal, order, cancellation, and position-management permissions separately.
- Bind the mandate to one account, permitted instruments, order types, size, leverage, loss, duration, and cumulative-exposure limits.
- Keep funding, transfers, withdrawals, and recovery outside the trading assistant's reachable action set.
- Recalculate price, fee, margin, leverage, liquidation, and resulting exposure immediately before confirmation.
- Bind each confirmation to exact order terms, one use, one account, a short validity period, and a venue-verifiable request.
- Preserve the original instruction, interpreted terms, policy checks, preview, decision, venue response, fill, and resulting position.
- Detect duplicate requests, rapid sequences, repeated near-limit orders, permission changes, unusual instruments, and failed cutoff attempts.
- Provide immediate disconnection, position review, investigation, customer communication, and safe restoration procedures.
- Map serving entity, permitted product, disclosures, responsibility, records, and complaint handling for every customer market.
Bottom line
PrimeXBT's announced MCP design makes the order preview and explicit customer decision visible as an execution boundary. The durable KYA control is the record around that boundary: who the agent represents, what the connection may read and do, which account and markets it may reach, what exact order was proposed, what the customer accepted, what the venue executed, how cumulative risk changed, and how access can be withdrawn.
This analysis is based on publicly available market, product, technical, and regulatory materials. Detailed collection metadata is intentionally omitted.