Submission type: Talk/session proposal - 30-40 mins (25 min talk + 5 min Q&A)
On a quick-commerce app, fraud does not need to be clever. Someone creates an account, uses a coupon or claims a few refunds, and when we finally block the account, they create a new one in a minute. Our fraud models judge an account by its past behaviour, so a brand-new account looks clean at exactly the moment it does the most damage. In one case, 611 accounts belonged to one coupon ring. In another, 347 accounts sat behind one refund ring. So the useful question is not “is this account bad?” but “who else is this account?”. To answer it, we had about 27 million accounts across 67 cities, the things those accounts share (devices, phone numbers, UPI IDs, delivery locations, names, buildings, IP addresses), and no labels telling us which accounts belong to the same person.
This talk is the story of how we linked those accounts, including what did not work. Simple rules broke first: one IP address can be shared by thousands of strangers on the same mobile network, and a building name like “ground floor” connects thousands of people who have never met. A graph-embedding model (node2vec) treated every shared signal as equally important, and its clusters of up to 50 accounts looked just as profitable as normal customers, a sign that it was mixing fraud rings with ordinary users. What worked was mostly careful counting: give each shared signal a weight based on how rare it is (the same idea search engines use to decide which words on a page matter), and learn how much each type of signal proves identity with Fellegi–Sunter, a record-linkage method from 1969 that can be fitted without labels. The surprise came when we gave those same weights to the expensive embedding model: it produced almost the same clusters as the cheap version. The value was in the weights, not in the model. I will also show how we judged clusters with no ground truth, why that judgment could be fooling us, and what a simple blocking rule would have saved when we replayed a day of orders: around 20 paise on every order the platform handled that day.
1. The fraudster who keeps coming back (4 min). Two real, anonymised fraud rings: how they worked and what they cost. We found more than 200 similar rings of each kind across India, all running the same playbook of fresh accounts, coupons and refunds. Why “who else is this account?” is the better question.
2. Seeing the data as a map of shared things (5 min). Accounts on one side, the things they use on the other. Why each signal on its own is noisy. The data cleaning that changed results: names typed in decorative Unicode letters, masked UPI IDs, and “building names” like “1st floor”, “block A” or “home”. Why strong signals (device, phone, UPI ID, push token) can link two accounts on their own, while weak ones (location, name, building) count only in combination.
3. Three attempts, and why we kept the cheapest (8 min). node2vec in one picture, and how its results told us something was wrong. Our counting approach (we call it PRISM), explained with a small worked example: how much a user relies on a signal, how rare that signal is, and how much more often true duplicates share it than strangers do. What the data learned on its own: device, push token, UPI ID and phone are strong evidence; IP address, name and building are weak. Then the same weights inside node2vec: far more compute, nearly the same clusters.
4. Judging clusters when you have no labels (6 min). The “fraud gradient”: if the clusters are real, bigger clusters should lose more money per order and claim more refunds. How we used this to tune the clustering separately for each city. How this check can fool you (it may reward grouping loss-making strangers, like a hostel full of students). The honest test: clusters built from three months of history, then checked against the next day’s orders, which they had never seen. The blocking rule, the money, and how much the result moved between two days we measured (20 paise per order on one, 12 paise on the other).
5. Acting before the first order, and open questions (2 min). How a brand-new account can be matched to an existing cluster in one cheap step, so it carries the history of its older accounts from day one. What I still cannot answer.
- Not all sharing is equal. Two accounts sharing a rare device is strong proof that they are one person. Sharing a common IP address proves almost nothing. Weighting evidence by rarity, using a 50-year-old statistics method, took us as far as a much more expensive model.
- No labels? Decide what “good” should look like, then try to break it. Write down the pattern that real results should show, test it on data the model never saw, and ask how your check could be rewarding the wrong thing.
Anyone who has to decide whether two records belong to the same person or thing: fraud and risk teams, trust and safety, people cleaning customer or patient databases, KYC and lending teams, and platforms fighting promo abuse in gaming, delivery or ride-hailing. Also anyone doing data science without labels. You do not need a background in graphs or ML. Every method is shown with a picture and a small worked example.
I cannot share the raw data, because it contains personal information. I will show real clusters with every identifier masked, and real aggregate numbers. I also plan to share a small synthetic dataset and notebook so people can try the method themselves. The synthetic data can show how the method works; it cannot prove that it works on real fraud.
Mahesh Reginthala is a Senior Machine Learning Engineer at Zepto in Bengaluru. He started and led the identity resolution work in this talk, taking it from an idea to a weekly pipeline that groups about 27 million accounts across 67 cities, and has launched risk models for refunds, delivery verification and store quality checks. He also started Zap, Zepto’s in-house AI support system, whose agents now handle tens of thousands of customer tickets a day. Before Zepto, he built AI ad-creative generation at Walmart, search ranking for a million retailers at Udaan, and ran his own AI start-up for a while. He studied at IIT Guwahati. Across agents, fraud models and search, much of his work has been designing evaluations that hold up in production. The identity resolution system was built together with Prema Chandra Reddy and the Fraud Data Science team at Zepto.
An internal version exists. I will share a public draft with anonymised examples, with comments on, before the editorial call.
- How to check identity clusters without ground truth. Our main check uses money (profit and refunds per order). That is what the business cares about, but it means a method can look good by grouping costly customers who are not actually the same person. I would love ideas: small hand-labelled audits, planted fake duplicates, or other checks that have worked for you.
- Shared living versus shared identity. Hostels, offices, joint families and shared phones create big clusters of genuinely different people. Where should the line be, and how do others draw it?
- Was “cheap matches expensive” just luck? I would like to hear from anyone who has compared simple weighted matching with graph embeddings on their own data.
- I can help with: experience, technique, critique
- I need help with: technique, critique, dataset
- I’d like to meet: practitioners, researchers, domain experts, dataset owners
fraud, entity resolution, evaluation
{{ gettext('Login to leave a comment') }}
{{ gettext('Post a comment…') }}{{ errorMsg }}
{{ gettext('No comments posted yet') }}