Most security advice for software is about servers: firewalls, encryption, patching. For MLM software that is only half the picture. The other half is about money logic. Who can change a commission rate? Who can move a member in the tree? Who can add to a wallet balance by hand, and would anyone ever find out? A platform can have a perfect server and still lose money to its own users, because the weak point is what a logged-in person is allowed to do.
This checklist focuses on that second half. For where the software is hosted and who looks after the infrastructure, see our guide to cloud vs on-premise hosting. Here the questions are about permissions, approvals, logs, fraud and payouts, with a way to test each one in a demo before you sign.
Quick answer: Check twelve things: role-based access, dual approval for money changes, an audit log, admin two-factor login, confirmation on member withdrawals, detection of duplicate and self-referral accounts, commission reversal on returns, a dry run before every payout, backups that have been restore-tested, protection of KYC and personal data, safe handling of inputs and uploads, and independent security testing. Ask the vendor to show each one working in a demo. A feature that exists only in a brochure does not count.
The 12 checks at a glance
| Check | What good looks like | Weak sign |
|---|---|---|
| 1. Role-based access | Separate roles such as support, finance, plan manager and super admin, each seeing only what the job needs | One shared admin login for everyone |
| 2. Dual approval for money changes | A second person must approve manual wallet adjustments, commission edits and plan changes | One admin can credit any wallet alone |
| 3. Audit log | Records who changed what and when, with the old and new value, and cannot be edited from the admin panel | No log, or a log the same admin can delete |
| 4. Admin two-factor login | Admin and back-office accounts need a second factor, with login alerts and session timeouts | Password-only admin access |
| 5. Withdrawal confirmation | A one-time code or similar check for withdrawals, plus a waiting period after a payout address changes | A changed bank or wallet address works for a withdrawal immediately |
| 6. Duplicate and self-referral detection | Flags for shared devices, bank accounts, KYC documents or addresses across accounts | Anyone can create unlimited accounts under themselves |
| 7. Return and refund reversal | Commissions and volume are reversed when an order is returned or a payment fails | Returned orders keep paying commissions |
| 8. Payout dry run and double-payout guard | A preview of the full payout run, an approval step, and a guard so one run cannot pay twice | Payouts run on a button with no preview |
| 9. Backups with a restore test | Regular backups kept apart from the main server, and a restore actually tried | Backups exist but have never been restored |
| 10. KYC and personal data protection | Documents stored with restricted access, masked in screens where possible, exports limited and logged | Identity documents sitting in a public folder |
| 11. Safe inputs and uploads | Forms validated, uploads limited to expected file types, one member unable to view another's data by changing a number in the address | A member can open someone else's profile by editing the URL |
| 12. Independent testing and updates | A security test by someone outside the build team, with a date and scope you can ask about, plus a policy for applying updates | No test done, or no answer about how often it is updated |
Who can touch the money: roles and approvals
Start with permissions, because most real losses in MLM platforms come from people who already have a login, not from outside attackers. A support agent should be able to help a member reset a password without being able to see bank details. A finance user should be able to approve a payout without being able to change the compensation plan. The person who changes the plan should not be the person who approves the payout that results from it.
The control that matters most here is dual approval, sometimes called maker and checker. One person proposes a manual change, for example crediting a member's wallet after a dispute, and a second person approves it. The software should record both names. If a vendor says all admins can do everything because it is simpler, ask what would stop one dishonest or compromised account from emptying wallets.
The audit log: your record when something goes wrong
An audit log answers the questions that come after an incident: who changed this commission, when was this member moved, who edited this rank. A useful log records the user, the time, the action, and the value before and after. It should cover logins, wallet adjustments, placement changes, rank overrides, payout runs and changes to settings. Just as important, nobody should be able to edit or delete it from the normal admin panel.
Test it in the demo: change something small, then ask to see the log entry for it. If the answer is a database query that the vendor writes live, the log is not part of the product.
Logins, withdrawals and account takeover
- Admin accounts need a second factor and should time out when idle. They can reach every member's data.
- Member withdrawals are the moment an account takeover turns into a loss. A one-time code, or a link to the registered email, makes a stolen password less useful.
- Changing a payout address deserves a delay or an extra check before the next withdrawal. A common attack is to change the address and withdraw in the same minute.
- Repeated failed logins should slow down or lock an account, and members should get a notice when their email or password changes.
- Passwords must be stored as one-way hashes, never in readable form. Ask how they are stored. A vendor who can email your old password back to you is storing it wrongly.
MLM-specific fraud that ordinary security checklists miss
A generic web checklist will not mention the attacks that target a commission plan. These are the ones to ask about:
- Self-referral and duplicate accounts. One person creates several accounts to collect bonuses from their own purchases or to fill a binary leg. Look for flags on shared devices, bank accounts, identity documents and addresses.
- Order and return abuse. Someone buys to hit a volume target, collects the commission, then returns the goods. The software should reverse the commission and volume when the return is recorded.
- Placement manipulation. Moving members in the tree changes who earns. Placement changes should be limited to specific roles, approved, and logged. Our post on genealogy trees explains why sponsor and placement need separate protection.
- Rank and volume overrides. A manual rank change can pay out for years. These overrides need approval and a reason recorded.
- Payout concentration. Several accounts paying out to one bank account or wallet is a pattern worth a review queue.
None of these can be prevented by encryption. They are prevented by rules in the product and by people who look at the reports.
Payout runs: preview first, approve, then pay
A payout run is the highest-risk operation in the system. A safe process looks like this: the system calculates the run, shows a full preview with totals and exceptions, a finance user reviews it, a second user approves it, and only then does money move. The software should also guard against the same run being executed twice, for example if a page is refreshed or a job is restarted. Finally, a reconciliation report should show that what was paid equals what was approved.
If your payouts go through a payment gateway or a crypto wallet, ask how the platform checks that a payment confirmation really came from the gateway. Callbacks should be verified, and the keys that connect to the gateway should be stored outside the website's code.
Data: backups, KYC documents and exports
- Backups. A backup that has never been restored is a hope, not a backup. Ask when the last restore test was done and how long it took.
- KYC and identity documents. These are the most sensitive files in the system. They should be stored with restricted access, not in a folder that can be opened with a link.
- Exports. A member list with phone numbers and addresses is valuable to a competitor. Check who can export it and whether exports are logged.
- Data protection law. Rules differ by country, so confirm with your own adviser what applies to your members. This is general information, not legal advice.
Try it yourself: a safe test script for a demo
Only run these on a demo or test copy that you have permission to test, never on a live system. Each should be stopped by the software:
| Test | What should happen |
|---|---|
| As a member, change the number in the address bar to open another member's profile | Access is refused |
| As a member, try to open an admin page by typing its address | Access is refused or you are sent to login |
| Request two withdrawals in quick succession for more than the balance | The second is refused; the balance never goes negative |
| Change a payout address, then withdraw straight away | A delay or extra confirmation applies |
| Upload a file that is not an image where an image is expected | The upload is rejected |
| Place an order, get commissions credited, then record a return | The commission and volume are reversed |
| As a support user, try to change a wallet balance | The action is not available to that role |
A vendor who is comfortable with this kind of testing in a demo is showing you something useful about their product.
What a checklist cannot tell you
A checklist shows what exists, not how well it is built. Two vendors can both say they have an audit log and one of them may only log logins. That is why the practical step is to watch each item work. Also be careful with badges. Claims such as “bank-grade security” mean nothing without detail. If a vendor mentions a certification, ask which one, who issued it, and what it covers. If they do not hold one, that is a fair answer, and a better one than an unclear claim.
How we approach this
Ask us for each of these in a live demo, and we will show you what is built and say plainly what is not. If your plan or your market calls for controls beyond the standard ones, such as extra approvals or country-specific records, we can build them around your needs. Tell us about your setup and what you want to protect.
Keep reading
- cloud vs on-premise — who looks after the infrastructure and the data.
- How to hire an MLM software company — including how to ask about testing.
- The buyer's checklist — the rest of the buying decision.
See what we build on our custom MLM software page, or compare the software features.
Frequently Asked Questions
What security features should MLM software have?
At minimum: role-based access, an audit log, two-factor login for admins, confirmation on member withdrawals, reversal of commissions on returns, a preview and approval step for payouts, tested backups, and protection of identity documents. MLM software also needs controls against self-referral and duplicate accounts.
Is a blockchain or smart contract MLM more secure than a normal one?
Not automatically. A smart contract can make payouts tamper-resistant, but it also cannot usually be changed after launch, so a bug in the logic is hard to fix. The web application around it still needs the same access controls, logs and checks. See our guide to smart contract clone scripts for the risks.
How do I check a vendor's security claims?
Ask to see each control working in a demo, ask when the last independent security test was done and what it covered, and ask how backups are restored. A confident vendor will answer with specifics. Vague answers, or a badge with no detail, are a warning.
Who is responsible for security, the vendor or me?
Both, and the split depends on the model. On a vendor-hosted platform the vendor looks after the infrastructure, but you still control who has admin access and how your team uses it. If you host the software yourself, you carry more of it. Agree the split in writing.
Can software stop my own staff from misusing the system?
It can reduce the risk with separate roles, dual approval for money changes and a log that nobody can edit, so misuse is harder and gets noticed. It cannot replace hiring carefully and reviewing reports regularly.