MLM Software Development Company in Pretoria

What this page covers, and what it does not claim

No Pretoria office. Pretoria is South Africa’s administrative capital, and the reason that framing is useful here is that this page is about the moment somebody official — or simply somebody serious — asks you for something.

Everything about operating in South Africa generally, including how POPIA consent is captured at the point of collection, is on the South Africa page. This page is about the three capabilities that only get tested under a request.

A data subject request is a query or it is a day’s work

Under POPIA a person can ask what you hold about them, ask you to correct it, object to processing, and in defined circumstances ask you to delete it. The obligation is not the hard part. The assembly is.

In a direct selling platform, one person’s data is spread across more places than in an ordinary business:

• the distributor record and its status history,
• orders they placed as a buyer,
• orders attributed to them as a seller,
• their position in the placement tree and in the sponsorship tree,
• every commission line, in every period,
• uploaded identity and banking documents,
• consent records per channel,
• support tickets and marketing communications.

Assembled by hand across six screens, each request costs a day and probably misses something. As one query against one identifier, it costs minutes and it is complete.

Requests are rare right up until they are not. A departing leader, a commission dispute or a competitor recruiting your field will produce several in a week.

Retention: the configuration nobody does

Skipping retention breaks nothing, which is exactly why it gets skipped. The system works, and it accumulates identity documents, bank details, communications and consent records indefinitely.

That accumulation is two problems at once. It is a growing obligation, and it is a growing breach exposure — the data you no longer need is the data most likely to cause harm if it leaves.

So the configuration is per category, with an action at expiry that actually runs:

The periods themselves are a legal question and they differ by category and by market, which is why they are configurable rather than defaulted. What should not be optional is the mechanism.

Deletion that leaves the ledger intact

The apparent conflict — a person asks to be deleted, and a paid commission is a financial record with its own retention duty — resolves by separating identity from record.

Names, contact details, documents and banking details are removed or hashed. The commission lines, the tree position and the closed-period statements remain as anonymised entries, because removing them would invalidate every statement above and below that position in the structure. Every distributor who was paid on that volume has a statement that must still reconcile.

Where the two duties genuinely conflict, what was retained and why is documented rather than decided silently. The exact boundaries are a question for your attorney.

The audit trail a dispute turns on

Three layers, and most platforms in this category have only the first:

1. Record edits. Who changed a distributor’s details, when, and what the previous value was.
2. Plan changes. The commission rate, rank threshold, qualification rule or cap that was altered — with who, when and the previous value. This is the change a distributor disputes by name, and it is the layer most commonly missing.
3. The run, versioned with its rule set. So a closed period re-executes to identical output after the rules have changed since.

With all three, a question about a payment from two years ago is answered in minutes from records. With only the first, it takes weeks and ends in a judgement call. The commission page covers run versioning and the back office page covers where the audit log sits in the corporate console.

Both are unbackfillable, which is the argument the compliance comparison makes at length: a feature you did not buy in year one costs the same in year two, and a record you did not capture cannot be bought at all.

After an incident

The question after a security incident is scope: whose data, which fields, over what window. That is answerable only if access logs and export logs were retained, so both are, and both are append-only.

Estimating the answer is not an option, because the estimate becomes the notification.

Working with us

SAST hours, a named technical lead in the statement of work, and retention and audit configured during implementation rather than deferred to a phase two that does not get scheduled. The engagement page covers what the work involves.