Training material for the staff who run the loyalty and engagement program: what every screen is for, which decisions each role may take, the procedures to follow, and the controls that exist to stop a marketing setting from quietly becoming a financial one.
Every reward value in this console moves a recognised liability on the bank's balance sheet. A change to a streak reward is not a marketing setting — it is a financial change that Finance and Internal Audit have to see. That is why nothing in the engine takes effect when you save it. You build a draft, you submit it, a second person approves it, and it applies on the next nightly run. If you find yourself looking for a way around that, you have misread the task.
Root & Rise is six layers stacked on one wallet. Each layer answers a different question, has a different funder, and fails in a different way. You cannot operate the console well without knowing which layer you are touching.
| Layer | What it is | Funded by | Fails when |
|---|---|---|---|
| Onramp | One-time bonus for clearing Level 0 to Level 1 | Growth budget | Bonus paid, customer never returns |
| Foundation | Instant cashback on eligible transactions — cash, not points | Bank's own margin | Rate creeps above the point value |
| Daily Habits | Check-ins, streaks, fraud quizzes — free actions | Marketplace partners | Engagement rises, Trust Score does not |
| Moments | Capped chance reward on a qualifying transaction | Marketing budget | Velocity farming on small tickets |
| Trust Score | Behavioural score that unlocks credit terms | Reduced cost of risk | Used for pricing before cohort validation |
| Marketplace & purpose | Where points are spent; literacy and grants | Partners, bank, donors | A redemption fails and nobody notices |
Points are earned by doing; the Trust Score is earned by banking well. Habits and quizzes never move the score. If they did, the score would be gameable and the credit story collapses. Never approve a change that connects the two.
Every action in the console is attributed to a named person and written to the audit log. There are no shared accounts and no service logins for humans.
| Role | May do | May not do |
|---|---|---|
| Program analyst | Build drafts, create campaigns and templates, raise adjustments, triage fraud alerts, own cases | Approve anything they raised; unmask PII in bulk |
| Program admin | Everything an analyst can, plus approve engine changes and adjustments, manage users | Approve their own submissions; sign the breakage assumption |
| Finance | Sign the breakage assumption, approve point-value and settlement changes, read all cost views | Edit engine rules or campaigns |
| Compliance | Approve customer-facing copy and templates, review fraud dispositions | Change reward values |
| Credit Risk | Own the Trust Score model, approve weight and tier-threshold changes, work the credit desk | Award or reverse points |
| Internal Audit | Read everything, including the full audit log and every reveal event | Change or approve anything |
Names render as A*** K*** everywhere: the customer list, Customer 360, the credit desk queue and the case file. This is not a display preference. Revealing a name is an action with a subject, a reason and a record.
PII-2026-nnn entry is written to the audit log with your name and the time. You cannot suppress it.Reveal one customer at a time. There is deliberately no "show all names" control, because an operator who can unmask a book cannot explain why they unmasked one.
The left rail is grouped by what you are trying to do. A badge means something needs attention: a count of pending items, or a dot on Engine config meaning you have an unpublished draft.
| Section | Use it to | Primary owner |
|---|---|---|
| Overview | Read the program's health in one screen | Program office |
| Layers | See cadence, participation and funder per layer | Program office |
| Customers | Find an account and open its 360 | Analyst |
| Points liability | Read the IFRS 15 position and test breakage | Finance |
| Engine config | Change how earning works — as a draft | Analyst / admin |
| Campaigns | Run bonus mechanics on top of base earn | Analyst |
| Campaign analytics | Judge whether spend worked, against a holdout | Analyst / Finance |
| Approvals | Second-pair-of-eyes queue for every change | Admin / Finance |
| Fraud & abuse | Triage alerts, suspend earning, claw back | Analyst + Compliance |
| Cases | Own and resolve customer issues to SLA | Analyst |
| Credit desk | Price applications with the Trust Score attached | Credit Risk |
| Onramp funnel | Find where Level 0 conversion leaks | Growth |
| Ops & reconciliation | Tie the ledger to the GL; watch the batch | Finance + Ops |
| Board reporting | Assemble the monthly pack from live figures | Program office |
| Partners | Contracts, catalogue pricing, settlement runs | Program office + Finance |
| Audit log | Prove what changed, who changed it, when | Internal Audit |
Read the Overview in this order, every morning. The order matters more than the numbers.
The period selector changes every figure on the screen. Always state the period when you quote a number in a meeting; most disagreements about program performance are two people quoting different windows.
One row per layer: cadence, participation, cost, funder and phase. Use it for two questions. Is a layer earning its cost? — compare participation against cost. Who pays for this? — the funder column is the one to quote when someone proposes making a layer more generous. Daily Habits is partner-funded; Moments is marketing-funded; Foundation comes out of the bank's own margin. Those are different conversations with different people.
Search or filter by tier, then click a row. A click updates the quick-look panel on the right; it does not navigate. To open the full record use Open full Customer 360. This separation is deliberate — scanning a list should not cost you your place.
An adjustment is the only way points enter a balance without a rule producing them. That is why it needs two signatures and a case reference. Raise it from the trace, never from a blank form: the trace attaches the evidence automatically.
ADJ-…. A different person approves it. Raiser and approver can never be the same account.Every line of customer activity opens a trace: which rule fired, what inputs it used, the arithmetic, and the plain-language sentence you can read to the customer. This is the single most useful screen in the console and the one to reach for first when someone asks "why did I get this?"
Traces exist for the awkward cases too, not just the happy ones: a transaction excluded by rule (agent cash-out is not an eligible trigger), a redemption on hold awaiting a biller, a manual adjustment with both signatures, and a campaign award showing base earn and bonus separately. If you cannot explain an award from its trace, escalate rather than guess.
Each trace carries a suggested wording line. Use it. It has been through Compliance, it avoids implying a discretion that does not exist, and it keeps two agents from giving one customer two different explanations.
Outstanding points are a contract liability under IFRS 15. The recognised amount is:
liability = outstanding points × point value × (1 − breakage)
Three numbers, three owners. Outstanding points come from the ledger and are not an opinion. The point value is an engine setting that Finance and Internal Audit approve — read the live figure from Engine config → Point value, never from this manual. Breakage — the share expected never to be redeemed — is an assumption Finance signs and Audit traces, and it is set in the same place, as Booked breakage assumption.
The booked assumption lives in Engine config → Point value. Changing it is a change request: it goes through Approvals with Finance and Internal Audit, and it moves the recognised liability. The slider on the Points liability screen changes nothing — it is a sensitivity tool for asking "what would the position be at a different assumption". If someone says they "changed breakage", establish which of the two they mean before anything else.
This manual deliberately quotes no live values. Every current figure is on screen, and a manual that repeats them goes stale the first time Finance re-signs an assumption. Appendix A lists the values as configured at installation, for reference only.
Lower breakage means a larger liability — and a better program. Customers actually redeeming is the outcome we want. Do not treat a rising liability as bad news on its own; read it with redemption rate beside it. A program with 40% breakage is cheap because it is not working.
The breakage slider is a sensitivity tool, not a setting. Move it to see what the position would be under a different assumption; the booked figure only changes when Finance re-signs the assumption, which appears in the audit log as a re-signature, not a silent edit.
This is where earning is defined. Nothing here is live when you change it. The banner at the top of the section is the truth of your session: "Draft matches the live configuration" or "n unpublished changes in this draft".
Discard changes reverts the entire draft — every tab, including cashback and messaging — back to live. There is no partial discard; if you want to keep some changes, submit those first.
| Tab | What it controls | Watch out for |
|---|---|---|
| Triggers | The events the engine can see — QR, POS, bill, P2P, cash-in, salary inflow — with basis and volume | Deactivating a trigger silently disables every rule and campaign built on it |
| Earn rules | Points per trigger, per-rule caps, on/off | Removing a rule is not the same as disabling it — disable if you may reverse |
| Point value | Rupees per point, minimum redemption, expiry months, rounding, partner subsidy | The single highest-impact number in the console; it reprices the whole liability |
| Habits & streaks | Check-in, weekly bonus, day-30 milestone, free freezes, quiz points and questions per session | Freezes are a retention feature, not generosity — removing them breaks streaks in bulk |
| Trust Score | The five inputs, their weights, lookbacks and definitions; recalculation cadence | Weights must total 100%. Never add a points or habit input |
| Quiz library | Fraud-awareness questions, answers, explanations, live/draft state | Publishing needs Compliance; a wrong answer key teaches customers the wrong lesson |
| Tier ladder | Tier names, score thresholds, cashback %, Moments rate, unlock copy; add and remove tiers | Lowering a threshold promotes a cohort overnight and raises cost immediately |
| Moments | Daily cap, average value, minimum ticket, win rate, budget, eligible triggers | Minimum ticket is the anti-farming control; do not lower it to raise participation |
| Foundation cashback | Channel eligibility and rate multiplier, payout cadence, minimum ticket, monthly cap | Cash, not points — never hits the ledger, so it never appears in liability |
| Templates | Notification copy in three languages, channel, fatigue class | A missing translation means an English fallback most of the book will not read |
| Messaging & rates | Cost per channel, SMS segment sizes, default holdout, fatigue cap, quiet hours | Message length is a budget decision once SMS is involved |
| Backtest | Replays the draft against 30/90/180 days of real history, by cohort | Tells you cost, never behaviour — see 9.3 |
| Simulation | Projects the ledger forward 6, 12 or 24 months on drafted or live rules | Quote the peak and the band, never the closing figure alone — see 9.4 |
| Projection | Forward sandbox for cost and liability | Nothing here reaches production |
Five behavioural inputs, each with a weight, a lookback window and a written definition: repayment and bill punctuality, transaction regularity, savings behaviour, account tenure and dispute history. Weights must total 100% — the tab will not let you submit otherwise. Recalculation is weekly, and the excluded-inputs list is part of the model: campaign awards, habit activity, quiz results, redemptions, manual adjustments and app opens are all explicitly outside it.
Changing a weight changes credit decisions. It requires Credit Risk approval and, before any pricing use, a validated cohort. Say so plainly when asked to "just bump" a weight.
The score itself is produced by a background engine on its own schedule, not by this screen — what you configure here is the definition the engine uses. So a weight change takes effect at the next recalculation, not on approval, and the scores on a customer record are always as of the last successful run. If a recalculation has not run, Ops and reconciliation will show it before anyone notices on a customer record.
A backtest answers one question honestly: what would this rule have cost on transactions that already happened? It cannot tell you whether behaviour would have changed, because the customers in the history were never offered the new rule. The tab lists what it refuses to model — new triggers with no history, quiz changes, Trust Score weights, cashback changes — rather than producing a confident number. Anything behavioural needs a holdout going forward.
Backtest looks backwards; Simulation looks forwards. It projects the points ledger month by month over 6, 12 or 24 months, on either your draft or the live configuration, and it is the screen Finance will ask for before approving anything that changes reward values.
You set six inputs: horizon, basis (drafted or live rules — run both to see the counterfactual), redemption propensity as a share of the outstanding balance each month, monthly customer growth, program adoption as a share of MAU, and the breakage assumption.
It returns points issued and redeemed over the horizon, peak liability with the month it occurs, closing liability, the month-by-month table, a sensitivity band at ±6pp of breakage, and points and recognised cost per active customer per month.
The simulation uses the same relation as section 8 — outstanding × point value × (1 − breakage) — and "outstanding" means the same quantity here as on the Points liability screen. Pick any row and verify it with a calculator. If a figure on this screen ever fails that check, treat it as a defect and raise it; do not reconcile around it.
A simulation is an argument about a range, not a forecast of a number. Quote the peak and the band around it. Never quote the closing figure on its own, never to two decimal places, and always state the four inputs that produced it — a projection without its assumptions is not a projection, it is a guess with a chart.
The screen also lists what it assumes and where it will be wrong: flat adoption and growth, redemption as a constant share rather than the lumpy reality around expiry warnings and festivals, behaviour held constant so a more generous rule pays more on the same activity without being assumed to create activity, and cashback excluded entirely because it is cash and never enters the ledger. Expiry is not modelled as a separate event — because points are spent oldest lot first, very few survive eighteen months, and points never redeemed are recognised through breakage instead. Modelling both would count the same points twice.
Use the two tools together in one sequence: Backtest to price the change on activity that really happened, Simulation to show Finance the liability curve it creates, and a campaign holdout to find out whether behaviour actually moved. Only the third can answer that last question.
A campaign is a bonus that stacks on top of base earn — never a replacement for it. Each campaign is built across four tabs, with the name, ID, status and launch controls always visible.
| Tab | Decisions you make there |
|---|---|
| Mechanic | Trigger, minimum spend, reward shape (flat, per-unit or multiplier), per-customer cap, dates, and a preview of what one customer would earn |
| Audience | Tiers, cities, KYC level, minimum transaction count, lapsed-customer flag — and the control group / holdout % |
| Message | Channel and copy in English, Urdu and Roman Urdu, frozen at submission |
| Cost | Points liability and messaging spend, kept separate, plus pool consumption against the hard cap |
Set a holdout of at least 10% on every campaign. The holdout is eligible customers deliberately not given the bonus, so the difference between them and the treated group is the campaign's effect. Without one you can report spend and activity but you cannot say the campaign caused anything. A 5% holdout on a small cohort produces a confidence band wider than the effect you are trying to measure — that is worse than no test, because it looks like an answer.
Two cost figures are shown and they are never netted together: points liability under IFRS 15, and messaging spend as marketing cost. The pool is a hard ceiling — when it is consumed, awards stop. Lifecycle actions are Submit for approval, Pause / Resume (awards stop immediately; points already issued stay), Duplicate and Delete.
Opens on the portfolio view: total points spend, incremental actives, blended cost per incremental active, and — reported as prominently as the successes — the spend that cannot be read. The scope dropdown switches to a single campaign for its control-group table, message funnel and post-campaign persistence.
Campaigns with no adequate control group are excluded from the blended cost figure rather than assumed to work. This is deliberate and you should not "fix" it by estimating a denominator.
Every submission lands here: engine change requests, campaigns, adjustments, templates and settlement runs. Each shows the requester, role, timestamp, required sign-offs and the full diff. Approving applies it on the next run; rejecting returns it with a reason. Both write to the audit log.
| Change | Required sign-off |
|---|---|
| Point value / rupees per point | Finance + Internal Audit |
| Earn rule or habit value | Finance + Program admin |
| Tier threshold or Trust Score weight | Credit Risk |
| Campaign launch | Finance + Compliance |
| Customer-facing copy or quiz question | Compliance |
| Manual adjustment over 250 points | Program admin (never the raiser) |
| Partner settlement run | Finance + Procurement |
A points program is a fraud target. Six detection patterns run on the same nightly batch as the ledger, so an alert and the points it questions are always the same age.
| Pattern | Threshold |
|---|---|
| Circular P2P | 2 A→B→A round trips inside 24h, both legs earning |
| Agent collusion | 4 customers, one agent, cash-in then cash-out inside 30 minutes |
| QR velocity farming | 12 payments a day just over the Moments minimum ticket |
| Self-referral ring | 3 KYC upgrade bonuses per device fingerprint |
| Quiz automation | Answered under 4 seconds, 5 days running |
| Dormant reactivation spike | 30 transactions in 48h after a bonus |
Nothing here reverses points on its own. A claw-back is the mirror image of a goodwill credit and carries the same dual authorisation.
Every customer issue on the program, with an owner, a priority and an SLA. Cases arrive from app chat, the contact centre, branches and automatically from fraud alerts.
Work the queue by SLA, not by age: a breached case with no owner is the most urgent thing on the screen. Always run the engine trace before contacting the customer — roughly a third of "missing points" cases turn out to be transactions excluded by rule, where the answer is an explanation rather than an adjustment.
Applications with the Trust Score attached, alongside bureau depth. The recommended price is a model output; the analyst may price it. Two standing constraints: preferential pricing from the Trust Score stays gated on risk-model validation, and no decision taken here writes to a core system — the desk demonstrates the workflow and records the judgement.
The case for the score is thin-file customers: someone with two years of punctual bill payments through the wallet and no bureau history is invisible to a traditional score and legible to this one. That is the argument to make, and the reason the score must never be movable by playing a game.
One row per partner with accrued value for the month; the detail panel carries the contract, funding model, redemption rate, monthly cap and the SLA against actual fulfilment. Watch the fulfilment column: a partner outside SLA with a failure rate several times the program average is a customer-trust problem before it is a commercial one, and service credits are netted off the next settlement.
Every item with its points cost, rupee value and — the column that matters — the per-point rate. That rate is not the same across the catalogue: a point buys more against a bill than it does at a partner whose funding rate is lower. Customers work this out, so the catalogue is priced deliberately rather than left to whatever each partner offered. Two standing rules: no item may be priced above the booked point value, and bill payment should remain the best rate available, because it is also the redemption that helps a customer's Trust Score.
Install → registered → KYC started → submitted → Level 1 → first transaction → active in month two, each step showing conversion off the previous one, with the four leaks named alongside cause and proposed fix. Read it with one question in mind: is the bonus the problem, or is the journey? Currently the bonus works at roughly Rs. 74 a head while half of everyone upgraded is gone by month two — which makes the 72-hour window after the bonus, not the bonus size, the thing to fix.
The points ledger tied out to the general ledger, account by account: opening, issued, redeemed, expired, closing, GL and variance. Below it, every nightly job with schedule, duration, records and retries, and the health of each upstream feed.
A streak payout job once timed out with no retry. Three days later it was a customer complaint; three days after that it was a goodwill adjustment with two signatures. Batch reliability is a customer-trust metric, not an IT metric — which is why it is reported here and in the board pack rather than in a systems report.
Choose a period, select sections, build the pack. Figures are read live from the console at the moment of assembly — nothing is retyped, which is why the numbers always match the screens they came from.
The pack leads with DAU/MAU and closes with what did not work: campaign spend with no detectable lift, spend that cannot be judged at all, SLA breaches, open reconciliation breaks. Keep it that way. A board pack containing only good news is a pack nobody can act on, and the first time the bad news arrives from outside the program office you have lost the argument for the program.
Append-only. Every configuration change, approval, adjustment, reveal event, template publication, settlement run and access change, with actor, role, area, diff, reference and result. Filter by area or search by actor, reference or action. Nothing can be edited or removed, including by an administrator. When Audit asks "who changed the ratio and who approved it", this screen is the answer and no other screen is.
| Cadence | What happens | Owner |
|---|---|---|
| Daily, before 09:00 | Ops checklist; fraud triage; breached cases assigned | Analyst on duty |
| Daily | Approvals queue cleared to zero pending over 24h | Program admin |
| Weekly | Trust Score recalculation reviewed; DAU/MAU and the mercenary test read together | Program office + Credit Risk |
| Weekly | Live campaign check: pool consumption, message funnel, early lift | Analyst |
| Monthly, 1st | Partner settlement run; liability revaluation; board pack assembled | Finance + Program office |
| Monthly | Campaign post-mortems, including the ones that did not work | Analyst |
| Quarterly | Breakage assumption re-signed; access review; catalogue repricing | Finance + Audit |
| Situation | Do this, in this order |
|---|---|
| Points issued in error at scale | Pause the rule or campaign → notify Finance → quantify from the ledger → single claw-back request with evidence. Do not reverse account by account. |
| A nightly job fails | Raise with Ops for retry → estimate affected customers → open a case per affected customer if the retry cannot run same day. |
| GL will not tie | Record the break with an owner and target date → do not adjust the ledger to force a tie → escalate to Finance if open beyond 72 hours. |
| Suspected agent or ring fraud | Suspend earning → refer to the Financial Crime Unit → do not contact the customer before FCU advises. |
| Partner outside SLA repeatedly | Claim service credits → throttle the catalogue item → notify Procurement before renewal. |
| Pressure to use the Trust Score for pricing early | Refuse and route to Credit Risk. Cohort validation is a launch gate, not a formality. |
| Task | Where | Approval |
|---|---|---|
| Explain an award to a customer | Customer 360 → activity → trace | None |
| Raise a goodwill credit | Trace → Raise adjustment | Program admin |
| Change a streak reward | Engine config → Habits & streaks → Submit | Finance + admin |
| Launch a festival campaign | Campaigns → New campaign → four tabs → Submit | Finance + Compliance |
| Add a quiz question | Engine config → Quiz library → publish | Compliance |
| Write a new notification | Engine config → Templates → New template | Compliance + admin |
| Suspend a suspicious account's earning | Fraud & abuse → alert → Suspend earning | None to suspend; admin to claw back |
| Pay the partners | Partners → Settlement → Run settlement | Finance + Procurement |
| Prepare the board pack | Board reporting → select → Build | Program head |
| Show Finance a 12-month cost curve | Engine config → Simulation → Run | None to run; Finance signs the change |
| Field | Live value | Effect of raising it |
|---|---|---|
| Rupees per point | Rs. 0.35 | Liability and every redemption cost rise proportionally |
| Minimum redemption | 200 pts | Fewer small redemptions; breakage rises |
| Expiry | 18 months | Longer life lowers breakage and raises liability |
| Daily check-in | 1 pt | Highest-volume line — small changes are large in aggregate |
| Day-30 milestone | 10 pts | Retention lever; paid once per cycle |
| Quiz points | 2 pts × 2 questions | Cheap and partly self-funding via lower dispute rates |
| Free streak freezes | 1 a month | Costs nothing; protects streaks and retention |
| Onramp bonus | 500 pts | Raises upgrade rate; does nothing for month-two retention |
| Moments cap | 1 a day | Direct multiplier on marketing spend |
| Moments minimum ticket | PKR 100 | Anti-farming control — lowering it invites abuse |
| Cashback monthly cap | PKR 400 | Caps the tail without touching the median earner |
| Message fatigue cap | 6 a customer a month | More reach, more SMS cost, faster opt-out |
| Default campaign holdout | 10% | Larger holdout resolves smaller effects; do not go below 10% |
These are controls, not gaps. If a colleague asks you to work around one, the answer is no and the reason is here.
The console runs inside the bank's own data centre. Three consequences you will meet in practice.
This console is a configuration and read surface. It is not where anything is computed. The work happens in background engines running inside the bank's own batch window, and the console's job is to configure them, govern the changes, and display what they produced.
| Engine | Computes | Console's role |
|---|---|---|
| Earn engine | Awards, caps, campaign attribution, expiry, the points ledger | Configure the rules; approve changes; read the trace |
| Trust Score engine | The behavioural score, recalculated on its own schedule | Configure inputs, weights and lookbacks; read the score |
| Detection engine | Fraud and abuse alerts against the pattern thresholds | Triage alerts; record dispositions |
| Liability engine | Nightly revaluation and the GL journal | Hold the point value and breakage assumption; read the position |
| Retention engine | Churn and at-risk scoring — a separate deployment | Display only, and filter campaign audiences by the flag |
Two consequences that come up constantly in practice. A screen showing a stale figure is usually an engine that has not run, not a broken screen — check Ops and reconciliation before raising a UI defect. And the console cannot produce a number an engine has not computed: if the Trust Score recalculation did not run this week, the scores on screen are last week's, and they are labelled as such rather than silently re-estimated.
The customer can see almost everything you can. They can read why an award was what it was, which points expire first, why they got a message, and how their case was resolved. Operate on the assumption that every figure on your screen will be read back to you by the person it belongs to — because it can be.
Figures in this manual are illustrative and consistent with the console build. Thresholds, reward values and tier names remain subject to workshop confirmation. Version 1.0 · August 2026 · Program Office, HBL Microfinance Bank.