Here are some frequently-asked and introductory questions about AWTS

Do you provide signals or trade copying?

No. AWTS provides tools for you to develop and operate your own trading systems - whether fully systematically, or data-driven tooling to support discretionary execution.

We do not provide signals, nor trade recommendations nor any mechanism for trade copying.

How long does a lifetime purchase last?

Lifetime licenses are perpetual, however support and updates are only available for a period of one year from the date of purchase or the end of the AWTS EAP programme for the tier you purchase, whichever comes later.

AWTS is self-hosted, and lifetime purchases come with offline licensing - so your ability to continue to use the software does not depend on our servers, services or even our existence.

Can I sell custom modules for AWTS?

Yes, the AWTS framework is an open, extensible, API-based architecture and custom modules are actively encouraged and supported.

There are no commercial restrictions on how a custom module that you create can be offered.

Note that the API structure also means your custom modules can either be delivered to customers to self-host, or offered online for customer AWTS environments to connect to remotely.

What data is included?

Licensing market data for redistribution is orders of magnitude more expensive than licensing for your own use. Licensing for your own use will also depend on your professional status and whether or not you work alone. There is also huge breadth in the types, forms and characteristics of data available; no one size fits all.

So AWTS is a BYOD platform; you run it self-hosted on your own infrastructure and connect it to your choice of data sources. Many modules are available for integration with various 3rd party vendors, and you can also implement new/custom data sources yourself.

Some freely-licensed data is also available, please contact us for more information.

Are there built-in indicators?

Yes, if you use the Runner service for charting and/or strategy execution then you can add pre-defined indicators by declaring them in the job's Spec file.

Most common indicators are supported, including SMA, EMA, RSI, MACD.

Multi-instrument indicators are also supports, e.g. Relative Strength vs a [customisable] benchmark.

Can I run it in a cloud VPS server?

Yes - pretty much all cloud providers offer linux VMs, which are trivial to run docker containers on.

For basic use, like running a strategy live, a basic $5/month instance should be all that is needed - use the Configurator to set up a minimal environment with just a Data service, Book service, Results service, Runner and of course your actual strategy.

Heavier usage, like backtesting and strategy research will typically need a larger server instance - primarily to cope with caching larger amounts of market data and being able to efficiently serve candles and simulate fills for efficient backtest performance. Nevertheless, it is still often wise to start small and only increase resources/costs as needed.

Are data corrections/updates included in backtests?

When live-streaming data, sometimes candles get updated after-the-fact, for various reasons.

At the moment, AWTS does not support replicating this behaviour in backtesting.

Future updates may include support for this, on a vendor-by-vendor basis.

Typically the hard part of implementing this is having reliable data that can be replayed - vendors do not supply it so it must be collected real-time, and/or reconstructed from tick data.

Why are my backtests slow?

Backtesting should be really fast - but of course 'fast' and 'slow' are vague and relative terms. If your backtests are not running as fast as you would like, consider the following:

Trade lifetimes

Depending on your strategy, hint the engine with the lifetime parameters of your trades.

E.g. if your strategies include a rule "all cash at the weekend", then the engine can know that every week is independent of every other week* and can parallelize your backtests more effectively.

*aside from account size, which is typically irrelevant for backtesting.

Simulating fills

The engine uses the smallest candles possible (or ticks, if available) to simulate fills as accurately as possible. Depending on the vendor/broker this may be actual tick data, or candles as small as 1 second.

For this, the largest performance impact is usually in fetching the price data from your upstream broker/vendor.

Consider increasing the amount of disk space available for market data caching, and pre-caching the data in advance so its already locally available when your backtests come to run.

Some Data modules have vendor-specific configuration you can tweak - e.g. to tell it to use higher-timeframe data for fills; which increases speed at a cost of accuracy.

See the Data services documentation for more details


Backtesting, especially with multiple time periods running in parallel, is resource intensive - and deliberately so to maximise use of your hardware to run backtests as quickly as possible.

Monitor your hardware during backtests using your OS-standard performance tools. You should typically see strong CPU usage (multiple cores at 100%), and minimal disk I/O.

Backtesting is memory-hungry, not having enough RAM is significantly impactful to backtest performance and tends to be obvious in system performance metrics; manifesting as reduced CPU usage and significant disk writes/reads.

Can you see my strategies?

No - you run AWTS modules, and your strategies, on your own infrastructure. We do not have access to your code nor your strategies, and the AWTS modules do not provide any mechanism to exfiltrate them from your infrastructure.

Furthermore, the principle of Provable Security means that you can prove for yourself - without having to trust - that this is the case.

See the security docs for more information.