Release May 2025

1. Volume-Based Logic with Aggregated Attributes in Rule Engine

Introduced aggregate attributes for global and local attributes (datatype: float or int).
Users can now create aggregate attributes by:
- Selecting a base attribute (global/local)
- Choosing an aggregate function (sum, min, max, average, count)
- Defining a time period (Lifetime, MTD, QTD, YTD, Rolling)
- Optionally applying conditions
Only name edits are permitted. Aggregate attributes can be deleted only if not used in the Rule Engine.
Aggregation is based only on incoming data (via file/API), not historical data.
For Rolling Year, aggregation considers the last 365 days. Users outside this range won’t be excluded from summaries due to a known limitation, but this does not affect point issuance.
For MTD/QTD/YTD, aggregation occurs even if a user has no transaction in the current time period. Their data is stored according to the transaction date.
Aggregate attributes support all Rule Engine features (conditions, tiers, etc.) when combined with manual attributes.
No cap on the number of aggregate attributes.
- Load test: 1M transactions + 10 aggregate attributes = ~4.7M records in ~8–10 mins.
- Points issuance: 3 rule groups × 2 rules each with product capping = 210 mins total.
- Overall processing time: ~220 minutes.
2. Disabling "Field is Unique" on CRD LastSixDigits
CRD API/File supports zero values for LastSixDigits and SubRelationIdentifier.
Either CardNumber or SubRelationIdentifier must be non-null and non-zero.
Updates are allowed using memberRelationRef, cardNumber, and subRelationIdentifier.
CardNumber and SubRelationIdentifier can no longer be updated after insertion.
Get API returns all members with matching cardNumber or subRelationIdentifier.

3. Branding Update to Loyalife

Sender email updated to [email protected] and name changed to Loyalife.
No impact on existing programs—they retain current configurations.
Email templates updated to remove all LBMS/Giift references.

4. Redirection of Existing Plum Account from Loyalife

Marketplace section now available under platform config for users with view/edit permissions.
Users redirected to appropriate Plum portals based on their role (super admin, admin, or member).
Password resets must be done from the Loyalife portal.
Marketplace credentials are not validated in real-time—UI displays errors during login if incorrect.
Token-based authentication handled using refresh tokens.

5. Sidebar UI/UX Improvements

Unique icons added for all sidebar modules with accurate tooltips.
“Organization” removed from the top nav.
“Manage Users” & “Manage Roles” merged into Manage Roles.

6. Multi-Currency Program Management

Program Admins can link two independent programs (one-time action).
Proper error shown if a member exists in one program but not the other.
Module-level switching supported (e.g., Member module); detailed views limited to linked modules.

7. Improved Member Transaction API

GetMemberTransactionSummary and GetMemberTransactionSummaryByDate APIs now fetch local attributes.
Supports both new and legacy programs.

8. Revamped Points Definition Setup

Unified view for points setup:
- Terminology & Rates (Cashback, Purchase, Redemption)
- Expiration Details (Schedule, Period, Start Condition)
- Claim & Pending Points Management now within this screen
Obsolete attribute setting option in Rule Engine removed.

9. Enhanced User Creation Flow

Email ID now precedes username in the form.
Auto-fills username if the email is already in use; field is disabled.
New users can manually input username if email is not in use.
Basic field validations introduced.

10. Configurable Points Expiry Logic

Points can now expire based on the processing date or availability date.
Expiry begins when transaction status changes to confirmed.
Expiry date is calculated post-approval if anomaly detection is enabled.

11. Enable/Disable Monthly Email Statements

New toggle under Communication Settings to enable/disable monthly statements (enabled by default).
Controlled by users with permission to create communication templates.
Compatible with all programs.
Notification won’t re-trigger for the same month once sent.

12. Removing Monthly Cap on Product Code & Rule Group

Field validation removed for monthly caps.
Admins can now enter values >100,000 for Product Code and >5 digits for Rule Group limits.

13. Purchase Eraser Report

New filter “Purchase Erases” added to transaction report.
Not included in default reports—clients must create custom views.
Transactions with loyalty_txn_type=47 and transaction_type=2 are classified as Purchase Erasers.
Narration: “Redemption DebitTransfer”.

14. Report Generation Enhancements

Users can preview setup before generating auto reports.
Manual reports can now be generated from auto-report configurations.
Naming format: [Parent Report Name]_[StartDate-EndDate].

15. VAPT Fixes for LBMS 2025

All vulnerabilities flagged by the Seciq team have been resolved.
Verified and closed after penetration testing; security certificate issued.

GF-3248: Providing volume based logic with Aggregated Attributes in Rule Engine
Aggregate attribute is introduced on global and local attributes whose data type is float or int
User can create aggregate attribute by selecting the attribute(local/global) along with aggregate function(sum, min, max, Average and count) and time period(Lifetime, month to date, quarter to date, year to date and rolling)
User can also add condition(not mandtaory) while creating aggregate attribute
User is allowed to only edit the name and can delete the aggregate if not used in rule engine
Aggregation is computed based on the incoming data(via file or API) and not on the historical data.
For rolling year the aggregation is computed for last 365 days.. When the time period changes the user will not be removed/updated from the aggregate summary even if his txn does not fall under 365 days as this is the limitation. This is harmless as the points will not be issued as it checked based on the current time period.
For MTD,YTD and QTD, even if user does not have txn in current time period, the computation will happen and the data will be stored as per his txn date. Ex: if user has a txn in 15-May-2024, the computation will be done and his data would be stored for the year 2024 and for month may for MTD condition. As and when the data matching this records comes up, it wil be aggregated and points would be issued according to the rule configured.
Aggregate attributes combined with manual(global/local) attributes are verified in rule engine with/without set condition, tiers etc
There is no limit on number of aggregate attributes user can create. QA team have load tested with 1M txn data with 10 aggregate attributes generating around 4.7 million records in the aggregate summary table. This activity took 8-10 Min.
Post processing of issuing points took 70 min for each rule group (total 3 rule groups having 2 rules in each group) with product capping enabled.
Overall time taken is 220 Min(8-10 min for aggregate processing and 70*3=210 min for points issuing)

GF-7261: BDI Go-Live Preparation | Disabling Field is Unique on CRD "LastSixDigits"
CRD file/API processing is enhanced to handle zero values for Last six digit and sub relation identifier
User can insert the CRD data for member by adding unique sub relation identifier and last six digits
Both CardNumber & Subrelation Identifier cannot be 0 or null together in API for File Processing. There should be data in one of them. Passing null to both returns error “CardNumber and SubrelationIdentifier both cannot be empty together.
Either CardNumber or SubrelationIdentifier should have unique value for successful data insertion
Update would be based upon member relation reference, cardNumber, SubRelation Identifier. On update operation cardNumber and SubRelation Identifier cannot be updated.
Both Sub-relation identifier and card number can have unique values together.
The get API call by cardNumber of SubRelationIdentifier returns all the members with the matching data.

GF-6909: Remove all Mention of LBMS and Giift from Product
As part of loyalife rebranding below places are enhanced which were still referring to as LBMS
sender email is updated to [email protected] and default sender name is updated to Loyalife
These changes will not impact existing programs as they will still continue to use existing sender email and name without changes.
Email template is corrected and has only loyalife references

GF-6579: Redirection of Existing Plum Account from Loyalife
User with Platform view and edit configuration permission will be able to add/edit marketplace details under platform configuration section
Only when marketplace is configured user will see the option of Plum. When clicked on this, the user will navigate to plum admin portal based on the access he has in plum side
If the User is registered as super admin at plum side then user will be taken to admin portal.
If the user is registered as Admin at plum then he will be taken to marketplace/end user section and he will have the option to switch to admin from the profile section.
If the user is not registered on the plum side then even the redirection happens to plum side but will be treated as member. He wont get the option to switch to admin profile
User will not be able to reset his password from the plum section and has to be done from loyalife side only
User can provide wrong credentials while setting up marketplace configuration and no check is done from the loyalife side. Error message is shown on the UI when user tries to login to plum account in this case as the handshake API throws error.
Refresh token is used to generate the access token. If user has got access token by using a valid refresh token, then even by passing wrong refresh token in loyalife, user will be redirected to plum. Once the Access token expires then using wrong refresh token, access token cant be generated and at that time he wont be redirected to plum account.

GF-6335: Improving left side bar UI and UX
Each module in the sidebar displays a unique and recognizable icon.
Hovering over an icon displays the correct tooltip.
“Organization” option is removed from the main navbar.
“Manage Users” and “Manage Roles” are merged into a single section called “Manage Roles.”

GF-6704: Multi currency creation & management under a single program
Program admins can now link 2 independent programs. This is one time activity and user cannot delink the program once its linked.
Only program admins will have the ability to link programs
Proper error is shown if member exists in one program but not in other.
Permission-based access control works as expected.
The program switcher functionality is currently supported only at the module-level home pages(e.g., Member). Detailed actions like View are functional only within the Member module. Other modules do not yet support in-depth actions post switching

GF-6391: Improving member transaction API by adding rule engine custom transaction attributes for the storefront.
Now GetMemberTransactionSummary and GetMemberTransactionSummaryByDate API fetches member local attributes.
Local attribute values added via API/file are supported and will be fetched by above Api's
This is compatible with old and new program.

GF-7145: Revamping Points Definition Setup for a Structured Flow
With this improvement all points-related configurations is consolidated into a single structured screen under Points Definition Setup,
Point Terminology & Rates->This section has the Points terminology along with 3 Rates: Cashback Rate, Customer Purchase Rate, Redemption Rate
Expiration Details->This section has the following option under it, Point Expiration Schedule, Point Expiration Period, Point Expiration Start Condition
Claim & Pending Points Management->This section is moved under points definition. No change in the functionality. Pending Points & Retro Claim toggles will be disabled and non editable if global attributes are missing.
The Attribute Setting option in the Rule Engine Attribute Setup Screen is removed, as it does not serve a required purpose.

GF-7112: Enhanced Validation and Autofill for Username while User Creation in Program Creation Flow
Email ID field is placed above the username field in the user creation form
If Email id provided by the user is already present in system, username is auto filled and the field will be disabled.
If Email id provided by the user is not present in system, user will be provided option to enter the username of his choice.
Basic field validations are provided to give a good usable exprience to the user

GF-7049: Configurable Points Expiry Logic in Loyalty Programs
Points expiry logic is enhanced as the user can set the points expiration based on the processing date or points availability date
User can use global or local attributes for this feature
By default the point expiration duration is set to processing date and the user cannot change until the claim & pending points management is configured.
Expiration would kick in once the transaction changes to 1(confirmed).
In case of anomay detection feature enabled, expiry date would be calculated once the user approves the transaction.

GF-6998: Ability to Disable/Enable Monthly Email Statement
Option to Enable/Disable toggle for monthly statement is provided in communication setting section. This would be enabled by default. User needs to explicitly disable if not required
User with only create communication template permission can enable/disable this toggle
No change in the core functionality of monthly Estatement
Once a member gets monthly statement for a particular month, he will not be eligible to receive the notification in same month.
This feature is compatible with new(imported) and existing program

GF-6932: Removing 100,000 Monthly Cap on Product Code & Rule Group Points in Rule Engine
Admins can successfully save Product Code Monthly Cap values beyond 100,000.
Admins can also save Rule Group Limits with values exceeding 5 digits.
No validation errors are triggered even when high values are entered.
Only field validation on the Ui is removed.

GF-6700: Providing Purchase Eraser Report
New filter “Purchase erases” is added in the transaction report. This filter is not part of any of the default reports created by system. So for the existing clients, they need to create a new view using this filter.
Member who does redemption with loyalty_txn_type=47 and transacton_type=2 will be termed as purchase eraser.
Narration for this transaction would be “Redemption DebitTransfer”

GF-6549: Enhancing the Manual Report Generation Workflow and GF-6547: Enhancements to the Report Listing Page
Users can now view the report setup before an auto-generated report is generated.
Users can manually generate a report from an auto-generated report that is pending refresh.
Manual report uses the same configuration as the parent auto-generated report.
Report name follows the format: [Parent Report Name]_[StartDate-End Date].

GF-7289: VAPT fixes for LBMS 2025
All the VAPT fixes raised by Seciq team(External penetration Testing team) have been fixed.
The fixes have been tested and closed after which certificate was issued.