# Fake Accounts: How to Detect Multi-Account Fraud > Detect fake accounts and multi-account fraud with connected evidence, clear eligibility rules, practical reviews, and controls that protect real customers. Author: Younes Published: 2026-10-08 URL: https://blog.kairal.io/fake-accounts-multi-account-fraud ![Detecting fake accounts and connected fraud](https://blog.kairal.io/_img/3f40b689-e5f6-816c-8503-f0183a6d8926/6a34043a-43e5-40ef-ab37-231fe766f2ae/fake-accounts-multi-account-fraud.webp) ### Context Registrations are growing, but the orders tell a different story. Groups of new accounts claim the same welcome offer, target the same limited products, or return to a referral program through another identity. Each account looks plausible on its own. The repeated participation becomes visible when you connect the journeys. Fake accounts and multi-account fraud can distort customer acquisition, loyalty programs, and access to scarce inventory. For commerce teams, the useful task is to establish which accounts are related, what rule they may be breaking, and where a proportionate intervention will protect the business. **Table of contents** ### What are fake accounts and multi-account fraud? A fake account presents an invented or misleading identity. Multi-account fraud involves controlling several accounts to obtain an advantage that a platform restricts, such as repeated new-customer discounts, referral rewards, or extra purchase allocations. The two can overlap, but they are not identical. An operation can use accounts with plausible details to conceal repeated participation. A customer can also have more than one account for an ordinary reason, such as keeping personal and business purchases separate. [OWASP identifies account creation for subsequent misuse](https://owasp.github.io/www-project-automated-threats-to-web-applications/assets/oats/EN/OAT-019_Account_Creation.html) as an automated threat. Detection should follow what happens after registration as well as how the account was created. ### Define the rule you need to protect Start with the restricted benefit. Does the offer permit one redemption per account, per customer, or per household? Does a release limit purchases across accounts? The policy determines which relationships matter and what evidence is needed. Write down the qualifying conditions before choosing a detection threshold. Include corrections, cancellations, account merges, and support exceptions. A reviewer should be able to explain which rule a group of accounts violated. Keep eligibility checks on the server. Account correlation does not repair a coupon that can be redeemed twice through concurrent requests or a purchase limit that a direct API call can bypass. Review those application checks alongside detection. For promotion-specific controls, see the [coupon fraud prevention guide](https://blog.kairal.io/coupon-fraud-prevention). ### Connect evidence across the account journey Build an investigation around several kinds of evidence: - **Account history:** creation times, verification outcomes, previous orders, and earlier enforcement decisions. - **Device and session relationships:** environments recurring across accounts, rapid identity switching, and continuity between visits. - **Behavior:** repeated action sequences, coordinated timing, and accounts consistently targeting the same restricted benefit. - **Network context:** routes and infrastructure that help explain how an operation is distributed. - **Commercial outcomes:** relevant payment references, delivery details, referral relationships, redemptions, and fulfilled orders. Each category has limits. A shared address can describe a family. Similar browser configurations are common. A residential connection can carry abusive activity, while a VPN can belong to a legitimate shopper. Record how strong each relationship is. An exact match to an internal payment reference and a similarity between browser attributes should not silently become the same kind of evidence. Preserve the original values your system is authorized to use so a reviewer can inspect a normalized match. ### Distinguish shared households from coordinated activity Consider several accounts using one laptop and delivering to one address. That relationship deserves context, especially during a popular release. It does not by itself establish that one person controls every account. Now consider those accounts repeatedly switching identities, claiming a benefit restricted to one customer, and reproducing the same order sequence across campaigns. The recurring combination gives the team a stronger basis for investigation. Review timing and outcomes together. Account preparation may happen days before a launch, and an established account may later become part of an abuse operation. Looking only at today's registration volume misses both cases. Include legitimate examples in policy evaluation: household devices, shared work networks, customers replacing an old account, and support-assisted account corrections. Record which examples would be affected before enforcing a new rule. ### Intervene where the accounts claim value Choose an action that protects the rule at risk. A questionable welcome-offer claim may justify checking eligibility or reviewing the discount while ordinary browsing remains available. A group repeatedly reserving scarce inventory may require tighter controls on reservations. Treat uncertain relationships differently from confirmed repeated abuse. Your team can observe a pattern, request suitable verification, review an order, or restrict a specific benefit according to the evidence and the consequences. Plan what the customer sees. A denied discount, a delayed order, and a restricted account need different explanations and support routes. A vague error at checkout makes a correct decision harder to understand and an incorrect decision harder to repair. ### Give reviewers a complete case A useful case shows the affected accounts, the relevant timeline, the relationship between them, the restricted benefit, and the resulting orders or redemptions. Include the policy version and the action already taken. Make the explanation specific. “These accounts share a device” describes a relationship. “These accounts share a device and repeatedly claimed a one-customer offer through the same sequence” explains why the relationship matters. Give reviewers a way to record an innocent explanation, split a mistaken group, and correct an enforcement decision. Retain enough evidence for that review without turning unrelated customer information into an investigation record. Kairal's [COMPOSITE® technology](https://www.kairal.io/product/) helps connect repeat activity across devices, sessions, and accounts. Shared devices become a lead to investigate within the wider behavior. Your eligibility rules and commercial outcomes determine what the team does with that lead. ### Measure confirmed abuse and customer impact Track outcomes across the benefit you are protecting: - **Repeated benefits issued:** which related accounts received restricted value, including cases discovered after fulfillment. - **Confirmed abusive groups:** how many investigations established a rule violation and what happened afterwards. - **Customer completion:** whether eligible shoppers can register, verify, and finish purchasing. - **Appeals and reversals:** which decisions were corrected and which signals caused the mistake. - **Investigation time and recurrence:** how quickly the team understood a group and whether the same pattern returned. Avoid counting every linked account as prevented fraud. A relationship is an investigation lead; a rejected request is an enforcement event. Confirmed abuse and estimated financial impact need their own evidence and calculation method. ### Prepare your next campaign or release Choose one benefit and map its journey from registration to fulfilled order. Agree on the rule, the evidence a reviewer needs, and the least disruptive action that protects it. Test shared-device customers and repeated participation before rolling the policy out. After the campaign, review both abuse cases and successful appeals. Those findings should improve the next policy rather than merely increase the number of accounts flagged. If repeated identities are exploiting your offers or purchase limits, [discuss the account journey with Kairal](https://www.kairal.io/solutions/retail-ecommerce/). Bring the eligibility rule and examples of the relationships your team currently struggles to explain.