When Technical Indicators Are A Red Flag – And When They’re Necessary

The article “When Technical Indicators Are A Red Flag – And When They’re Necessary” was originally posted on Databento blog.

In this article, we dig into when technical indicators are a red flag, and when they’re necessary. To identify the red flags, we use what we call the technical indicator smell test: when your market data API has extensive support for technical indicators and derived features.

When technical indicators are a red flag

Most technical indicators have an insignificant correlation with future returns, which makes them impractical for developing profitable trading strategies.

It’s usually better to compute returns on the client side. This may be controversial, but we’re quite opinionated about it at Databento. Even some popular values like Greeks and VWAPs are often better computed on the client side; Greek calculation is subjective to model and inputs, and top trading firms rarely use third-party Greeks.

Good APIs usually have a small API surface with few orthogonal API methods. While technical indicators may serve a specific audience, their purpose is so far downstream that it’s bloated for most users who don’t need them. Here are a few examples:

• Poor model fit: Most technical indicators have functional forms that result in poor model fit, e.g., truncation, censorship, non-linearity, discretization, and dependence on subsampled time-space.
• Expensive to compute online: Many technical indicators have functional forms that are expensive to compute online, e.g., require a sliding window of memory or cost linear time in the lookback period to compute.
• Many venues have derived data policies: Sometimes, these indicators are published without compliance with the venue’s data policies.

When technical indicators are necessary

Although we’ve pointed out many reasons not to support technical indicators, there are limited situations in which we do recommend them:

• I/O is always a limiting factor when providing a data-intensive API, so it’s often better to push computation closer to the source, up the I/O or memory hierarchy, from client to server, etc. The same principle underpins Apache Spark and edge computing. If the API is used by a web application that serves many users, it could be cheaper to compute these on the server side.
• It’s easy to communicate as a starter example in your documentation; many of these technical indicators are widely known and have simple, functional forms.

You can view our docs page for examples of calculating common technical indicators on Databento, like VWAP and RSI or TICK and TRIN.