Rule document template for trading bot requirements

How to use it. Copy the sections below into your own document and replace each [bracket] with your answer. "None" and "does not apply" are answers; a blank is not. Keep API keys and passwords out of it. You do not need to send this with your first message: it comes in during discovery, the first stage in how we work.

This document is your half of a trading bot specification. It says what your rules are. The other half, the scope document, says what the software does with them, how it behaves when something fails and how each requirement is checked.

There is deliberately no filled-in example. Any example rule or value could be read as a suggestion, and strategy and investment decisions are yours.

When a rule is ready

A rule is ready when two people, given the same data, reach the same action without asking you anything. Every rule should fit this shape:

R-__: When   [exact condition, with every value stated]
      on     [instrument]
      using  [data source, field and interval]
      during [time window, with time zone]
      then   [action]
      with   [order type, quantity rule and time limit]

Before you move on, check each rule for these problems:

• Vague words. Replace words such as soon, about, strong, weak, high, low, large, small, recent, normal, usually and if needed with a definition or a number of your own.
• Unnamed data. Say which feed, which field and which interval the rule reads. Say when a period counts as closed.
• Missing "otherwise". Say what happens when the condition is false, when the data is missing and when an order is already open.
• Collisions. Say which rule wins when two are true at the same moment.
• Judgment. If you would look at the market and decide, the rule is not written yet. Software cannot apply a judgment you have not defined.

1. About this document

2. Account and platform

Fincode builds for your own account and declines projects that run on other people's accounts, copy trades or sell signals. Which platforms you can use depends on the law of your country and the platform's terms.

3. Instruments

4. Data the rules read

Repeat this block for each input a rule reads.

5. When the rules run

6. Entry rules

Repeat this block for each entry rule, and give each one its own ID.

7. Exit rules

Repeat this block for each exit rule, and give each one its own ID.

8. Quantity

9. Order handling

Answer once if the answer holds for every rule, or once per rule if it does not.

10. Risk limits

These limits run independently of your rules, and in production they are enabled by default. The values are yours: Fincode does not suggest them. See other controls in the software.

11. Failure behavior

The scope document sets the technical handling, such as checking an order's status before anything is resent. Here you decide what those events mean for your account and who deals with them.

12. People and notifications

13. Worked cases

Worked cases show what you expect in specific situations, using your own records. Write at least one case per rule, plus cases where nothing should happen and cases where two rules are true at once. They become acceptance checks: the software's decision has to match yours.

14. Change log

Once development starts, a new version of this document is handled as a change to the scope, because tests depend on it.

15. Your statement

These rules are mine, and Fincode did not suggest them. The account they run on is my own or my company's. Strategy and investment decisions are mine. I understand that tests show how the software behaves, not future results, and that trades can lose money.

Plain-text copy

The same template as plain text, for pasting into any editor.

RULE DOCUMENT

1. ABOUT THIS DOCUMENT
Rules written by: [name and role]
Version and date: [version, date]
Who can change these rules: [name and role]
Who approves project stages: [name and role]

2. ACCOUNT AND PLATFORM
Exchange or broker: [platform name]
Account holder: [you or your company]
Country of the account holder: [country]
Account or product type the rules use:
  [as the platform names it]
Does the software touch anyone else's account or money?
  [yes or no]
What the platform's API terms say about this use:
  [what you read, with the date]
Where the software will run: [your server or cloud account]

3. INSTRUMENTS
Instruments the rules apply to:
  [list, exactly as the platform names them]
How an instrument is added or removed:
  [who decides, and how the software is told]
If an instrument is suspended or delisted, or its trading
rules change:
  [what the software does]

4. DATA THE RULES READ (repeat for each input)
Input name: [the name your rules use for it]
Source: [which feed or endpoint]
Field: [exactly which value]
Interval: [your interval]
Time zone: [your time zone]
When a period counts as closed: [your definition]
History needed before the first decision:
  [how much, and from where]
If the data is missing, late or looks wrong:
  [what the software does]

5. WHEN THE RULES RUN
Days and hours: [days, hours and time zone]
Platform maintenance or closed periods:
  [what the software does]
At start-up, if a condition is already true:
  [what the software does]
At the end of a session or day:
  [what happens to open orders and positions]

6. ENTRY RULES (repeat for each rule)
Rule ID: [R-__]
Applies to: [instruments]
Active during: [time window]
Condition: [exact condition, with every value stated]
Data read: [input names from section 4]
Action: [what the software does when the condition is true]
Order: [see section 9]

All entry rules:
If two entry rules are true at once:
  [which one acts, and why]
If a rule is true while a position is already open:
  [what happens]
After an exit, when the same rule may act again:
  [your definition]

7. EXIT RULES (repeat for each rule)
Rule ID: [R-__]
Applies to: [which positions]
Active during: [time window]
Condition: [exact condition, with every value stated]
Data read: [input names from section 4]
Action: [what the software does when the condition is true]
Order: [see section 9]

All exit rules:
If an entry rule and an exit rule are true at once:
  [which one acts, and why]
If a risk limit blocks new orders, are exits still allowed?
  [your decision]
What else can end a position: [your list, or none]

8. QUANTITY
Formula: [your formula, with every input named]
Balance or value it reads, and when:
  [which value, at what moment]
Rounding: [your rounding direction]
If the result is below the platform's minimum:
  [what the software does]
If the result is above a risk limit:
  [what the software does]

9. ORDER HANDLING (once, or once per rule)
Order type: [as the platform names it]
Price the order uses:
  [your definition, if the order type needs a price]
How long an unfilled order may stay open:
  [your time limit, or none]
If partly filled at the end of that time:
  [what happens to the rest]
If the platform rejects the order: [what the software does]
When an open order is replaced or canceled:
  [your conditions]

10. RISK LIMITS (answer these four lines for each limit below)
  Value: [value]
  How it is measured: [definition]
  When it is reached: [what happens]
  Who can reset it: [name]
Limits to cover:
  Maximum order size
  Maximum position per instrument
  Maximum total exposure
  Loss limit per day (say which amounts count, and when the
    day resets)
  Maximum orders in a period (say which period)
  [any other limit you want]

11. FAILURE BEHAVIOR (answer these three lines for each event)
  What the software should do: [your decision]
  Who is told: [name]
  Who may restart it: [name]
Events to cover:
  The platform returns errors or cannot be reached
  An order's outcome stays unknown
  Live data stops or goes stale
  The software restarts with a position or an order open
  The software's records differ from the platform's
  The server's clock is wrong
  A risk limit is reached
  The emergency stop is used (say what happens to open orders
    and to positions)

12. PEOPLE AND NOTIFICATIONS
Who receives alerts: [names]
Alert channel: [your channel]
Who may use the emergency stop: [names]
Who may release a freeze: [names]
Who is reachable outside working hours: [names, or nobody]

13. WORKED CASES (at least one per rule, plus cases where
    nothing should happen and where two rules are true at once)
Case: [C-01]
Date and time: [date, time, time zone]
Data values: [values from your records]
Expected action: [action, or no action]
Rule: [R-__]

14. CHANGE LOG
Version: [version]
Date: [date]
What changed: [rule IDs and what changed]
Approved by: [name]

15. STATEMENT
These rules are mine, and Fincode did not suggest them. The
account they run on is my own or my company's. Strategy and
investment decisions are mine. I understand that tests show
how the software behaves, not future results, and that trades
can lose money.
Name and role: [name and role]
Date: [date]

This template is general information about writing software requirements. It is not investment, legal or tax advice, and it recommends no rule, instrument, parameter or platform. Fincode is a software company and does not provide investment advice, portfolio management or crypto asset services.