RCX Accounting Mechanisms¶

Introduction¶

This guide describes the way that accruals and redemptions in the RCX system are related to their corresponding parent Activities, the Rule system that created them, as well as how the FIFO (First In, First Out) mechanism is employed during point burn.

Activity Tracking¶

Activity Structure¶

In the RCX system, Activities are the basic elements of interaction. This means that in order for any rule in the RCX system to be triggered, there has to be an Activity submitted to the RCX engine, which generally represents a customer action of interest.

Figure 1. Activity Structure

An Activity can represent any event of interest that may result in earn and burn such as:

• making a purchase
• registering with the program
• downloading and installing a Mobile app
• checking in at a location
• redeeming points during a purchase
• redeeming points for a reward that can be used to obtain value later (e.g. discounts, free items, etc.)
• any other activity that may result in a change in the loyalty status of the customer

The Activity has a type field which is very important as it indicates what an Activity represents - e.g. Accrual, Redemption, Enrollment, etc. These types are configurable within RCX for a specific program and can be used in reporting to group earn/burn by specific activity types.

Each such Activity object is populated with stock attributes, most of which relate to the context in which the Activity occurred. For example:

• The Activity type indicating what event took place
• The LoyaltyID of the member for whom the Activity is processed
• The total financial value and currency of the activity - could be in USD, Points, etc.
• The Location where the Activity took place
• The date and time of the activity, including timezone information
• The products and quantities associated with the Activity (e.g. if it is a purchase)
• The payment methods used to pay (e.g. co-branded credit card, cash, etc.)
• A Reason/sub-reason code indicating why an activity was undertaken or in what context.

Each such Activity object is also populated with extension attributes, which can be added dynamically to RCX to reflect the specifics of a given program. This allows Activities to be flexible and model any event from any industry with equal efficiency - for example we can represent a Retail Purchase, an Airline Flight, a Hotel Stay,a Car Rental, a Gaming Rating, etc.

Accruals¶

When an Activity passes through the RCX rule engine, it gets evaluated by the various rules configured for a specific program, and if any of them are triggered, actions may be taken that earn or burn virtual currencies (points).

If a specific rule in the RCX engine has actions that earn points, and that rule is triggered by an Activity, the Activity is associated with an Accrual, which tracks that specific earn.

Each such Accrual is tagged with the id of the Rule that caused it and is also associated with the Activity in a parent child relationship.

For example, if there are two promotions modeled by RCX rules, that say:

• Promo 1: Buy a coke and get 100 points
• Promo 2: Buy a sandwich and get 200 points

And if a customer submits an activity that has both qualifying purchases, then the history of that customer in RCX will contain an Activity and two separate Accruals:

Figure 2. Accruals

Redemptions¶

If a specific rule in the RCX engine has actions that burn points, and that rule is triggered by an Activity, the Activity is associated with one or more Redemptions, which in turn are associated with the Accruals which were burned.

In the preceding example, let's say we have an Activity that burns 150 points to pay for a purchase. If we take into account the accruals from the previous section, the system will produce 2 Redemptions as follows:

Figure 3. Redemptions

FIFO Consumption Model¶

In RCX, the order in which Redemptions consume Accruals is known as First In, First Out (FIFO). This means that a Redemption will consume the oldest Accruals first, and then move on to the newer ones.

During this process of consumption, Accruals maintain a record of how much remaining consumable balance there is on them. Thus, it is possible that the same Accrual may be consumed by multiple redemptions, from potentially multiple Activities.

Here is our previous example, extended with another "pay with points" Activity that burns the remaining 150 points on the second accrual:

Figure 4. Allocation Example - Multiple Redemptions

It is also possible that the same burn Activity, if large enough, may create Redemptions to consume multiple Accruals, from potentially multiple Activities that carry those Accruals:

Figure 5. Allocation Example - Multiple Accruals

Handling Cancellations¶

In some cases, there is a need to back-out a specific transaction, which in RCX is known as a Cancellation. To achieve this, it is important that we can identify the original transaction that was submitted which needs to be canceled.

The process is as follows:

• For each Accrual in the original transaction, the Cancel transaction creates a corresponding Redemption to offset it.
• For each Redemption in the original transaction, the Cancel transaction creates a corresponding Accrual to offset it.
• The processing status of the original transaction changes to 'Canceled'
• The Activity representing the Cancellation is tagged with the id of the original transaction creating a link between the two.

Here is a diagram to illustrate cancelling an existing earn transaction:

Figure 6. Cancelling an Activity

Adjustments¶

Within RCX, Adjustments are trackable as a separate Activity type. In general, adjustments are equivalent to earn/burn that is initiated manually, and will follow the FIFO model. However, because of their separate Activity type they can be reported on separately.

Reason codes and sub-reason codes can also be used on the Adjustment activities to further classify them and break out reporting categories.

Breakage/Expiration¶

Expiration can be done in several ways depending on the program terms and conditions.

Activity-based Expiration¶

Activity based expiration is generally designed to wipe out balances after a certain period of time during which no activity for the member is registered. The time period is configurable, and also the criteria by which we determine what represents "activity" are also configurable.

During Activity-based expiration, the following actions are taken:

• The system determines all members who have not been active over a certain period.
• The system updates all the Accruals with an expiration flag and sets the date on which this happened.
• The system zeroes out the corresponding purse balance.
• THe fIFO allocation mechanism does not consider expired Accruals.

Sliding Window and Fixed Date Expiration¶

Often with Airlines or Hospitality, points expire at a fixed date - e.g. the end of the year, or on a sliding window basis if they are not burned within a certain time period.

Both of these within RCX, are handled in the following way:

• When an Accrual is recorded, it always carries an expiration date, which is configurable.
• The system runs a daily job, checking expiration dates and deducting balances as needed.
• The FIFO allocation mechanism does not consider expired Accruals.