A shared attribute is a lead, a ring is a finding.

Fictional scenarios and synthetic data. Reviewed 6 November 2026.

Forty new Lagoon Casino accounts claim the welcome bonus in forty-eight hours, all through one referral code. Tomas has a graph on his screen with forty nodes and a great many lines between them. It looks like a ring. Ines asks him to put the lines in order, strongest first, and to say what each one would mean if it were the only line.

What is actually being decided.

Link analysis answers one question: are these entities, which appear separate, in fact one operation? The decision that follows is whether to treat them as one, which usually means holding or reversing something for all of them at once. That is a wide action, and wide actions need strong evidence.

The operator carries the bonus money and the players it interrupts. The PSP carries the chargebacks if deposits turn out to be stolen cards. The analyst carries the inference, and the inference is the whole point. "Twelve accounts share two device references" is an observation. "One person opened them" is an inference. This article is about the distance between those two sentences and how to cross it carefully.

Attributes have strengths, and strength is measured.

Not every shared attribute means the same thing. the useful ordering is by how rarely legitimate accounts share the attribute, and that is a number you can measure in your own data rather than assume.

In this illustration, Tomas pulls the previous full month of Lagoon sign-ups and asks, for each attribute, how many accounts a typical value is shared by.

Country and browser family are shared by thousands of legitimate accounts; as a link they are nearly worthless. IP addresses can be shared in many legitimate settings: one address in the 203.0.113.0/24 range was used by 1,200 distinct accounts last month, which warrants investigating shared infrastructure before attributing the traffic to one person. Device references and deposit credentials can provide stronger linkage in some datasets, but collisions, sharing and identifier stability need to be measured.

The alternative we keep alive, always: a strong attribute can still have an innocent reason to be shared. Two device references across twelve accounts is what a bonus ring looks like. It is also what an internet café looks like, or a family, or a shared phone in a student house. Strength tells you how surprising the link is, not what caused it.

The forty accounts, link by link.

Now the Lagoon cluster, with synthetic numbers.

All 40 share the referral code, the country and the browser family. By the table above, this is expected of almost any forty accounts and tells us nothing yet.

26 of the 40 used one of three IP addresses. One of the three is the carrier gateway with 1,200 accounts last month; the 10 accounts on it are linked only weakly. The other two addresses were used by 9 and 7 of our accounts respectively and by no other account in the month. Those 16 are linked by an IP that is rare in the base population, which is a medium link.

12 of the 40 share two device references. Both references were seen on no other account last month. That is a strong link.

9 of those 12, plus 3 accounts outside the 12, made their first deposit with the same deposit credential token. That is a second strong link, and it connects 3 further accounts to the 12.

Count the cluster reached by strong links only: 12 by device, plus 3 more by credential, is 15. Those 15 are a finding: every one of them is tied to the others by an attribute that legitimate strangers share at the 99th percentile no more than three times. The remaining 25 are reached by the referral code alone, or by a carrier gateway, or by a medium IP link. They are a lead.

The OWASP automated-threats catalogue names the pattern this most resembles, OAT-019 (account creation) feeding a bonus claim, and describes it at the level a defender needs. We cite it for the name, not for proof. The proof is in the table.

Rings have shapes, and the shape matters.

A hub-and-spoke cluster has one attribute at the centre and many accounts on the spokes: one device reference, twelve accounts. Everything is one hop from the hub, and the inference is simple. A chain cluster links A to B by device, B to C by IP, C to D by a credential, and so on. Every hop is a separate inference, and a chain of medium links through five accounts is far weaker than any one of its hops looks on the graph.

Graph tools draw chains and hubs with the same confident lines, and the eye does not discount for distance. Before acting on any cluster, write out the shortest path from each member to the strongest hub, and the strength of each hop. If a member's path runs through a carrier gateway, it is not in the finding, however tidy the picture.

It must be explainable to someone without your tools.

When Stilling Bank, as acquirer, asks why fifteen deposits were refunded and fifteen accounts closed, or when an auditor asks the same in a year, the answer cannot be "the graph showed a ring". The answer is a path anyone can follow: "accounts 1 to 12 share device references D1 and D2, which no other account used in October; accounts 13 to 15 share deposit credential token T1 with nine of the first twelve". Each sentence is an observation with a base rate beside it. The inference, "one operator", is stated once, labelled as inference, and separated from the facts that support it. Write the note for the person who reopens it gives the format. A ring that cannot be explained in that form is a ring you should not yet act on.

A failure mode to watch.

The whole cluster is treated as the finding. Forty accounts came through one referral code, fifteen are clearly linked, so all forty are closed and the referral code is blocked. Twenty-five real players lose a bonus they were promised, the affiliate who owns the code has a legitimate grievance, and the fifteen-account operator is unaffected because they already have another code. The finding was fifteen. The action should have been fifteen.

A way to work it.

1. Before the next cluster arrives, build the base-rate table for every attribute you link on, from a normal month. Refresh it quarterly.
2. For the cluster, list every shared attribute and mark each as weak, medium or strong by the table.
3. Draw the strong-link cluster only. Count it. That is the candidate finding.
4. For each member, write the path to the hub and its weakest hop. Drop any member whose path runs through a weak link.
5. State the inference in one sentence, labelled as inference, with the innocent alternative beside it.
6. Act on the finding with a scoped, owned, reversible action and a review time: hold bonus release for the 15 pending a deposit check, owner Tomas, review in 48 hours, rollback by releasing the bonus. Hold the lead without acting, and set a date to look again.

Take it to the desk.

For each attribute we link on, do we know how many legitimate accounts share it in a normal month?

Try it: Forty new accounts claim a welcome bonus Look up: linked entities · link analysis · cohort

The Volume 01 note Shared signals is the short version of the base-rate argument. One welcome bonus, forty welcomes is the same cluster from the operator's side, and Three layers of a takeover uses the same device attribute for a different question.

Edited 6 November 2026. Primary references are listed above; fictional scenarios are not claims about Antifrog customers or operating experience.

Fictional learning material. Any numerical examples are synthetic. Use only authorised, appropriately minimised records for workplace exercises; do not upload customer information to this learning site.