Sample scope document for a trading bot

Sample, fictional project. Text in [square brackets] would be filled in for a real project. Risk limits and rule thresholds are blank on purpose: Client A sets them, and Fincode does not suggest them. Purely technical values, such as how often reconciliation runs, are marked [from design] and reach Client A in the design note for approval. A scope document is what you receive at the end of the first stage in how we work.

1. Purpose and status

This document states what the software must do, what it must not do, and how each requirement will be checked. It is the trading bot specification for this project, written before any development starts. Once Client A approves it, the written proposal is based on it. If this document and a later message disagree, this document stands until a numbered change says otherwise.

2. Background

Client A is a company that trades its own account on Exchange A. It has written its entry, exit and risk rules in a rule document and applies them by hand. It wants software that applies those rules on its own account, with its own API key, on its own server. No other person's account or money is involved.

The rules, instruments and limits are Client A's decisions. During discovery Fincode checked that the rules are precise enough to code and test. Fincode did not choose them and makes no statement about whether they will make money.

3. Responsibilities

4. System overview

The order service is a set of small components on Client A's server. The risk gate sits in the only path to the adapter, so no rule can bypass it. Only Exchange A's responses and events can mark an order as open, filled or closed.

Exchange A market data
  |
  v
Rule module      applies rules R-01 to R-nn from the rule document
  |  order instruction (signed, may be delivered more than once)
  v
Intake           checks secret and schema, drops duplicates and
  |              late messages
  v
Risk gate        allowlist, size and loss limits, emergency stop
  |
  v
Order manager    saves intent, tracks state, resolves unknowns
  |  ^
  v  |  responses and account events
Adapter          signing, clock check, rate budget, symbol rules
  |  ^
  v  |
Exchange A

Beside the main path:
Reconciler       compares local state with Exchange A
Logs and alerts  record each decision and report failures

5. Functional requirements

These are the trading bot requirements for this project. Each one is written so that it can be checked, and each names its check from section 10. Most of them describe failure, because the normal path is the easy part of trading software.

Rules

Intake

Risk gate

Order manager

Connections and limits

Restart and reconciliation

Logs and alerts

6. Non-functional requirements

• Where it runs: Client A's own server, [operating system and version]. Fincode does not host it. The intake listens on a private interface only, with no public endpoint.
• API key: read and trade permissions only, withdrawal off, IP restriction on where Exchange A supports it. Encrypted where it is stored on the server. Never in code, the repository, logs or messages.
• Capacity: expected load is [instructions per day, from Client A]. The test report states what was measured. Nothing is claimed that was not measured.
• Availability: no uptime figure is promised. Outages caused by the exchange, the server or the connection cannot be ruled out entirely, so this document specifies how the software behaves when they happen.
• Time: every timestamp is in UTC, and the host's clock is kept in sync.
• Logs: kept for [period set by Client A], in a location that survives the loss of the process.
• Operations: a runbook covers start, stop, restart, key rotation and releasing a freeze.

7. Platform facts recorded during discovery

Exchange A is invented, so these facts are too. In a real document, each row cites the platform's documentation and the date it was read. Which platforms a customer can use depends on the law of the customer's country and the platform's terms: Client A's country is [stated here], and the check is repeated before go-live.

8. Out of scope

• Choosing, changing or judging rules, instruments or parameters.
• Any view on whether the rules will make money. Historical replay checks that rules fire as written, and no return is calculated from it.
• Watching positions, running the software or placing orders for Client A.
• Any account other than Client A's own. Fincode declines projects that run on other people's accounts, copy trades or sell signals, and it does not take a profit share.
• Withdrawals or transfers of any kind.
• Hosting, and the security of Client A's server and account credentials.
• Tax or accounting reports, other exchanges, and any user interface beyond logs, alerts and the command line.
• Maintenance after handover, which is agreed separately. It covers the software and API compatibility, not strategy changes or position monitoring.

9. What Fincode needs from Client A

• The rule document, frozen at version 1.2 during development. The rule document template shows what it covers.
• Worked cases from Client A's own records, with the action expected in each. They become check W01.
• A value for every limit and threshold marked [set by Client A].
• A testnet key with read and trade permissions. The live key is never sent to Fincode.
• Access to the server for deployment, on terms Client A sets.
• A named approver, and a named person who can release a freeze.

10. Acceptance checks

Acceptance checks describe how the software behaves. A return, a win rate or a backtest result is not an acceptance criterion. The sample test report shows how these results are reported.

11. Test approach

1. Automated tests on synthetic data, including a fake exchange that can fail on demand.
2. Historical replay to check that each rule fires as written (W01). No return is calculated.
3. Exchange A's testnet with a proxy that can delay, drop or replace responses, so failures happen when the test needs them (T01 to T14).
4. A paper trading account with live market data (P01).
5. A live account with small limits, only after Client A approves the test report. The limits are Client A's.

12. Deliverables

• The order service, with source code and deployment scripts. Code ownership: [agreed in the contract].
• A configuration file with no limit values filled in.
• A test report covering every check in section 10.
• Technical documentation and an operations runbook.

13. Open questions

Questions stay visible until someone answers them. Each one blocks only the work that depends on it.

14. Changes to this document

After approval, each change is written as a numbered change to this document, with its effect on work items, dates and cost. Work on a change starts only after Client A approves it. A new version of the rule document counts as a change.

15. Terms set elsewhere

16. Approval

Sample of the format for a fictional project. Tests show how the software behaves, not future results. Trades can lose money. Strategy and investment decisions belong to the account holder. Fincode is a software company and does not provide investment advice, portfolio management or crypto asset services.