Security and Compliance

Points are money that has not been spent yet, and they are stolen the way small amounts of money are always stolen: by the people closest to the till, in quantities nobody notices, using the system exactly as it is designed to work. BigLedger has no fraud engine — no velocity limits, no store-level issuance caps, no impossible-travel checks, no rotating codes — so every control here is a person looking at something, and this page names what they look at.

Watch for the three ways points are stolen, and what catches each

A cashier puts their own card — or a friend’s — on a stranger’s sale

A walk-in customer does not ask for points. The cashier attaches a card anyway, and a thousand ringgit of somebody else’s shopping earns points onto a card the cashier controls. It costs the customer nothing, which is why nobody complains, and it can run for years.

What catches it: one card appearing on an implausible number of bills, across branches or shifts it should not span. No screen ranks cards by points earned — the member reward redemption route in the Sales Report looks like one but loads no points data — so the list comes from the point transaction lines (…/membership-points-txn/lines/query, filtered to REWARD for the month): count the lines and sum the points per card, look at the top of the list, and ask whether that member’s shopping pattern is a real person’s. A staff card doing it will also show up at a single till.

Who and when: the branch manager, monthly, on their own branch’s list — and somebody at head office on the group list, because a cashier who moves between GS-KV-01 and GS-KV-02 is invisible to either manager alone. They know the check was done properly when they can name the top five earning members in their branch and say who each is.

A cashier redeems a balance without the member there

Points are redeemed against a card number, and a card number is not a password. A cashier who knows a member’s number can spend their balance on a stranger’s bill — or on their own — and the member finds out weeks later when their balance is short.

What catches it: the member’s own Point Transaction tab, read backwards from the complaint. Every redemption line carries the document, the branch, the cashier who created it and the date, so a disputed redemption resolves to one bill at one till. The preventive control is POS_ALLOW_VERIFIED_MEMBER_REDEEM_POINTS, which restricts redemption to members whose verification status is VERIFIED — it does not prove the member is present, but it stops a card number invented at the counter from spending anything.

Who and when: whoever handles member complaints, the same day the complaint arrives, because the evidence is complete and sitting on the member record. They know they have finished when they can tell the member which branch, which bill and which cashier.

Somebody adjusts points and gives no real reason

Add Point Adjustment writes points onto any member, requires a branch and an item, and goes in as a transaction of type ADJ stamped with the login that keyed it. The reason is optional free text, so a blank or “goodwill” is as acceptable to the product as a genuine explanation. And the form’s Display Type can be set to HIDDEN, which removes the line from the member-facing history — though never from the member’s Point Transaction tab in the applet, which keeps it with its creator and date. Do not look for it in the Audit Trail: the adjustment form writes its line without an audit-trail entry, so the Point Transaction tab is the record.

What catches it: reading the adjustment lines, all of them, with the reasons. They are a small population and they are the only points in the system a person typed. Look for the same reason repeated, adjustments onto members with no purchase history, and HIDDEN adjustments — there is a legitimate use for hiding a line, and there is exactly one good reason to hide it from the person it belongs to.

Who and when: somebody outside the branch, monthly, from the point transaction lines (every ADJ line for the month, with its reason and creator). They know it is under control when every adjustment in the month can be matched to a complaint, a goodwill decision or a correction somebody else authorised.

Separate the three where you can

Three acts, and one person holding all three is the exposure: issuing a card, awarding or adjusting points, and redeeming them at the counter. The product will let one login do all three, so the separation is yours to impose, and the instruments are these:

There is no approval workflow on a point adjustment. The product’s approval engines cover purchase orders, purchase and stock requisitions and claims, not membership, and there is no amount threshold anywhere. So the second signature is a person reading the adjustments afterwards, not a screen refusing them beforehand — which is why the monthly review above is the control and not a formality. If a large adjustment must genuinely be approved before it is made, the only version of that available is a written request going to the one person who holds ALLOW_EDIT_MEMBERSHIP_POINTS, and the evidence is the written request, kept by you.

Decide whether staff may hold cards, and write it down

Staff cards are how the first fraud starts and also how a legitimate staff discount programme works, so the question is a policy one and it has to be answered before it happens.

Nothing in the member record marks a card as staff. If you allow them, make them identifiable before you issue the first one — a member label used for nothing else, or a dedicated member class — so that the monthly review can separate staff cards from customers’ rather than arguing about them. If you do not allow them, say so in the staff handbook, because the product will never refuse one.

Tell your cashiers that a card number is not a password

A card number identifies a member and proves nothing about who is holding it. It is printed on the card, it is searchable in the listing, and on the storefront the QR code widget encodes the card number in plain text, so any phone that photographs a member’s screen has it.

So a card number alone must not release points. Whoever writes the counter instructions says what else is required — the physical card, the member’s phone number read back, a verified member status — and the way to know the instruction landed is to ask a cashier what they would do if somebody recited a card number from memory.

What is audited

• Membership Admin → Audit Trail: applet code, table, action, user, device, dates, for every member created, changed or deleted; an update keeps the old and the new record side by side. A point adjustment keyed on the form is not in it — its own line, with Created By, is the record.
• Every point transaction line carries its transaction type (REWARD, REDEEM, ADJ, EXPIRY and the rest), the document and line it came from where there is one, Created By and the branch.
• A voucher’s Audit tab and each ticket’s Ticket History (location, description, document, entity, quantity, amount, posting status).
• A member-changes webhook exists if you subscribe to it.

Nothing turns any of it into a warning about people. Membership Admin offers no alert, no digest and no exception rule over the Audit Trail or the point transactions. The one standing alert in the module is the membership points exception report (a Scheduler processor that e-mails it to the company addresses when scheduled), and it checks data integrity — wrong-signed or zero points, the same points posted twice within two minutes, a redemption larger than the balance — not any of the three patterns above. So an audit record is evidence for an investigation somebody decides to open — which is what makes the monthly reviews on this page the actual control.

Integration security

External systems reach members and points through the platform API with the headers on the authentication page; most member and points endpoints come in backoffice-ep, etl-ep and member-login variants. Give an integration its own access key and the narrowest permission family — and remember that an integration holding the points-write family is a fourth person who can adjust points, and belongs in your monthly review like the other three.

What is not here

• No certification. This wiki does not state that BigLedger holds PDPA, PCI-DSS, ISO or any other certification, and no page in it should. Encryption at rest, key rotation and penetration testing are questions for your platform agreement, not features of the membership applets.
• No fraud engine: no velocity limits, no store-level issuance caps, no impossible-travel checks, no rotating QR codes. A voucher’s protections are its per-customer and daily limits, its rules, its soft pin and activation pin, a ticket’s assignment and redeemable dates, and the fact that a serial is redeemed once. Everything else on this page is the substitute, and it is people reading reports on a date they agreed.
• No member authentication in this module — member logins are the storefront’s, documented with CP Commerce.
• No points-liability accounting: outstanding points post nothing. What you owe is built by hand — what you owe your members.