multiAccount vs accountSharing: Two Signals, Two Abuse Patterns

Two of Prynt’s behavioral risk signals look almost identical on paper. Both count how many of your accounts have appeared on one device. Both end up in the risk score and in reason codes. But they’re tuned for different abuse, and using the wrong one in a rule either misses the problem or floods you with false positives.

This post lays out what each signal measures, which pattern it’s built to catch, and how to write rules that use them well.

What each signal counts

Both signals count distinct linkedId values seen on one device (one visitorId) inside a time window. linkedId is your account id, attached either at identify time or afterwards with PUT /v1/events/{requestId}.

	multiAccount	accountSharing
Window	30 days	24 hours
Fires when	2 or more distinct accounts	More than 3 distinct accounts
Counts the current account	Yes	No, prior events only
Rule fields	multiAccount (true/false), distinctAccounts30d (number)	accountSharing (number of distinct accounts)
Reason code	MULTI_ACCOUNT	ACCOUNT_SHARING

On the server, GET /v1/events/{requestId} returns both under risk.signals:

{
  "risk": {
    "signals": {
      "multiAccount": { "distinctAccounts30d": 3, "windowDays": 30, "detected": true },
      "accountSharing": { "distinctAccounts": 1, "detected": false }
    },
    "reasons": ["multiAccount"]
  }
}

When both would fire, only accountSharing adds to the score. The two aren’t stacked, so a device switching between five accounts today isn’t double-penalized for also having had them this month.

Behavioral signals like these come with Smart Signals on the Pro plan and above. On any plan, the event also carries accountsOnDevice, the full list of accounts ever linked to the device, which is what the signup recipes use for hard limits.

multiAccount: the slow pattern

multiAccount is designed for abuse that happens over days or weeks:

• Repeat free trials. A user signs up, uses the trial, and comes back two weeks later with a new email.
• Bonus and referral farming. A second account to collect a new-user bonus, a third to refer the second.
• Ban evasion. A suspended user returns on the same laptop with a fresh account.

None of these produce many accounts in one day. A threshold of two over thirty days is low on purpose: for most consumer products, a second account on the same browser within a month is unusual enough to be worth a look, and for trial-based products it’s the exact thing you want to catch.

It’s also the signal most likely to touch legitimate users. Couples sharing a laptop, someone with a personal and a work account, a support agent testing signup. That’s why its default weight is small. On its own it nudges the score; combined with a VPN, a fresh disposable email or automation signals, it pushes toward challenge or block.

accountSharing: the fast pattern

accountSharing looks at a single day and fires only above three accounts. That pattern looks different:

• Account farms being worked. One operator logging into many accounts on one machine to claim daily rewards, post content, or move funds.
• Mule and cash-out operations cycling through accounts on a shared device.
• Shared kiosks and terminals in shops, libraries and internet cafés, which are legitimate and look the same.

That last point is why accountSharing needs context in rules. Four accounts in a day from a library terminal is normal. Four accounts in a day from a residential laptop on a datacenter IP is not.

A note on the name

“Account sharing” often means one account used by several people, the password-sharing problem streaming services care about. Prynt’s accountSharing is the opposite direction: one device used by several accounts. One account appearing on many devices is the deviceSpread signal (more than five distinct devices for one account in 24 hours). If password sharing is what you’re after, read detecting credential sharing and write rules on deviceSpread.

Feeding the signals

Both signals are empty until you tell Prynt which account is which. Two ways:

// at login, when you know the account: pass linkedId to identify()
const { requestId } = await prynt.identify({ tag: { action: 'login' }, linkedId: user.id });

// at signup, after the account exists: attach it server-side
await prynt.updateEvent(requestId, { linkedId: String(user.id) });

Do both. Login events keep the 24-hour accountSharing window accurate; the post-signup updateEvent is what makes the next signup see this account in multiAccount and accountsOnDevice.

Rule examples

The console rules engine accepts multiAccount, distinctAccounts30d and accountSharing as fields, with operators eq ne gt lt gte lte in and actions allow, challenge, block or tag. Rules run by priority, and a block always wins over an earlier challenge.

A starting set for a SaaS product with free trials:

Priority	Field	Op	Value	Action
10	distinctAccounts30d	gte	4	block
20	distinctAccounts30d	gte	2	tag (rule named repeat_trial)
30	accountSharing	gt	3	challenge

The tag doesn’t change the decision; the rule’s name rides along in risk.tags on the server event (and decision.tags in the browser result), so your signup handler can route those accounts to phone verification instead of refusing them.

For a consumer app with shared devices (families, kiosks), loosen the multi-account rule and lean on combinations. Since each rule is a single condition, combine them in your server code:

const s = event.risk?.signals ?? {};
const many30d = (s.multiAccount?.distinctAccounts30d ?? 0) >= 3;
const anonymized = event.smartSignals.vpn?.result || event.smartSignals.datacenter?.result;
if (many30d && anonymized) return holdForReview(event);

Read them together with reason codes

Reason codes are what make these signals usable in a review queue. An event with MULTI_ACCOUNT alone is a household or a returning trialist; one with MULTI_ACCOUNT, EMAIL_DISPOSABLE and RESIDENTIAL_PROXY is someone working at it. An event with ACCOUNT_SHARING and AUTOMATION_BEHAVIOR is a farm being worked by a script. Explainable reason codes covers how to build triage around them.

Start by tagging rather than blocking on both signals for a couple of weeks. Look at what the tagged devices actually did, then promote the combinations that are clearly abuse into block rules. Multi-accounting detection covers the wider strategy, and the field reference lives in the docs.