I’ve recently been working on some anti-fraud and anti-money-laundering projects, and it’s given me a much more concrete sense of how telecom fraud and money laundering actually work. E-commerce platforms are an easy target for criminals, and as a product manager you have to design with that risk in mind from the start — if crime ends up happening on your product, the best case is you feel terrible about it, and the worst case is regulatory penalties. Under China’s “dual penalty” system, that liability now runs from the platform all the way down to the individuals responsible. Fighting this kind of crime is everyone’s job.

Reference material

Why do top-up-and-withdraw platforms keep turning into money-laundering tools for scammers? //zhuanlan.zhihu.com/p/151289531

Full text of China’s Anti-Telecom and Online Fraud Law //zhuanlan.zhihu.com/p/560714960

Designing the risk control system

An e-commerce platform’s account system typically has a few core functions: account opening, stored value, transactions, and withdrawals. Each function needs guardrails scoped to its business case from day one, and once it’s live you need to keep thinking about how it could be abused, monitor user data, catch abnormal behavior quickly, and back it up with limits, alerts, and blocking.

At account opening, KYC needs to be done properly — don’t open the door to users who aren’t your intended audience, and if your account system has multiple tiers, map users to the right tier strictly rather than loosely. Don’t loosen these controls just to keep future feature changes flexible or to chase faster growth — you need to weigh business needs against security at design time, and chasing a growth metric while ignoring security can backfire badly.

For stored value, you need to decide which payment channels can fund it. Credit cards generally should be blocked, and B2B transfers into a personal wallet-style account need handling that matches what kind of virtual account the platform actually is. Beyond that: does this user actually need to hold a balance? How much do they typically top up? When do they usually do it? These patterns all need research and matching controls — capping top-up amounts, blocking certain users from topping up at all, disallowing balance payment for certain business lines, flagging top-ups at unusual hours, and so on.

Transaction monitoring is one of an e-commerce platform’s core jobs. Since the platform has already vetted and screened both buyers and sellers on the way in, what’s really left is verifying that a given transaction is genuine. From a fund-splitting standpoint, “transaction” is a broader concept than just a purchase — any transfer from account A to account B counts, and transfers can show up outside the normal buying flow too. You need to check that a transaction makes sense — not just for ordinary purchases, but for any transfer-like movement between user accounts or between merchant accounts. Transactions that come from edge-case business scenarios and don’t map to an actual purchase should be tightly restricted — support the narrowest version of that use case and block anything beyond it. For transactions tied to actual purchases, check frequency and amount to catch buyers and sellers colluding on fake transactions to launder money through the platform, and where needed, verify the paying user’s identity to guard against account takeover or account trading.

A refund back to the original payment method is generally low-risk. Withdrawal is one of only two ways money leaves a user’s account (setting aside platform-side deductions like fees) — so however many issues slipped through earlier, if this last line of defense holds, you avoid an actual loss of funds. Withdrawals need their own security checks, plus tight controls on where the money can go. Withdrawal amount, frequency, and how fast it settles all need risk rules. If it’s a B2B platform where withdrawals aren’t very frequent, manual review is a perfectly reasonable option.

Bottom line: risk control has to guard against competitors, insiders, and unknown bad actors all at once — you can’t design for just one threat. Different bad actors use different tactics. And as a product person, if a piece of business carries a lot of inherent risk, the best move is often to just not build it; if you have to, think hard about which version of it carries the least risk.