Skip to main content

Timestamp variables for rules and risk factors

How to configure timestamp variables for rules and risk factors

Overview

Timestamp variables let you build rules and risk factors based on when something happened, not just what happened. Instead of only comparing current values (transaction amount, user country, KYC status), you can now compare when a specific event last occurred against the current moment, against another timestamp, or against a fixed time window.


With timestamp variables generalize this: you can now build a timestamp condition around any user event field or transaction field you choose.


How it works

A timestamp variable resolves to the epoch timestamp of the most recent event matching a condition you define. You configure two things:

  1. Event type: what kind of event to look at:

    • User event: an event on the user record (e.g. KYC status change, address/country update, login).

    • Transaction event: a transaction with specific attributes (e.g. amount, card status change, currency, payment method).

  2. Comparison type: how to match the event:

    • Value: match when a specific field equals (or otherwise compares to) a specific value, e.g. cardStatus = "ACTIVE" or amount > 1000.

    • Presence: match simply on whether a field is present/set on the event, without checking its value.

Once defined, the variable holds a timestamp: "the last time this condition was true." You then compare that timestamp using the new compare_timestamps function, either against:

  • The current transaction/event's own timestamp ("time of the rule run"),

  • Another timestamp variable you've defined,

  • Or a fixed time window (e.g. "within the last 24 hours").

For transaction-triggered rules, a user-event timestamp variable can also be scoped by direction - sender, receiver, or both - so you can specifically ask "when did the sender's card status last change to Active" versus "when did the receiver's."



Where to find it

Timestamp variables are available in two places:

  • Rule builder - when defining a rule's variables, alongside entity and aggregate variables.

  • Risk factor configuration - when building a custom risk factor for transaction or customer risk scoring.

Look for the option to add a Timestamp variable when creating a new variable in either builder. It opens a dedicated configuration form where you pick the entity type, the field, the comparison type, and (for Value comparisons) the value or operator to match.

Some examples of how timestamp variables maybe used

1. Event timestamp compared to the current transaction (Rule Builder)

Goal: Flag a transaction that happens suspiciously soon after a card was reactivated, a common pattern in card-testing fraud.

Rule: "Transaction shortly after card reactivation"

  1. Create a Timestamp variable:

    • Event type: Transaction

    • Field: cardStatus

    • Comparison type: Value, equals ACTIVE

    • Direction: Sender (the user initiating the transaction)

Checking for Card Status active timestamp
​

Checking for new transactions timestamp

  1. Build the rule condition using compare_timestamps:

    AND the time difference between active status timestamp and the current transaction's timestamp is less than or equal to 30 minutes

Logic to compare timestamps between card active status and new transactions with the time window
​
​Note: The toggle for value determines the logic for the comparison. Toggled on means the events happens within 30 minutes of each other, toggled off means events happen 30 minutes outside of eachother

2. Risk factor: recent KYC approval

Goal: Add risk points to a transaction that happens suspiciously soon after a user's KYC was approved, a pattern associated with mule account testing right after onboarding.
​Risk factor: "Transaction shortly after KYC approval"

  1. Create a Timestamp variable:

    • Event type: User

    • Field: kycStatus

    • Comparison type: Value, equals Successful

  2. Create a second Timestamp variable (stands in for "now," the current transaction):

    • Event type: Transaction

    • Field: transactionId

    • Comparison type: Presence

  3. Build the risk factor condition using compare_timestamps:

    • IF the transaction happened within 24 hours after KYC approval

  4. Action: Add a defined number of risk points to the transaction risk score (TRS) or just pick the risk level

Note: if you're building the KYC risk factor and a transaction comes in, then KRS wouldn't get updated.
​
​

Related Articles
Did this answer your question?