Decentralised News · Agentic Finance · Decision research
By Heath Muchena · Source review 2026-11-13 · Instrument version 1.0.0
What Matters
- The AI label does not settle which service a trading arrangement provides.
- Record the asset scope, client instructions, order path and each provider’s role.
- ESMA’s MiCA answer carries across specified copy-trading guidance for service qualification only.
- The DN record identifies review questions and missing evidence; it does not issue a legal classification or verify authorisation.
DN Alpha Thesis
A fictional trading service lets a client choose a strategy, set a spending limit and cancel proposed trades before a short deadline. Its marketing calls that client control. The operational question is more precise: what happens when the client does nothing?
That question belongs inside a larger service assessment. ESMA’s current MiCA answer directs firms to examine their particular copy-trading model, using specified earlier guidance for qualification. Calling a workflow an AI assistant does not complete that assessment. [1]
This guide translates the boundary into an evidence task for product teams, reviewers and readers evaluating a service. The DN EU Copy-Trading Service-Scope Record maps declared facts to the next review question. It makes no finding about a named provider, investment return or licence. The claim to test is that a product’s visible controls describe its actual decision authority; the evidence is the mandate and order path.
DN Evidence Block
Evidence reviewed: 13 November 2026. Sources are official MiCA provisions, ESMA’s 2025 autotrading answer and the exact 2012 and 2023 material it references. No provider was inspected or classified. The scenarios are synthetic. The instrument uses self-reported categorical inputs and leaves legal conclusions unresolved. This is an EU service-scope guide; it does not establish US state rules or a universal requirement for AI reasoning logs.
Original DN instrument · version 1.0.0
DN EU Copy-Trading Service-Scope Record
Organise one reported EU trading workflow and identify the next evidence question. This record does not classify a service or verify any provider’s permission.
Enter your assumptions or load a labelled example. Required blank numbers stay missing; unknown evidence remains unknown. Use nonpersonal labels only. This instrument makes no network requests and uses no persistent browser storage.
Use your own inputs
No current result. Enter inputs or load an illustrative example.
Self-reported categorical facts only; no asset classification, legal verdict, suitability assessment, authorisation verification, external requests or personal client information.
Start with the asset and the client relationship
MiCA’s scope includes relevant crypto-asset services in the Union, but excludes crypto-assets that qualify as financial instruments. A token label therefore cannot choose the legal route. Record the asset assessment before applying a service analysis; a mixed product needs its components separated. [2]
Article 3 distinguishes several services. Portfolio management concerns discretionary, client-specific management under a mandate. Advice concerns personalised recommendations. Executing an order and receiving an order for onward transmission are separately defined activities. These distinctions make the actual relationship and sequence of decisions relevant. [3]
For an operational review, create one short description that names the contracting provider, intended client, asset set and permitted actions. Then list the assumptions you have not established. “The user owns the wallet” does not answer who decides which investment to make. “The bot runs locally” does not describe the commercial relationship. These are useful engineering facts, but an incomplete service description.
The worksheet asks you to report an asset assessment; it does not perform one. Selecting “financial instruments” routes the record to a separate framework review. Selecting “outside the EU” stops this article’s EU routing. Neither selection creates an exemption.
What the current ESMA answer actually carries across
ESMA’s MiCA Q&A 2463, answered on 7 April 2025, explains that copy trading is not a separately defined MiCA service. Firms must identify the services their particular arrangement provides. For that qualification exercise, ESMA points to the whole of Question 9 in its 2012 MiFID Q&A and sections 2.1 and 2.2 of its 2023 copy-trading briefing. It expressly confines this application to identifying the type of service. [1]
That boundary matters when constructing a review checklist. Read MiCA’s own requirements after assessing the relevant service. Do not paste the later MiFID briefing chapters into a MiCA compliance claim. The answer supplies a way to analyse a business model, not a declaration that every feature or obligation in two regulatory frameworks is interchangeable.
Keep a source-version note in the review file. A 2026 product release may change the workflow without changing the cited 2025 answer. Conversely, a revised regulatory answer may require reassessment even when the code remains unchanged. Record which change triggered the review instead of describing older guidance as a new rule.
Inspect the decision that reaches the order
The 2012 example concerns a client selecting third-party signal providers, after which their signals become orders without further client intervention. ESMA identifies portfolio management in that arrangement; a budget or loss limit does not change that characterisation. It contrasts this with required client action before each transaction, while recognising that other services can remain relevant. [4]
A useful evidence packet links a single proposed trade to its originating instruction. Save the version of the instruction that existed before the order, the system’s proposed action, any client response and the resulting submission. Preserve unsuccessful attempts and cancellations as well. A screenshot of a confirmation screen proves little if the production path can bypass it.
| Claim to examine | Evidence to request | Question left open |
|---|---|---|
| “The client decides every trade.” | A required affirmative response linked to each submitted order. | Can any supported path proceed without that response? |
| “The agent only follows instructions.” | The exact instruction, its author and the permitted changes. | Who chooses the asset, direction and timing? |
| “Risk limits keep the client in control.” | The limit configuration and the decision process within it. | Who makes the investment choice inside the limits? |
This table is DN’s proposed evidence method. It is not a statutory list of required logs and does not turn a transaction trace into a legal opinion.
An optional veto is different from an approval gate
The 2023 briefing addresses a client who can approve, modify or cancel during a time limit, after which the trade executes. In that example, client intervention is not necessary and the service is portfolio management. The briefing also explains that specific limits can coexist with automatic execution. Its analysis remains dependent on the business model. [5]
Test silence deliberately in an authorised simulation. Suppose a fictional service sends a proposed order and offers a ten-second cancellation window. If no response causes submission, call the feature an optional veto in the review record. The ten seconds are an illustrative design choice, not a regulatory threshold.
Now compare a second fictional service that expires the proposal and submits nothing without a client response. It has a different decision path. That difference is worth documenting, but it does not resolve whether personalised advice, order transmission or execution is being provided. An approval button is evidence about a step, not a complete description of the service.
Do not equate every automated rule with discretion
The 2012 Q&A also describes a client who fully specifies the detailed conditions for each signal or order, including the precise market trigger. That is a distinct example of a decision taken by the client. It should not be collapsed into the earlier third-party signal example. [4]
In a review packet, distinguish “follow whichever opportunities this strategy selects” from an instruction specifying the action and exact triggering condition. Ask whether the provider may substitute instruments, alter the condition, reinterpret a broad objective or update a model that changes the decision. Record those permissions rather than treating the word “algorithm” as an answer.
The instrument therefore has a separate route for reported fully specified client rules. Its output asks for the detailed instruction and change authority. It does not certify that the arrangement meets ESMA’s example. A template that silently fills in material choices is an obvious reason to examine what the client actually determined.
Map the providers before reviewing their permissions
ESMA’s briefing considers arrangements with more than one firm and explains that the roles can amount to different services. A signal provider, order-transmission service and executing firm should therefore not be treated as one undifferentiated platform. [5]
Build a separate row for every party that can change an instruction or cause an order to move. For each row, record the contract, decision authority, input, output and hand-off evidence. Then ask which party can stop an obsolete instruction from reaching the next stage. A clean user interface can hide several different contractual and operational boundaries.
MiCA Article 59 provides for authorised CASPs and eligible financial entities operating under Article 60. Authorisations under Article 63 specify services; adding services requires an extension process. A general claim that a business is regulated is not a service-specific assessment of this workflow. [6]
Use the exact legal entity and applicable service scope when checking permissions through the appropriate official sources. Save the check date and the product version it covered. This article does not verify any firm’s permission, and the worksheet never upgrades a self-reported review into a verified authorisation.
Keep suitability separate from strategy performance
For CASPs providing advice or portfolio management, MiCA Article 81 requires a suitability assessment that considers the client’s knowledge and experience, objectives, risk tolerance and financial capacity for loss. Where required information is missing or the service or asset is considered unsuitable, paragraph 11 restricts recommendations and starting portfolio management. [7]
A strong backtest cannot supply missing client facts. Nor can the same generic risk setting describe every client’s circumstances. Maintain separate review records for strategy evaluation, the client-service relationship and any applicable suitability assessment. The separation makes it easier to see whether an impressive performance chart is being used to answer the wrong question.
The public instrument deliberately collects no personal financial profile and performs no suitability calculation. A field saying that records are matched means only that the user reports having connected the relevant documents and traces. Sensitive client information belongs in the organisation’s authorised process, not in a public example or a shared JSON attachment.
Use the record to choose the next evidence request
Consider three synthetic cases. In the first, a provider’s strategy selects trades, the client can veto, and silence permits execution. The record directs attention to discretion and the mandate. In the second, the client reportedly specifies every detailed trading condition; the next task is to verify that instruction and who can change it. In the third, the asset assessment and client relationship are unknown; the record asks for those facts before giving a more specific review focus.
None receives a compliance grade. Even a fully completed record returns “Undetermined” for service classification and “Not verified” for authorisation. These outputs are intentional. The useful product is the traceable question for the reviewer, together with the assumptions that produced it.
If “affirmative client action required” is combined with “execution proceeds on silence”, the instrument rejects the contradictory inputs. Resolve which description matches the workflow. If the evidence itself is inconclusive, select unknown; do not choose the reassuring label merely to produce an output.
Keep the downloaded record alongside the controlled evidence references in your review system. The public worksheet stores a nonpersonal workflow label and categorical declarations, not your contracts or order history. Reopen the review when model authority, asset coverage, timeout behaviour, participating entities or relevant guidance changes.
Methodology and limits
The record first reads the reported EU context, asset assessment and client relationship. Unresolved scope keeps the output at a preliminary evidence request. Within a reported EU client service, a fully specified client instruction receives its own review route; other reported automatic choices point to discretion and mandate review, while required affirmative action points to the remaining recommendation and order-handling questions. Unknown action or silence behaviour remains unresolved.
The method is categorical and has no numerical units, weighted score or legal probability. It does not infer facts from a company name, wallet, token or model brand. A direct contradiction between required affirmative action and execution on silence is rejected. Other unknowns are retained and named. Every successful record keeps classification undetermined and authorisation unverified, including the synthetic examples.
This worksheet cannot resolve asset classification, territorial reach, exemptions, contractual interpretation, suitability, national supervisory practice or any provider’s permission. The reported workflow may omit material behaviour. Its review focus is an editorial aid for preparing evidence, not a substitute for a qualified assessment of the actual arrangement. No live register, account, order or external database is queried. The published examples are not observations of operating services.
Machine-readable record schema · 1.0.0
This JSON Schema documents the downloadable record, including input provenance, missing-value handling and method versions. The creation timestamp records the calculation time; it does not certify when the underlying evidence was observed.
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"$id": "urn:dn:record:dn-eu-copy-trading-service-scope-record:1.0.0",
"title": "DN EU Copy-Trading Service-Scope Record record",
"type": "object",
"additionalProperties": false,
"required": [
"schemaVersion",
"recordType",
"createdAt",
"articleSourceReviewDate",
"inputEvidenceStatus",
"inputBasis",
"exampleLabel",
"engineVersion",
"inputs",
"result"
],
"properties": {
"schemaVersion": {
"const": "1.0.0"
},
"recordType": {
"const": "dn-eu-copy-trading-service-scope-record"
},
"createdAt": {
"type": "string",
"format": "date-time"
},
"articleSourceReviewDate": {
"const": "2026-11-13"
},
"inputEvidenceStatus": {
"const": "user_entered_not_independently_verified"
},
"inputBasis": {
"enum": [
"user_entered",
"illustrative_example",
"illustrative_example_modified"
]
},
"exampleLabel": {
"type": [
"string",
"null"
]
},
"engineVersion": {
"const": "1.1.0"
},
"inputs": {
"type": "object",
"additionalProperties": false,
"required": [
"workflow",
"eu_scope",
"asset_route",
"relationship",
"instruction",
"client_action",
"silence",
"personalised",
"actors",
"mandate",
"records",
"authorisation"
],
"properties": {
"workflow": {
"type": "string",
"maxLength": 120,
"minLength": 1
},
"eu_scope": {
"type": "string",
"enum": [
"unknown",
"yes",
"no"
]
},
"asset_route": {
"type": "string",
"enum": [
"unknown",
"mica_assets",
"financial_instruments",
"mixed"
]
},
"relationship": {
"type": "string",
"enum": [
"unknown",
"client_service",
"own_account_only"
]
},
"instruction": {
"type": "string",
"enum": [
"unknown",
"third_party_signals",
"provider_choices",
"client_precise_rules"
]
},
"client_action": {
"type": "string",
"enum": [
"unknown",
"required_each",
"optional_veto",
"no_per_trade_action"
]
},
"silence": {
"type": "string",
"enum": [
"unknown",
"blocked",
"executes"
]
},
"personalised": {
"type": "string",
"enum": [
"unknown",
"yes",
"no"
]
},
"actors": {
"type": "string",
"enum": [
"unknown",
"single",
"multiple"
]
},
"mandate": {
"type": "string",
"enum": [
"unknown",
"current",
"missing"
]
},
"records": {
"type": "string",
"enum": [
"unknown",
"matched",
"description_only"
]
},
"authorisation": {
"type": "string",
"enum": [
"unknown",
"service_specific_review",
"general_claim",
"none"
]
}
}
},
"result": {
"type": "object",
"additionalProperties": false,
"required": [
"summary",
"metrics",
"findings"
],
"properties": {
"summary": {
"type": "string"
},
"metrics": {
"type": "array",
"items": {
"type": "object",
"additionalProperties": false,
"required": [
"label",
"value"
],
"properties": {
"label": {
"type": "string"
},
"value": {
"type": [
"number",
"string",
"null",
"boolean"
]
},
"unit": {
"type": "string"
},
"note": {
"type": "string"
}
}
}
},
"findings": {
"type": "array",
"items": {
"type": "object",
"additionalProperties": false,
"required": [
"level",
"text"
],
"properties": {
"level": {
"enum": [
"note",
"warning",
"error"
]
},
"text": {
"type": "string"
}
}
}
}
}
}
},
"allOf": [
{
"if": {
"properties": {
"inputBasis": {
"const": "user_entered"
}
}
},
"then": {
"properties": {
"exampleLabel": {
"type": "null"
}
}
},
"else": {
"properties": {
"exampleLabel": {
"type": "string",
"minLength": 1
}
}
}
}
]
}Related DN research
Frequently asked questions
Does a cancellation button mean the client decides every trade?
No conclusion follows from the button alone. Record whether an affirmative response is necessary and what happens on silence; then assess the complete arrangement.
Does every automated trading rule constitute portfolio management?
No blanket conclusion is justified. The referenced guidance distinguishes a client who fully specifies detailed transaction conditions from the automatic copying example. The actual facts still require review.
Does the MiCA answer import every requirement in the MiFID briefing?
No. Its cross-reference is expressly limited to service qualification and identifies the relevant material. Applicable MiCA obligations need their own analysis.
Can this record verify that a platform is authorised?
No. Even a reported service-specific permission review is unverified input. Check the actual entity and service through appropriate official sources and retain the dated evidence separately.
What should I enter if the product mixes different asset scopes?
Select mixed and separate the components for review. The worksheet cannot infer the framework from a ticker, token label or marketing description.
What changes should reopen a completed review?
Changes to decision authority, client approval behaviour, assets, provider roles, contracts or relevant official guidance can make an earlier record incomplete. Preserve the earlier version rather than silently rewriting it.
Sources and review dates
- ESMA MiCA Q&A 2463: Autotrading. Service qualification only; references all of 2012 Q&A 9 and 2023 briefing sections 2.1/2.2. Reviewed 2026-11-13. Source date: 2025-04-07.
- MiCA Article 2: Scope. Union scope and exclusion of financial instruments; no asset is classified by the article. Reviewed 2026-11-13.
- MiCA Article 3: Definitions. Client services, advice, portfolio management, order execution and transmission definitions. Reviewed 2026-11-13.
- ESMA 2012 MiFID Q&A, Question 9. Automatic third-party signals, client limits, required intervention and fully client-determined detailed conditions. Reviewed 2026-11-13. Source date: 2012-06-22.
- ESMA 2023 Copy Trading Supervisory Briefing, sections 2.1/2.2. Actual business model, multiple actors and optional-veto example; no blanket MiFID-to-MiCA conduct-rule import. Reviewed 2026-11-13. Source date: 2023-03-30.
- MiCA Article 59: Authorisation. Authorised CASP/Article 60 route and service-specific authorisation; no named firm checked. Reviewed 2026-11-13.
- MiCA Article 81: Advice and portfolio management. Suitability for the specified services and missing-information boundary; no public suitability assessment. Reviewed 2026-11-13.
Turn the finding into a decision
For a bounded review of the evidence and unresolved questions behind a specific operational decision, contact the DN Research Desk. Scope, feasibility, fee and delivery terms must be agreed before work begins.
Disclosure: This is independent DN editorial research. The instrument evaluates entered assumptions and does not independently verify your evidence or approve transactions. Illustrative examples are labelled. Any affiliate placement is identified where it appears; a commercial relationship does not determine the findings. No provider endorsement or guaranteed outcome is implied.
About the Author
