Traadence's forex trading bot is a complete rule-driven FX execution system for traders who want entries, exits, position sizing, and protective controls handled consistently instead of manually clicking through each decision. The build separates strategy logic from broker connectivity, so a trading rule can be evaluated first and an order request can be validated before it reaches the execution adapter. It does not claim to predict markets or guarantee results; it automates a defined process and records what happened.
A trading rule should produce the same execution decision from the same inputs, with every rejection, order, fill, stop, and shutdown event traceable afterward.
Core Features
| Feature | Description |
|---|---|
| Rule-based signal engine | Manual interpretation creates inconsistent entries. The engine evaluates configured price and indicator conditions on each completed decision interval and emits only explicit long, short, or no-trade states. |
| Pre-trade risk gate | A valid signal can still create an invalid order. The risk layer checks position size, stop distance, exposure, duplicate positions, and configured loss limits before an order is released. |
| Broker adapter boundary | Broker-specific request formats make strategy code brittle. Execution is isolated behind an adapter that maps normalized order intents to the connected account and returns acknowledgements, rejections, fills, and errors. |
| Protective order handling | Missing or mismatched protection can leave an open position unmanaged. Entry requests carry stop-loss and take-profit instructions when configured, while state tracking verifies the resulting position. |
| Position and order state ledger | Restarting a process without state can duplicate actions. A local ledger stores signals, order IDs, fills, open positions, errors, and timestamps so recovery starts from known execution state. |
| Kill switch and session controls | Automation should not keep trading after a defined safety boundary is breached. The bot can block new entries after configured limits, outside permitted sessions, or when connection health fails. |
Execution Architecture
The project uses Python's asyncio runtime for I/O-bound market-data and order events, while strategy evaluation remains deterministic and testable. Configuration is loaded separately from executable logic, and credentials are kept outside source control. A lightweight SQLite write-ahead log stores execution state because a single-node trading service benefits more from simple recovery and auditable records than from an unnecessary distributed database.
The processing path is deliberately narrow: market event
strategy state
risk validation
normalized order intent
broker adapter
acknowledgement/fill
ledger update. The risk gate runs before the network call. That matters because a connection retry should never be able to bypass size, stop, or session checks.
Market Context and Risk Boundaries
Automation removes manual execution variance, not market risk. The BIS 2025 Triennial Survey is the broad industry reference for global FX market structure, while the BIS June 2026 work on FX settlement risk reported that more than $14 trillion of gross FX obligations were settled on an average day in April 2025 and about 10% remained on a gross bilateral basis without settlement-risk mitigation.
For retail OTC trading, the CFTC forex advisory notes that leverage amplifies gains and losses and that the dealer controls the platform connection. Its historical disclosure sample also found roughly two out of three registered OTC forex customer accounts lost money. That is why the software treats position limits, broker errors, and shutdown conditions as first-class execution concerns rather than marketing claims. The CFTC also warns that automated trading programs cannot consistently predict the future.
Use Cases
- Run a repeatable intraday ruleset: evaluate the same entry and exit conditions each session without changing behavior because of hesitation or missed clicks.
- Enforce account-level boundaries: reject new orders when configured position, session, or loss constraints have already been reached.
- Recover from process restarts: reload open-position and order state from the ledger before deciding whether another action is allowed.
- Audit strategy execution: review timestamps, normalized signals, rejected orders, broker responses, and fills to distinguish strategy logic from execution failures.
Technical Stack
| Component | Choice | Why it is used |
|---|---|---|
| Runtime | Python 3 | Keeps strategy, risk, broker-adapter, and reporting logic in one readable codebase with mature testing and numerical tooling. |
| Concurrency | asyncio | Handles network-bound data and execution events without forcing strategy evaluation into multiple processes. |
| State store | SQLite WAL | Provides durable local order and position history with straightforward restart recovery for a single deployed instance. |
| Configuration | YAML + environment variables | Keeps trade rules readable while separating broker credentials and deployment secrets from versioned source. |
| Testing | pytest | Supports deterministic unit tests for signal rules, risk rejection paths, sizing calculations, and adapter error handling. |
Project Directory
fx-execution-engine/
├── app/
│ ├── main.py
│ ├── config.py
│ ├── strategy/
│ │ ├── signals.py
│ │ ├── indicators.py
│ │ └── rules.py
│ ├── risk/
│ │ ├── position_sizing.py
│ │ ├── limits.py
│ │ └── guards.py
│ ├── execution/
│ │ ├── broker_adapter.py
│ │ ├── order_router.py
│ │ └── reconciliation.py
│ └── storage/
│ ├── ledger.py
│ └── models.py
├── config/
│ ├── strategy.yaml
│ └── risk.yaml
├── tests/
│ ├── test_signals.py
│ ├── test_risk_limits.py
│ ├── test_order_router.py
│ └── test_recovery.py
├── .env.example
├── requirements.txt
└── README.md
Operational Benchmarks
The meaningful benchmark is not a claimed win rate. It is whether the execution service behaves predictably under failure. Acceptance checks cover duplicate-order prevention, restart reconciliation, invalid-size rejection, stale-data rejection, broker timeout handling, and persistence of every state transition. Strategy tests use fixed historical inputs so the same input series produces the same signal sequence.
- A rejected risk check creates zero outbound order requests.
- A restart reconciles stored state before new entries are enabled.
- Every order intent has a timestamp, strategy reason, risk decision, broker response, and final state.
- Connection-health failure blocks new exposure until the adapter is healthy again.
If the deployment needs additional broker adapters, new rule modules, monitoring, or reconciliation logic, Traadence can handle trading software development services and ongoing integration without changing the strategy/risk separation.
How to Automate Rule-Based Execution Using Traadence's forex trading bot
Download & Set Up the Project
Download, set up, and install Traadence's forex trading bot to get the project running. If you hit any difficulty, contact us here.
Open the Runtime
Start the service, confirm the broker adapter reports healthy, then open the status console to verify account state and current strategy session.
Set Trading Rules
Load strategy.yaml and risk.yaml; set currency pairs, decision interval, entry conditions, position size rule, stop distance, session window, and loss limits.
Start Execution
Run the start command. The service evaluates signals, rejects invalid orders, routes valid requests, and records acknowledgements, fills, positions, and errors in the ledger.
Questions
How does the bot decide when to enter and exit a trade?
It follows explicit strategy rules rather than discretionary judgment. Market inputs are converted into a long, short, or no-trade state; qualifying actions then pass through the risk gate before any order request is sent.
Can I change risk limits without editing the strategy code?
Yes. Position sizing, stop distance, session windows, and configured loss limits live in separate configuration so they can be changed without rewriting signal logic. Changes should still be tested before live use because tighter or looser limits alter order eligibility.
What happens if the broker connection drops during a run?
New exposure is blocked when connection health fails. After connectivity returns, the adapter reconciles broker-side orders and positions against the local ledger before normal execution resumes, reducing the chance of duplicate or orphaned actions.