Ops Console
Business, risk and compliance teams configure and run the entire programme.
A bank-grade loyalty platform with real-time accrual, a no-code rule engine, three ways to redeem and a complete audit trail — built to sit alongside your core banking and channel systems, not replace them.
Business, risk and compliance teams configure and run the entire programme.
White-label, mobile-first app for balances, rewards and redemption.
For the bank's own mobile app, POS network and core banking feed.
Every screen, API and report reads from the same services and the same business logic. The balance a customer sees can never drift from what a service agent or the bank's own core system sees.
Four integration paths — same downstream result. The rule engine and the ledger never know which path a transaction arrived by.
Transactions are evaluated against active rules in seconds, not on a nightly batch cycle.
Business users author rules, tiers, campaigns and field mappings without engineering involvement.
Append-only ledger, maker-checker and full audit trail are foundational, not bolted on.
Transactions stream in and are evaluated against every active rule in seconds. Customers see their reward while the purchase is still fresh — the single biggest driver of programme engagement.
Two interchangeable authoring modes — a condition-tree editor and a drag-and-drop canvas — designed for business users rather than engineers.
Test any rule against sample transaction data and see exactly what it would award before a single customer is affected.
Per transaction, per day, per month or lifetime per customer — enforced correctly even when several rules match the same transaction.
Each rule is drafted, reviewed and approved by a second person before it takes effect. Full audit trail, no exceptions.
When points post overnight, the reward is disconnected from the purchase that earned it. Real-time accrual closes that gap — and makes time-boxed campaigns, streaks and instant multipliers possible in the first place.
Blanket earn rates are expensive and rarely change behaviour. Tiers and segments let the bank concentrate reward spend where it actually moves the needle.
Configurable tiers with automatic movement up and down, driven by customer behaviour and evaluated by the same engine that awards points.
Segments defined from behavioural and profile attributes; rules and campaigns can target any segment directly.
See which rules and segments are genuinely driving lift, rather than assuming.
Three views on one screen, built to answer the question every programme owner is asked.
Which specific rule produced the accrual, and what it cost in points liability.
Whether a targeted segment is genuinely outperforming the customer base as a whole.
Whether customers are climbing tiers, stalling, or quietly falling back down.
Because targeting, earning and reporting all run through the same rule definition, a campaign's results are attributable to the exact rule that produced them.
There is no reconciliation between a marketing tool and the points system, because there is only one system.
Points only feel valuable when they are easy to spend. The platform supports catalogue vouchers, direct payment at a merchant till, and cash-back straight onto the customer's own card or account — from a single catalogue and a single balance.
Merchant-branded vouchers, browsable and redeemable from the customer app — or by a service agent acting on the customer's behalf.
Redeem points directly against a purchase amount at a partner merchant's till, OTP-secured, with no catalogue item required.
The customer converts points to cash-back credited onto their own card or account, settled through the bank's existing process.
A configurable, weighted prize wheel with a daily spin allowance in the customer app. Prizes are points, credited to the ledger like any other accrual.
Challenges generated from a customer's own transaction patterns — a spend target on categories they already use — with bonus points on completion.
Admin-managed banner campaigns on the customer home screen, so the bank can merchandise offers and new partners without a product release.
Launched by single sign-on from the bank's own mobile or web banking, so the customer never re-authenticates and never feels handed off to a third party. Arabic-first, with right-to-left layout throughout.
A home screen with balance and currency-equivalent estimate, earned, spent and expiring summary, recent activity and active promotions. A voucher catalogue they can filter, redeem from and revisit with the original code and PIN. A partner directory of every pay-with-points merchant. And an account view with profile, points-expiry schedule and notification preferences.
Full multi-channel notification delivery: in-app feed, WhatsApp, SMS, email and push. One-time codes, points-credited confirmations, redemption receipts and two-stage expiry warnings are sent on each relevant event — the cadence regulators expect and customers respond to.
Every customer screen reads from the same services and business logic as the Ops Console and the bank's own APIs, so a customer, a service agent and the core system always see the same number.
Points are a liability on the bank's balance sheet. The platform treats them that way — with the same controls a core banking system would be held to, and the evidence trail an internal audit or a SAMA examiner will ask for.
Every point earned, spent or adjusted is a permanent, immutable record. Nothing is ever overwritten, so any balance can be reconstructed from history.
Rule changes, manual adjustments, voucher and merchant approvals and conversion-rate changes all require a second approver — enforced at the database level, not just in the interface.
Every staff action and every access to profile data is logged, searchable, and viewable as an old-value and new-value difference directly from the Ops Console.
Automatic flagging of unusual redemption velocity, a compliance review queue, and the ability to suspend a customer's earning or redemption immediately.
Roles are fully configurable — defined, scoped and combined to match the bank's own operating model, with separation of duties enforced by design. This configuration is a working starting point.
Configurable expiry policy, plus a two-stage advance-warning notification to customers before points lapse — the pattern regulators expect, and the one that avoids complaints.
Customer data handling designed against PDPL: lawful basis for profile and behavioural data, retention limits, access logging on every profile view, and deletion that propagates rather than leaving orphaned records in the ledger.
An executive view for the people accountable for the programme, and a full reporting suite — every figure attributable — for the people who have to reconcile it. The executive dashboard covers outstanding points liability, active and newly enrolled customers, accrual and redemption trends, and tier distribution, filterable across 7, 30 and 90-day windows.
| Report | What it answers |
|---|---|
| Accrual summary | What was earned, by rule, over any period |
| Redemption | What was spent, through which channel and against which merchant |
| Manual adjustments | Every hand-made change, with the agent and the approver named |
| Points expiry | What lapsed, when, and what was warned in advance |
| Spin & Win | Prize distribution and points issued through the wheel |
| Fraud flags | What was flagged, who reviewed it, and how it was resolved |
| Merchant settlement | Gross, commission and net payable per merchant per month, reconciliation-ready |
Each report drills down to the specific rule, agent or reviewer responsible — what turns a report from a management summary into an audit artefact. All reports are filterable and CSV-exportable.
Four independent ways for transactions to reach the platform, all producing exactly the same downstream result. The rule engine and the ledger never know which path a transaction arrived by.
The platform's own topic, where the bank integrates its core banking system directly into a real-time stream.
Where no real-time feed exists. Upload a file and receive a per-row accepted and rejected reconciliation file back, with a reason against every rejected row.
Rather than requiring the bank to publish onto the platform's topic, the platform connects out to a broker the bank already owns and exposes.
Signup, status check, redemption and cash-back endpoints for the bank's own channel apps, authenticated through a dedicated OAuth2 client-credentials mechanism entirely separate from staff login.
The same batch and API pattern carries KYC status, contact details and profile updates from core banking into the platform, so customer data stays aligned without manual re-keying.
A loyalty ledger under concurrent load is where correctness bugs hide: two approvals racing on the same rule, the same voucher redeemed twice, an OTP used in parallel. These are treated as design requirements and proven under adversarial and load testing rather than assumed in code review.
AES-256-GCM for every external connection secret held by the platform.
With tighter limits applied to authentication and credential-exchange routes.
CORS locked to known origins and standard security headers applied on every response.
Formula injection neutralised on every field of every CSV export.
Load testing surfaces race conditions in maker-checker approval, OTP redemption and duplicate voucher redemption. Each is closed with atomic, database-enforced guarantees rather than application-level checks that fail under contention.
Structured logging, error tracking and Prometheus-compatible metrics — vendor-neutral, so it works with whatever log, metrics and error stack the bank already runs.
Database, cache and message broker are each checked separately, so a partial outage is immediately diagnosable rather than a mystery.
Containerised backend, Ops Console and Customer Portal, each with its own production build.
One backend serves both web apps and every API surface, deployed for the bank alone — no shared tenancy, and data stays inside the bank's chosen environment.
Automated unit tests, end-to-end browser tests and build verification run on every change.
Points post in seconds, not overnight.
Business users own the programme, not engineering.
Four integration paths, including the bank's own broker with zero-code field mapping.
Append-only ledger, maker-checker, full audit trail — foundational, not bolted on.
Web, mobile SSO, in-store POS and bank APIs share the same rules, balances and history.
Concurrency and security issues found and closed through real adversarial and load testing.
No. It sits alongside core banking and channel systems and consumes transactions from them. The core remains the system of record for accounts and balances; the platform is the system of record for points, rules and redemption.
When points post overnight, the reward is disconnected from the purchase that earned it, which weakens the behavioural link the programme depends on. Real-time accrual also makes time-boxed campaigns, streaks and instant multipliers possible at all — none of those work on a nightly cycle.
Yes. Rules are authored in a no-code builder, simulated against sample transaction data before go-live, and promoted through maker-checker approval with old-value and new-value differences retained for audit. A campaign is a rule with an audience, so targeting, earning and reporting all reference the same definition.
Three ways from a single catalogue and a single balance: merchant-branded vouchers redeemed in the app, pay-with-points directly against a purchase at a partner till secured by OTP, and cash-back converted onto the customer's own card or account through the bank's existing settlement process.
Points sit on the balance sheet, so the platform applies core-banking-grade controls: an append-only ledger where nothing is overwritten and any balance can be reconstructed from history, maker-checker enforced at the database level rather than only in the interface, and a full audit trail of every staff action and profile access.
Four independent integration paths exist and none is mandatory: a direct streaming feed, CSV batch upload with per-row reconciliation, connecting outward to a broker the bank already owns with business-user field mapping, and channel APIs. All four produce the same downstream result.
The customer application and operations console are built Arabic-first with right-to-left layout. Customer data handling is designed against PDPL, points-expiry policy includes advance customer warning, and voucher and settlement reporting is produced in a form finance and compliance teams can reconcile, including for VAT treatment.
A working session of about ninety minutes is usually enough to configure a live earn rule, run it against sample transactions, and walk the resulting ledger entry, approval trail and report — using your products, your tiers and your terminology.