Real time Rules

Unit21 offers a real time detection engine for rules.

This approach differs from the transaction monitoring ruleset in terms of how the rules are evaluated, what type of rules exist, and the intended use cases.

Real time rules typically monitor fraudulent activity and are currently optimized to flag transactions in the authorization loop.

Real time rules can be dynamically created and modified on Unit21’s dashboard (similar to transaction monitoring rules). The method of triggering is different however.

Real time rules are triggered via API call:

  • Individual events are sent to Unit21 using a specific endpoint that will trigger the real time rules on that event
  • A response indicating PASS or FAIL will be returned to the caller

Supported Rules:

Event Property Rules: users can configure whether properties on a given event match certain conditions. Example of these include:

  • Whether a transaction is over $100K
  • If the sender and receiver are the same user
  • Whether a transaction has a status of failed and occurred between midnight and 4AM UTC

Match-list Rules: dynamically modifiable matchlists can be used in rules. Examples of these rules include:

  • If a transaction originated in a known bad IP address
  • If the sender of the transaction is from a high risk country

Windowed Aggregate Rules: transaction sums, counts, and averages within a given time window that are over or under a specific threshold. Examples of these rules include:

  • If a user transacts more than 10K in a 3 hours span
  • If a user receives more than 250 transactions in a week


  1. Real time rules can be modified at any time.
  2. Updates and deletes will not be taken into account for rule execution.
  3. If there is an error during a rule execution, an ERROR will be returned.
  4. Real time rules do not generate alerts or send notifications.


Additional rules will be supported in the future.

We will likely support First time/Newly seen rules, Behavior Deviation rules, Geospacial rules, and Sequential rules soon.


Contact your customer success manager to get started.

Unit21 will write the initial ruleset for you for testing in the sandbox environment.

Once the rules are set up:

  1. In order to execute rules on the event, run a POST request to https://rtr.{env}
  2. After you receive a response from the above API call, you will need to save the event to Unit21 (so that it can be used in future rule executions). To do this, run POST request to https://{env} with the exact same json body used in the call above.

Both steps here are important - the first enables you to run the rule on the event and the second allows you to save the event to Unit21 so that it can be incorporated in future rule executions.


  1. The p99 response time per API call is 1 second.
  2. The engine can support a monthly transaction volume of 30M with a burst throughput of up to 100 requests per second.
  3. For aggregation rules, each evaluation will only take into account transactions that happened for some time, namely there is a delay, and the very recent transactions will not be captured in the aggregations. The p99 delay is 60 seconds.


Because of the nature of the way data is processed and stored in Unit21, there is a small margin for error in aggregate rule evaluation.

There are two steps involved in using real time rules (more described below):

  1. Running the rule on a given event
  2. Saving that event to Unit21

While running the rule is fast (< 1s), the process of saving transactions can take up to ~5 minutes in complex situations. As a result, a transaction may not be usable in a real time rule that runs within the next 5 minutes. This case is typically unlikely as it would only be triggered in aggregate rules if a high number of transactions occur for a single user near the end of a time window.

Regarding time windows, a 1 hour window is the smallest supported window size.
In addition, sum, count, and average are the only currently supported aggregate functions.