Security, availability, and confidentiality - independently audited to meet enterprise data protection standards.
Our real-time first design makes our Loyalty Engine stand out in its processing capabilities in terms of scale, response times, and flexibility.
Trusted by
How ReactorCX processes activities, updates member state, and emits events for enterprise loyalty programs.
The ReactorCX Loyalty Engine is built on a real-time first processing model designed for enterprise-grade efficiency and scalability. The model is structured around Activities: every member interaction with the program is represented as an Activity that flows through ReactorCX.
Each Activity updates Member State, persists to RCX Data, and emits Events for downstream Event Handlers. The architecture supports both purchase and non-purchase behaviors with the same level of control, scale, response times, and flexibility.
Real-time first means ReactorCX processes loyalty activities as they happen rather than queuing them for periodic batch reconciliation. Every Activity is evaluated through the rules engine immediately upon arrival, Member State updates take effect immediately, and downstream Events are published as the activity completes.
The platform-wide <200ms API response SLA reflects this design - not an aspirational target, but the operational standard maintained across 2.6 billion transactions annually in production.
In ReactorCX, an Activity is the general concept that represents anything that happens to a member: a purchase, a redemption, a check-in, a survey response, a tier qualification event, or any other interaction the program is interested in.
This general concept lets ReactorCX handle both purchase and non-purchase behaviors with an unprecedented level of control, because the rules engine treats all activities through the same evaluation path rather than maintaining separate code for each behavior type.
ReactorCX treats purchases and non-purchase engagement through the same Activity model and the same rules engine. This means a loyalty program can configure earning, tier progression, badge issuance, and benefit eligibility consistently across both behavior types.
Engagement-first membership programs that do not use currency at all are supported by the same processing model that handles points-based programs at enterprise transaction scale - no separate configuration, no separate system.
Activities enter ReactorCX through the REST API, which is the synchronous entry point for enrollment, balance and status queries, eligibility checks, reward issuance and redemption operations, and member servicing actions.
The REST API is the same API surface that powers the ReactorCX user interface - so any operation an admin can perform in the platform is available to client systems through the API, with no capability gaps between the UI and the integration layer.
Member State is the unified representation of a member's standing in the program: balances, tier levels, segments, preferences, account status, and any custom attributes defined by the program.
Every Activity that flows through ReactorCX evaluates against Member State, updates it where applicable, and persists the updated state to RCX Data. Member State is exposed to integrated systems through the REST API in real time.
RCX Data is the persistent layer of the ReactorCX processing model, holding member profiles, activity history, rule configurations, accrual lineage, and program operational state. Every Activity that flows through ReactorCX persists to RCX Data, and Member State reads come from this layer.
ReactorCX emits Events in two levels: Replication Events (Level 1, CUD) at the object level for keeping external systems in sync, and Business Events (Level 2) on specific loyalty actions such as point earning, tier changes, reward issuance, and referral completion.
Events flow to Event Handlers either directly through the Event API or through enterprise streaming infrastructure such as Apache Kafka, Pulsar, or cloud streaming offerings from Azure, AWS, and GCP.
Event Handlers are the downstream subscribers that consume ReactorCX Events. Each Event Handler subscribes to the events relevant to its use case rather than processing every platform event, with subscription scope controlled through the same access framework that governs API access.
The Scheduler handles time-based and recurring processing in ReactorCX, including effective-dated rule activation, scheduled promotion launches, expiration warnings, accrual expiration, and other behavior that needs to fire on a schedule rather than in response to a member action.
This is what enables ReactorCX to publish events such as ExpirationWarningEvent, AccrualExpiryEvent, and TierExpirationWarningEvent on their appropriate cadence - without requiring a member action to trigger them.
ReactorCX maintains transaction execution logs that capture which rules triggered for each Activity, which actions executed, input payload details, and processing results. The execution log answers: what happened, why it happened, which rule fired, what actions executed, and what data the platform used to make the decision.
This supports dispute handling, support workflows, debugging, and audit requirements - giving program teams and client support teams a complete view of every processing decision the platform made.
Full execution traceability is not an add-on. Every Activity produces a complete log as part of the standard processing model.
The ReactorCX processing model operates at enterprise scale:
Loyalty Methods has integrated ReactorCX across 30,000+ locations - with the processing model running consistently at these SLAs across every channel, geography, and program complexity.
The ReactorCX processing model honors the privacy mode chosen by each program. ReactorCX supports two modes: storing PII inside the platform with full data subject rights support (access, deletion, rectification, restriction of processing, portability), or operating with tokenized identifiers where PII is stored externally in a client-controlled system.
Activity processing and Member State operate consistently in either mode. MGM Resorts operates ReactorCX with membership numbers only - no PII stored in the loyalty platform.
The ReactorCX processing model runs within the broader SOC 2 Type II certified ReactorCX platform, with encryption in transit (TLS), encryption at rest (AES-256), role-based and attribute-based access controls, and audit logs across access, system activity, configuration changes, and member and transaction activity.
Activity processing, Member State updates, RCX Data persistence, Event publication, and Scheduler operations all run under these controls - the security posture applies uniformly across every component of the processing model.
Choose the best in class solution, team and process to get there.
