Security and Compliance

This page is for whoever answers for the member base at a group like GadgetSphere: the loyalty programme owner, the finance controller who reviews points, and the person your company has made responsible for personal data. A loyalty programme holds two things worth stealing or leaking — points, which are money not yet spent, and members’ personal details, which identify real people. BigLedger stores, shows and records both. It does not watch either of them for you, so this page says what the product keeps and where, and hands each review to a named person on a date. Setting the reviews up takes an afternoon; running them takes about an hour a month.

GadgetSphere Sdn Bhd (GS) enrols members at the till in 22 branches, GadgetSphere Online (GSO) enrols them on its website, and the same card earns and spends in every company of the group. That is the shape every example below uses.

Who answers for what

Who	Owns	When	How they know it is done
Whoever your company names as responsible for personal data	What you collect, why, how long you keep it, and answering a member who asks	Before the enrolment form is printed; then on every request	Every field on the form has a stated purpose, and every request has a dated answer
The person who administers permission sets	Who can see, change and delete members, and who can add points	Quarterly, and the day somebody leaves	The holders of each membership permission match the current staff list (below)
Somebody outside the branches — finance or audit	The monthly read of every hand-keyed point adjustment and the top earners	Monthly	Every adjustment is matched to a reason somebody else authorised
Each branch manager	The top earning cards in their own branch	Monthly	They can name the top five and say who each is
Whoever handles member complaints	Tracing a disputed redemption	The day the complaint arrives	They can tell the member which branch, which bill and which cashier

What the law requires of you as the holder of this data is a question for your adviser; this page describes what the product does, so that the person who owns the duty knows what they are working with.

Know where a member’s details are copied, and who can see each copy

A member’s details do not live in one place. Enrolling a member at GS-KV-01 puts the name, mobile number, e-mail, date of birth and identity number on the membership card, and from there they spread:

The linked customer record. Enrolling usually links or creates a customer, and a new one is created with the member’s name, identity number, e-mail and phone (data management has the detail).
Every bill the member is on. A document copies the customer’s identity when it is issued and keeps that copy, so last year’s cash bills show the details as they were then.
The till’s member search, which shows name, date of birth and mobile number unless the POS hide settings for date of birth and phone are on.
The Membership Report CSV — card number, name, phone, e-mail, gender, date of birth, nationality, ethnicity, marital status, occupation and an address — once anybody runs it.
The points exception report e-mail, which attaches member names in a CSV to the addresses the schedule names, or else to the company’s own e-mail address.
Any webhook subscribed to the member topics. Each create and change sends the member’s record to the address on the subscription, and keeps a copy of what it sent on the webhook’s activity log (webhooks).

So “who can see a member’s details” is a list of people and systems, not one setting. It is everyone who holds the member permissions in a permission set, everyone who can open the till’s member search, everyone who receives the exception e-mail or holds a downloaded export, and every system at the end of a webhook. The till’s hide settings decide what is on display at the counter; who may know a member’s details at all is decided by who holds those permissions (settings and permissions).

One for a group in particular: if the exception report is scheduled for GS, GSO and GSD, each company’s e-mail carries the exceptions of the whole group, not only its own. A finance clerk at the distribution company will read retail members’ names. Send it only to people who may see the whole member base.

Review who holds access, every quarter and on every leaver

The person who administers permission sets runs this list each quarter, and the relevant part of it on the day anybody leaves:

Who holds the member read, create, update and delete permissions.
Who holds the points-transaction create permission — anybody with it can add points to a member.
Who holds ALLOW_EDIT_MEMBERSHIP_POINTS and EDIT_MEMBERSHIP_END_DATE.
Which webhook subscriptions are on the member topics, and whether each receiver still has a reason to get members’ data.
Which access keys your integrations use, and what each may do.
Which addresses the points exception report goes to.
Which old exports are still listed on the Membership Report screen.

What goes wrong without it: a marketing agency’s webhook still receives every new member a year after its contract ended, or a cashier who moved to another company in the group still holds points create from a project. You know the review is done when each list matches the current staff and supplier list, and the date of the review is written down.

Know what correcting or deleting a member leaves behind

This is the part to settle before a member asks you to delete them, because the answer is not on any screen:

Deleting a member sets its status to DELETED. The row, its points history and its links stay.
The Audit Trail keeps a full copy. Each create, change and delete writes an entry holding the record as it was: a correction keeps the old value beside the new one, and a deletion keeps the whole deleted record, with the login that did it.
A deletion notice goes to member-topic webhooks, and each receiver keeps whatever it had.
Bills keep their copy of the member’s identity as it was when each was issued.
The linked customer record is a separate record, but two corrections reach it. A change of name, date of birth or gender on the member is copied onto the individual customers that share the member’s e-mail or phone — up to five — and onto their cards; and saving the member’s E-Invoice tab writes its buyer name, phone, e-mail and identity number onto the customer. Before renaming a member who shares a phone or e-mail with someone else, give the card its own first (Customer and Member).

So a member who asks to be deleted can be stopped from being used — set them INACTIVE or delete them — but their details survive in the history. Whoever owns personal data decides your position before the first request: what you will tell a member, whether you will ask your platform contact what a genuine erasure would involve, and what your adviser says you must keep for the sales records you are obliged to retain. The procedure for answering a request is on data management.

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

Points 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 rotating codes — so each control below is a person reading a record.

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.

What catches it: one card 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 is built from the month’s earning (REWARD) point lines, counted and summed per card, by whoever runs your API extracts. A staff card doing this also shows up at a single till.

Who and when: each 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.

A cashier redeems a balance without the member there

Points are redeemed against a card number, and a card number is not a password. It is printed on the card, searchable in the listing, and the QR code on the member’s own website account encodes it in plain text, so a photograph of a member’s phone screen carries it. A cashier who knows a number can spend that member’s balance on somebody else’s bill.

What catches it: the member’s Point Transaction tab, read backwards from the complaint. Every redemption line carries the document, the branch, the login that created it and the date. The preventive control is the POS setting that lets only verified members redeem: with it on, the till refuses redemption for a member marked UNVERIFIED, REVIEWED or EXPIRED.

A member created at the till is saved UNVERIFIED too, so with the setting on its points wait for somebody to verify the person (Cash Conversion). The setting does not prove the member is present — that is the counter instruction’s job: whoever writes it says what else releases points (the physical card, the phone number read back), and tests it by asking a cashier what they would do if somebody recited a card number from memory.

Somebody adjusts points and gives no real reason

Add Point Adjustment writes points onto any member as a line of type ADJ, stamped with the login that keyed it. The reason is optional, so a blank or “goodwill” is as acceptable to the product as a real explanation. The form’s Display Type can be set to HIDDEN, which leaves the line out of the member’s own history on your website — the Point Transaction tab in the applet still shows it, with its creator and date. That tab is the record of an adjustment: the form writes its line without an Audit Trail entry.

What catches it: reading every ADJ line for the month, with its reason and its creator. They are a small population, and the only points a person typed. Look for the same reason repeated, adjustments onto members with no purchases, and HIDDEN lines — there is a legitimate use for hiding a line, and few good reasons to hide one from the person it belongs to. Somebody outside the branches does this monthly, and it is under control when every adjustment matches a complaint, a goodwill decision or a correction somebody else authorised.

Separate the three acts where you can

Three acts, and one person holding all three is the exposure: enrolling a member, adding or adjusting points, and redeeming at the counter. One login can do all three, so the separation is yours to impose:

The act	What gates it	What to do with it
Enrol or edit a member	The member create and update permissions	Give counter staff create; keep update and delete with fewer people
Adjust points by hand	The points-transaction create permission on the server; and with the `DISALLOW_EDIT_MEMBERSHIP_POINTS` setting on, the applet shows the create button only to holders of `ALLOW_EDIT_MEMBERSHIP_POINTS`	Give both to somebody who does not work a till, and turn the setting on
Change a member’s end date	`EDIT_MEMBERSHIP_END_DATE` (the applet shows the field only to its holders)	The same person as the row above
Redeem at the counter	The verified-members-only setting, which the till enforces	Turn it on, verify members, and decide who may verify them

A point adjustment has no approval step and no amount threshold. So the second signature is a person reading the adjustments afterwards, not a screen refusing them beforehand. If a large adjustment must be approved first, the workable version is a written request to the one person who holds ALLOW_EDIT_MEMBERSHIP_POINTS, and the evidence is that written request, kept by you.

Decide whether staff may hold cards, and write it down. Nothing on a member record marks it as staff. If you allow staff cards, make them identifiable before the first one is issued — a member label used for nothing else — so the monthly reviews can separate them. If you do not, say so in the staff handbook.

What the records show, and what nobody reads for you

Membership Admin → Audit Trail: action, table, who, when, and the old and new values for members created, changed or deleted. The screen lists the entries made through Membership Admin itself; a point adjustment is not among them.
Each point line carries its type (REWARD, REDEEM, ADJ, EXPIRY and the rest), the document and line it came from where there is one, its creator and its branch.
A voucher’s Audit tab and each ticket’s Ticket History.

None of it raises a warning about people. The one scheduled alert in the module, the points exception report, checks data integrity — wrong-signed points, the same points posted twice in two minutes, a redemption larger than the balance — not the three patterns above. A record is evidence for an investigation somebody decides to open, which is why the reviews on this page are the control.

When it goes wrong

What you see	Why	What to do
A member says points were spent at a branch they never visited	Somebody used the card number	Point Transaction tab: the bill, branch and cashier; then the counter instruction and the verified-only setting
A member’s points history online is shorter than the applet’s	Adjustments saved with Display Type `HIDDEN`	Read those lines and the reason each was hidden
A deleted member’s details still appear in the Audit Trail	Deletion is a status, and the trail keeps the deleted record	Treat the trail as part of what you hold; settle erasure with your platform contact
A clerk in one company received another company’s member names	The exception report carries the whole group’s rows	Send it only to people who may see the whole member base
A leaver’s login still holds a membership permission	No review since they left	Remove it today, and run the quarterly review
Adjustments with blank reasons	The reason is optional	Make a reason the rule, and reject blank ones at the monthly review

What success looks like

A thirty-second check. Open a test member in Membership Admin and add a one-point adjustment with a reason. On the Point Transaction tab, find the line with your login as its creator. Change the member’s mobile number, then open Audit Trail and find the change with the old and the new number side by side. Then put the adjustment back. If both are where you looked, the records your reviews depend on are there; if the access-review list from the quarter is dated and matches the staff list, the people side is too.

How this fits with the rest of membership

What it depends on: every act above depends on permission sets and applet settings, which decide who holds each one (settings and permissions). A review cannot start until somebody can list who holds what.
The sibling page, and when to use which: use data management when the question is what you hold and for how long — the enrolment form, consent, exports and members’ requests. Use this page when it is who can see it, change it, or spend it.
What it touches elsewhere: the customer record, every bill and the e-invoice buyer block carry their own copies of a member’s identity, so a correction here does not reach them.
What breaks if it is wrong: a permission set with points create can add points to any member in the group, and the monthly adjustment read fails as a control the day the reviewer also holds it. Grant it as you would a signing authority.
What it is used alongside: in practice the adjustment read also feeds finance, because every adjustment changes what the group owes its members (what you owe your members).
What becomes possible once the reviews run: you can answer a member’s complaint with the bill, branch and cashier the same day, and show your adviser who could see member data as at each dated review.

What this wiki does not claim

No certification. This wiki does not state that BigLedger holds PDPA, PCI-DSS, ISO or any other certification. Encryption at rest, key rotation and penetration testing are questions for your platform agreement; whoever owns your vendor contracts asks them there.
No fraud engine and no retention clock: nothing ages members out or flags a pattern. The monthly reads and the quarterly review above are what stands in for both.
No member sign-in in this module — members sign in on the storefront, documented with CP Commerce.