Plain-language input
Describe instrument, timeframe, trigger, exit and risk budget in ordinary sentences. The description stays with the strategy.
STRATEGY DESIGN & TESTING
The AI Trading Strategy Builder That Ends in a Live, Governed Strategy
Traders write the idea in plain language. The workspace writes the explicit rules, tests them against history and against conditions history never showed, and hands an operator the evidence to say yes or no. Zero code, and a signature before capital moves.
5 stagesidea to live
Zero codeto build or edit
Human sign-offbefore capital
THE WORKFLOW
From a Sentence to a Governed, Live Strategy
Five stages, in this order, every time. Nothing skips ahead, and nothing reaches live capital without a named human approving it.
1
Describe the strategy in plain language
A trader writes the idea the way they would explain it to a colleague — instrument, timeframe, what opens a position, what closes it, how much to risk. No script editor and no ticket to the quant-dev queue.
2
Convert it into explicit trading rules
Every phrase becomes a named rule: universe, entry, exit, sizing, risk limits and filters. Rules are shown in full and editable, anything the description left out is flagged rather than assumed, and each edit makes a version.
3
Backtest and validate before deployment
Rules run against historical data with fees, funding and modelled slippage, then across rolling walk-forward folds, then a scenario library. The output is a robustness report with sensitivity and a look-ahead audit.
4
Approve with the evidence in front of you
The strategy enters an approval queue with its rule version, its report and any findings still open. An operator reviews both and signs off, or returns it. Which roles may author and approve is yours to set.
5
Deploy under operator-defined limits
Approved strategies deploy into an envelope you define: paper or staged capital first, allocated notional, venue scope, maximum position size and a daily loss limit that halts trading. A kill switch is one click away.
One Loop, From Description to Deployment
The same pipeline handles a first draft and a fifth revision. Design, validate, govern, deploy — then back to the top when anything changes.
INSIDE THE WORKSPACEEvery Stage Has a Screen
Every Stage Has a Screen
And Every Screen Has Evidence
Rule generation
Each phrase becomes a named rule with an explicit condition — indicators, filters and session windows included.
Readable rule sets
Rules read as structured conditions, not a script file, so a risk officer who has never written code can see what will trade.
Versioned drafts
Every edit creates a version with an author and a timestamp, and approvals are granted against a specific version.
Historical simulation
Rules run against historical data with taker fees, funding and modelled slippage, and again at harsher cost assumptions.
Walk-forward folds
Parameters are fitted on each training window and tested on the next one the strategy has never seen, with sensitivity reported.
Scenario replay
Volatility shocks, liquidity thinning, gaps through a stop, venue outages and regime changes replayed and reported individually.
Look-ahead audit
Rules are checked for reading data they could not have known at the time — the quietest way a result flatters a strategy.
Approval gates
A strategy cannot reach live capital without a signature against a specific rule version. You set how many approvers it needs.
Role permissions
Separate who may author a strategy from who may approve one and who may change its limits. Segregation of duties is a setting.
Deployment envelope
Allocated notional, position size, venue and instrument scope, and a daily loss limit that halts trading automatically.
Drift alerts and kill switch
Live behaviour is compared with the tested envelope and alerts when it diverges. Halting a strategy is a single action.
What the System Does, and What a Person Decides
The split is deliberate: the system does the mechanical work of turning words into rules and rules into evidence, and a person makes every decision that puts capital at risk.
| # | Stage | The system does | A person decides |
|---|---|---|---|
| 1 | Describe | Reads the description and maps every phrase to a candidate rulegaps are flagged, never inferred | What the strategy is actually trying to do |
| 2 | Convert to rules | Writes explicit entries, exits, sizing, limits and filterseach one versioned | Whether each generated rule is right — and edits it if not |
| 3 | Validate | Runs historical simulation, walk-forward folds and scenario replaysand reports what failed | Which findings are acceptable and which send it back |
| 4 | Approve | Assembles the evidence pack and blocks deployment until it is signedno override path | Whether it goes live at all, and who is accountable for that |
| 5 | Deploy and monitor | Enforces the limits, watches for drift from tested behaviour, raises alertshalts on breach | Capital, scope, limits — and when to stop it |
PRODUCT WALKTHROUGH
Watch the Workflow End to End
The recorded walkthrough — description, generated rules, validation report, approval, deployment — is in production. The workflow itself is live today: book a demo and we will run it on your instruments, with your limits, in a session.
No video available
Video Coming Soon
CONTROLS & AUDIT
Book a Demo
Operator Controls, Permissions and a Full Audit Trail
Deployment is a governed act, not a toggle. Every limit is set by the operator and enforced by the engine — a strategy can never widen its own envelope — and every decision along the way is written down with a name against it.
Approval policyChoose how many approvers a live deployment needs and which roles qualify. Approvals bind to a rule version, not to a strategy name.
Segregated rolesAuthor, approver and limit-owner are separate permissions. Whoever wrote a strategy need not be the person who lets it trade.
Hard limitsAllocated notional, position size, concurrent positions, venue and instrument scope, and a daily loss limit that halts trading on breach.
Drift monitoringLive behaviour is measured against the tested envelope and alerts when it leaves it, so degradation shows as a signal, not a loss.
Exportable audit trailRule edits, validation runs, open findings, approvals and limit changes with identity and timestamp, ready for review.
Venue and instrument scopeA deployed strategy trades only the venues and instruments the operator listed. Anything outside that list is rejected at the engine.
CONNECTED SYSTEMS
Where Strategy Design Sits in the Coiny Stack
Design strategies in plain language here, then run them on the systems that already execute for your platform.
BUILT FOR
Teams That Need Strategy Iteration Without a Quant-Dev Queue
The workflow suits anyone who has more strategy ideas than engineering capacity — and cannot let that become a governance problem.
Exchange operators adding a strategy product
Offer strategy creation to your own users under your brand, with operator controls, approval policy and per-user limits built in.
Trading desks without engineering capacity
Traders who can describe an idea precisely no longer wait on a development cycle to find out whether it survives history.
Funds and treasury teams under mandate
Mandates that require documented testing and named approval before deployment are satisfied by the workflow itself.
Risk and compliance owners
Read the rules that will trade, see the findings open at approval, and export the audit trail without asking for a rebuild.
COMMON QUESTIONS
Strategy Design & Testing — FAQ
A natural-language trading strategy builder turns a written description of a trade idea into explicit, machine-executable rules. In Coiny Exchange's Strategy Design & Testing workspace you write the idea in plain English — instrument, timeframe, entry condition, exit condition, sizing and risk limits — and the system produces a named rule for each phrase. Every rule is visible, editable and versioned, and anything the description left unspecified is flagged rather than guessed.
Walk-forward testing fits a strategy's parameters on one block of historical data, tests them on the next block the strategy has never seen, and repeats that across the whole sample. It matters because a single historical run can be tuned until it fits the past perfectly and still fails in future markets. Coiny Exchange's Strategy Design & Testing runs walk-forward folds as a standard stage and reports each fold's out-of-sample behaviour beside its in-sample result.
No. Strategy Design & Testing from Coiny Exchange is a no-code workflow: a trader describes the strategy in plain language and reviews the generated rules in a structured editor rather than a script file. Teams that prefer to work programmatically are not excluded — the same strategies can be driven through Coiny's research and deployment APIs — but nothing in the guided workflow requires a developer or a quant-dev queue.
A tested strategy is deployed through an approval gate rather than a switch. In Coiny Exchange's Strategy Design & Testing, an operator reviews the rule version and the robustness report, signs off under the workspace's approval policy, then sets the deployment envelope: paper or staged capital, venue and instrument scope, maximum position size and daily loss limits. The strategy runs inside those limits, and every later change re-enters the same loop.
A strategy robustness report summarises how sensitive a strategy's simulated result is to being slightly wrong. The report Coiny Exchange produces covers parameter sensitivity around the chosen settings, cost and slippage stress, regime dependence, trade-count sufficiency, and a look-ahead audit that checks whether any rule reads data it could not have known at the time. Open findings travel with the strategy into the approval queue.
Scenario testing replays conditions a historical sample may not contain — a volatility shock, thinning liquidity, a price gap straight through a stop, a venue outage, or a change of market regime — and records how the strategy's rules behave in each. Coiny Exchange runs scenario tests as a standard stage of Strategy Design & Testing, so an operator sees the failure modes before capital is committed rather than afterwards.
Approval rights are an operator setting, not a product default. Strategy Design & Testing lets an exchange or trading desk define which roles may author strategies, which may approve them, and how many signatures a live deployment requires. Coiny Exchange records each approval with the approver's identity, the rule version approved and the findings that were open at the time, producing an audit trail for internal and regulatory review.
SEE IT ON YOUR MARKETS
Bring a Strategy Idea. Leave With the Rules and the Evidence.
In a working session we take one of your ideas, write it in plain language, generate the rules, run the validation and walk through the approval and deployment controls on your instruments.
Book a Demo