Understanding Execution Windows

Each model (rule) in production is associated with an execution time window, which is the period of time over which the model will be executed on.

For example:


Looking closer:


Because models (rules) can involve objects of different types:

  • Assume that Rule A (as in the illustration above) is a very simple rule that flags users that make more than 2 transactions of more than USD $10,000 in 12 hours.
  • Rule A is executed every 30 minutes (referred to in our system as the execution stride) in a sliding window fashion:
    • A few minutes after 12:30am we will run the rule against all transactions that occur between 12:30pm (on the previous day) and 12:30am,
    • then a half hour later run the rule against transactions that occur between 1:00pm (on the previous day) and 1:00am.

Execution strides are pre-defined as ~10-15% of the selected window size. (You select the window size when creating the rule from a scenario).

In the same system, you can run other rules e.g. Rule B with an execution time window of 1 week, executed every 12 hours (12 hour stride). This implies that if the rule is first executed on Monday 10 Jan at 7:00am against transactions from 'Monday 2 Jan 7:00am' to 'Monday 10 Jan 7:00am', it will next run on 'Monday 10 Jan at 7:00pm' against transactions from 'Monday 2 Jan 7:00pm' to 'Monday 10 Jan 7:00pm'.

Here are the supported window sizes along with their corresponding supported window stride lengths:

Execution Window SizeAvailable Stride Size (default values in bold)
10 mins (10 mins)1min, 2min, 4min, 5min, 10min
20 mins (20 mins)1min, 2min, 4min, 5min, 10min, 20min
1 hour (60 mins)4min, 5min, 10min, 20min, 30min, 45min, 1hr
3 hours (180 mins)10min, 20min, 30min, 45min, 1hr, 2hr, 3hr
12 hours (720 mins)30min, 45min, 1hr, 2hr, 3hr, 4hr, 6hr, 12hr
1 day (1440 mins)1hr, 2hr, 3hr, 4hr, 6hr, 12hr, 1d
3 days (4320 mins)3hr, 4hr, 6hr, 12hr, 1d, 3d
5 days (7200 mins)6hr, 12hr, 1d, 3d, 5d
1 week (10080 mins)6hr, 12hr, 1d, 3d, 5d, 7d
2 weeks (20160 mins)12hr, 1d, 3d, 5d, 7d, 14d
1 month (44640 mins)3d, 5d, 7d, 14d, 21d, 31d
2 months (87840 mins)3d, 5d, 7d, 14d, 21d, 31d, 61d
3 months (132480 mins)5d, 7d, 14d, 21d, 31d, 61d, 92d
4 months (175680 mins)5d, 7d, 14d, 21d, 31d, 61d, 92d, 122d
6 months (263520 mins)7d, 14d, 21d, 31d, 61d, 92d, 183d
1 year (525600 mins)14d, 21d, 31d, 61d, 92d, 365d

This sliding window algorithm makes for a level of detection robustness that is state-of-the-art. That said, there is just one unlikely scenarios in which detection will not occur and a false negative will occur.

Refer to the illustration immediately below for an explanation for how this might occur for Rule A described above:


In this image, transaction J and transaction K are both transactions initiated by the same user with amounts greater than USD $10,000.

  • Transaction J occurs x mins before the start of Execution window A-3.
  • Transaction K occurs y mins after the end of Execution window A-2.

As long as x + y is greater than 30 mins (stride size), the transactions will be flagged successfully.

However, if x + y is smaller than 30 mins,

  • transaction J occurs at 12:59am -- 1 min before start of Execution A-3 -- and
  • transaction K occurs at 12:31pm -- 1 min after the end of Execution A-2 --

There will not be a hit generated even though the transactions technically lie within 12 hours of each other.

1 Month versus 30/31 Days


In the example above:

  • The first "execution" time will be June 15, looking back 1 month which is May 15 - June 15.
  • The second execution will be 1 week later so it will be May 22 - June 22.

What is the distinction between 1 month and 31 days?

  • If you chose 1 month, it's a day match from one month ago. Simply subtract your month by 1.
  • If you choose 31 days, subtract your day by 31.