The Rule Engine is the business logic layer of Loyalife — it defines how members earn points for transactions and activities.
The Rule Engine is the core of your loyalty program’s incentive structure. It lets you create conditions-based rules — “if a transaction meets these criteria, apply this reward” — without any code. Rules support simple flat-rate earning, tiered multipliers, milestone bonuses, birthday cashback, and time-targeted promotions.
When a transaction arrives (via API or file upload), Loyalife evaluates all active rule groups whose linked segment includes the transacting member. Matching rules determine how many points, what cashback percentage, or what bonus applies. Results are posted to the member’s account immediately.Example — retail loyalty program:
Earn 2 points per ₹1 spent at any time
Earn an additional 1% cashback on transactions above ₹5,000
Earn 500 bonus points on the member’s birthday month
Earn a 25% cashback on every 20th order in a calendar month
Each is a separate rule inside the same rule group. All evaluate simultaneously for each transaction.
The data point to check (e.g., Transaction Amount, MCC, Transaction Date)
Operator
How to compare (equals, greater than, contains, between, is multiple of)
Value
A static threshold, or another member attribute for dynamic comparisons
Multiple conditions combine with AND (all must be true) or OR (any must be true).Every rule condition evaluates a combination of transaction attributes and member attributes — what happened in the transaction, and who the member is. This is what makes the Rule Engine powerful: a single rule can simultaneously check “was the transaction amount above ₹5,000?” (transaction attribute) and “is the member in the Gold tier?” (member attribute) and “has the member transacted more than 10 times this month?” (aggregate attribute).Supported attribute categories:
Category
Source
Examples
Transaction attributes
Submitted with each transaction via API or TXN file
Transaction Amount, Transaction Date, Product Code, Sub Product Code, Transaction Type, Relation Reference, Transaction Id
Custom transaction attributes
Defined by you in Rule Engine → Attributes
Merchant Name, MCC Code, Channel, Store ID, any program-specific transaction field
Member (global) attributes
Built-in member profile fields
Date of Birth, Gender, Status, Preferred Language
Member (custom) attributes
Defined by you in Members → Attributes
Occupation, region, card type, any program-specific member field
Aggregate attributes
Computed from transaction history
Monthly Spend Sum, Transaction Count (MTD/YTD), Average Transaction Value
The Transaction Date attribute supports combined date and time values. The date picker opens with a calendar plus an embedded time selector (HH:MM, 24-hour format) below the grid.
Picker element
Behavior
Calendar
Select the date as usual
Time selector (HH:MM)
Hour range 00–23, minute range 00–59
Default time
00:00 (midnight)
Today button
Sets current date + current time
Apply button
Confirms and closes the picker
Combined display
Shows as MM/DD/YYYY HH:MM in the condition field
For the between operator, both start and end pickers include their own time selectors. Existing rules with date-only values continue to work as-is — they are treated as 00:00 by default.Example use cases:
Dynamic attribute comparisons — birthday and anniversary rules
Instead of comparing an attribute to a fixed value, you can compare it to another member attribute. This enables rules like birthday cashback or card anniversary bonuses.Birthday cashback example:
Condition 1: Transaction Date [Date of Month] Equals Date of Birth [Date of Month]Condition 2: Transaction Date [Month of Year] Equals Date of Birth [Month of Year]THEN: 35% cashback
Constraints for dynamic comparisons:
Constraint
Rule
No self-comparison
An attribute cannot compare to itself
Type compatibility
Left and right must be the same data type (Date ↔ Date, Number ↔ Number)
Date type lock
If the left side uses [Date of Month], the right side auto-locks to [Date of Month]
Operator restrictions
Contains and Is Multiple Of are not available for attribute-to-attribute comparisons
Edge cases for birthday rules:
Scenario
Behavior
Date of Birth not set in member profile
Condition evaluates to false — no birthday reward
Member born on Feb 29
No birthday reward in non-leap years
Profile DOB updated mid-month (reward already issued)
Next reward on the new date, following year
Supplementary card transaction
Uses the DOB of the primary account linked to that card
The Is Multiple Of operator fires a rule every time an aggregate count or sum hits a multiple of your configured value. The current transaction is included in the aggregate before evaluation. Reversals and refunds adjust the aggregate automatically.Example — reward every 20th order per month:
Attribute: Monthly Order CountOperator: Is Multiple OfValue: 20Reward: 25% cashback (capped at ₹500 per transaction)
This fires on the 20th, 40th, 60th order, and so on.
An implicit Count > 0 guard is added automatically when you use Is Multiple Of to prevent zero from incorrectly matching (since 0 is technically a multiple of any number).
Each earning rule can carry one or more restrictions that limit when and how much the rule fires. Add restrictions from the Restrictions section of the rule builder.
Restriction type
What it does
Point Limit (MaximumPoints)
Sets a hard cap on the maximum points a single transaction can earn from this rule
Date Range
Restricts the rule to only fire within a specific start–end date window
Calculation Timing
Controls when points are posted after a qualifying transaction (e.g., immediately vs. after a holding period)
Product Codes
Restricts the rule to only fire for transactions with specific product codes
Sub Product Codes
Further narrows to specific sub-product codes within a product category
Combining restrictions:Multiple restrictions are evaluated together with AND logic — a transaction must satisfy all active restrictions for the rule to fire. For example, a rule restricted to a date range AND specific product codes will only fire for qualifying products within that time window.
Restrictions layer on top of IF conditions, not instead of them. A transaction must first pass all IF conditions, then pass all active restrictions, before the THEN reward is applied.
Changes to rule status (active/inactive) take effect immediately for new transactions. They do not retroactively apply or reverse points already awarded.
