Introducing Self Rate Limiting

Avoid duplicate signals or ensure only one position is opened over a certain time period with self rate limiting.

Depiction of rate limiting cartoonized as multiple highway lanes merging into one

An interesting problem has popped up recently in our Discord and in several support emails we've seen: duplicate signals.

Sometimes, for whatever reason, a duplicate signal is sent from TradingView (TV) for the same event. Most of the cases we've seen were from users running proprietary indicators they purchased and could not easily diagnose why multiple signals were being sent for a single alert.

To correct for this, we're introducing the concept of self rate limiting.

Traditional Rate Limiting

In a typical rate limiting scenario, the service provider (e.g., CrossTrade) limits the rate of requests a user sends to their servers or infrastructure.

For example, if you were accessing certain resources at CrossTrade, we might limit how many requests per minute each user was allowed to submit. This is traditionally put in place for users accessing APIs via code.

Since the overwhelming majority of signal requests are coming from TradingView and are legitimate trading signals, this isn't a problem for us.

Duplicate Signal Problem

But as we mentioned above, it can be a problem for traders. Several users came to us with a unique, duplicate signal problem we never anticipated when building CrossTrade.

Although we all setup our webhook alert signals in TV very meticulously, we ultimately don't control their software. To make matters worse, if we're trading proprietary signals (written in code we may not understand), we control neither the signal nor the technology sending it.

We at CrossTrade initially intended to be just the middleman between services like TradingView and NinjaTrader, passing through those requests as quickly as possible with no intervention. But we have the capacity to do so much more.

CrossTrade is in a unique position and can act as a middleware against all of the signals that transit through it.

We first took advantage of this when introducing our FLATTEN_FIRST flag, which injects a closing order to flatten the position prior to submitting the order criteria to place a new trader.

We can also leverage our tech to prevent duplicate signals from executing against NinjaTrader through something we call "self rate limiting."

How it Works

Instead of CrossTrade, the service provider, imposing rate limits on the traders. Each trader can now impose rate limits on themselves.

Let's say your entry signal is firing twice from TV, you can't figure out why, and it's messing up your strategy. Instead of wasting time figuring it out, you can use CrossTrade to limit how many signals are accepted for a certain message type over a certain window of time.

key=xxxxxxxxxxxxxxx;
command=PLACE;                      
account=sim101,sim102,sim103;
instrument=CL 07-24;
action=SELL;
qty=1;
order_type=MARKET;
tif=DAY;
rate_limit=1;
id=mystrategy;

Example alert message showing Rate Limit and ID fields, replicated across 3 accounts.

To use rate limiting, you simply have to provide a rate_limit and id identifier field to any alert message to track the message type.

In the above message, we set a rate_limit=1 and id=mystrategy. By default, if the rate limit is a single number, it defines the number of requests allowed through CrossTrade every one minute for that id.

So if 2 alerts show up within a few milliseconds of each other, the first one with that id will be accepted, and the second one will be blocked.

Fixed Window Algorithm

The type of rate limiting CrossTrade uses is known as "Fixed Window."

Fixed Window rate limiting is a technique used to control the rate at which requests are processed by a system within a specified time frame. It divides time into fixed, non-overlapping intervals, or windows, and enforces a maximum number of allowed requests per window.

For example, if the rate limit is set to 100 requests per minute, a new window starts every minute, and within each minute, the system allows up to 100 requests.

Once the limit is reached within a window, any additional requests are rejected until the next window begins.

Advanced Usage

By default, a single number rate limit is interpreted as number of requests per minute, specifically 60 seconds.

If you have cause to use other timeframes, it's also possible to set a custom window period for your rate limit by including a requests/window (requests per time window) value, separated by a forward slash with the window time in number of seconds.

đź’ˇ
The current limits on setting custom rate limits are 1,000 requests per day, or 86,400 seconds.

Examples:

rate_limit=1/10;
id=mystrategy;

Maximum of one request per 10 seconds.

rate_limit=10/120;
id=mystrategy;

Maximum of 10 requests per 2 minutes (120 seconds).

Other Use Cases

In addition to filtering duplicate signals, this technology could also be very useful for day trading strategies, for instance. If your strategy only holds positions for, at most, one hour, you could allow CrossTrade to only pass signals to NinjaTrader once per hour. Thus preventing the possibility of another signal affecting your position.

Here's how you can do it:

key=xxxxxxxxxxxxxxx;
command=PLACE;                      
account=sim101,sim102,sim103;
instrument=CL 07-24;
action=SELL;
qty=1;
order_type=MARKET;
tif=DAY;
rate_limit=1/3600;
id=mystrategy;

Example showing 1 request per hour, or 3,600 seconds.


We hope this is useful to the traders out there who find themselves in the unique situation where self rate limiting can solve their problems.

Until next time, happy trading!

Start your free trial

Try CrossTrade for 7 days.

Sign Up