# Rule document template for trading bot requirements

URL: https://fincodelabs.com/en/samples/rule-document-template · Publisher: Fincode (Fincode Yazılım ve Teknoloji A.Ş.), Istanbul, Turkey · Updated: 2026-11-06

A blank template for writing your own rules precisely enough to code and test. It holds no suggested rule, parameter or setting, and no real client's data: every value is yours to decide. Fincode checks that rules can be coded and tested; it does not choose them.

**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](https://fincodelabs.com/en/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](https://fincodelabs.com/en/samples/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

- **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]

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

- **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 this block for each input a rule reads.

- **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 this block for each entry rule, and give each one its own ID.

**One block per entry 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]

**Questions that apply to 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 this block for each exit rule, and give each one its own ID.

**One block per exit 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]

**Questions that apply to 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

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

- **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

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](https://fincodelabs.com/en/security).

| Limit | Value | How it is measured | When it is reached | Who can reset it |
| --- | --- | --- | --- | --- |
| Maximum order size | [value] | [definition] | [what happens] | [name] |
| Maximum position per instrument | [value] | [definition] | [what happens] | [name] |
| Maximum total exposure | [value] | [definition] | [what happens] | [name] |
| Loss limit per day | [value] | [which amounts count, and when the day resets] | [what happens] | [name] |
| Maximum orders in a period | [value and period] | [definition] | [what happens] | [name] |
| [any other limit you want] | [value] | [definition] | [what happens] | [name] |

## 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.

| Event | What the software should do | Who is told | Who may restart it |
| --- | --- | --- | --- |
| The platform returns errors or cannot be reached | [your decision] | [name] | [name] |
| An order's outcome stays unknown | [your decision] | [name] | [name] |
| Live data stops or goes stale | [your decision] | [name] | [name] |
| The software restarts with a position or an order open | [your decision] | [name] | [name] |
| The software's records differ from the platform's | [your decision] | [name] | [name] |
| The server's clock is wrong | [your decision] | [name] | [name] |
| A risk limit is reached | [your decision] | [name] | [name] |
| The emergency stop is used | [what happens to open orders, and to positions] | [name] | [name] |

## 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

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.

| Case | Date and time | Data values | Expected action | Rule |
| --- | --- | --- | --- | --- |
| [C-01] | [date, time, time zone] | [values from your records] | [action, or no action] | [R-__] |
| [C-02] | [date, time, time zone] | [values from your records] | [action, or no action] | [R-__] |

## 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.

| Version | Date | What changed | Approved by |
| --- | --- | --- | --- |
| [version] | [date] | [rule IDs and what changed] | [name] |

## 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.

- **Name and role:** [name and role]
- **Date:** [date]

## 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.

## What happens to your rule document

### You write it

On your own schedule, and only once a project is under discussion. Your first message does not need it.

### We check precision

We read for gaps and ambiguity. We do not comment on whether the rules are good.

### Questions come back

Anything that cannot be coded as written returns to you in writing. You decide the answer.

### It feeds the scope

The [scope document](https://fincodelabs.com/en/samples/scope-document) refers to your version, and your worked cases become acceptance checks.

## Questions about the template

### Can you suggest rules or fill this in for me?

No. Fincode does not recommend strategies or parameters, and strategy and investment decisions are yours. If you have written rules, we can check that they are precise enough to code and test.

### Why is there no filled-in example?

Any example rule or value could be read as a suggestion. The template shows the shape of a rule and leaves every value to you.

### Do I have to complete every section before contacting you?

No. Your first message only needs the platform, what the software should do and your timeline. Written rules come in during discovery, because the scope depends on them.

### Can I use this template with another developer?

Yes. It works with any developer: just change the company name in section 15. A precise rule document also makes quotes easier to compare, because each one is based on the same requirements.

### What if my rules change after development starts?

Write a new version and record it in the change log. During a project it is handled as a change to the scope, because tests depend on the rules.

## Read the other documents

- [Sample scope document](https://fincodelabs.com/en/samples/scope-document): The other half of the specification: requirements, failure behavior and acceptance checks.
- [Trading bot development](https://fincodelabs.com/en/services/algorithmic-trading): The service that turns a rule document into tested software.
- [How we work](https://fincodelabs.com/en/how-we-work): The four stages, what you receive at each, and how acceptance testing works.

---

Published by Fincode (Fincode Yazılım ve Teknoloji A.Ş.), a software company in Istanbul, Turkey: https://fincodelabs.com/en/samples/rule-document-template