Should merchants prioritise policy changes or identity-based decisioning first?

Why identity-based decisioning should lead policy tuning

When abuse repeats, the first problem is usually not the rule itself but the lack of context about who or what is driving the behaviour. Identity-based decisioning gives merchants a way to distinguish a normal repeat customer, a shared device, a scripted actor, and a previously seen risk pattern. That makes later policy changes more targeted instead of broadly disruptive.

Policy changes work best after the merchant can see which accounts, devices, sessions, or payment paths are repeatedly involved. Without that view, stricter thresholds often hit legitimate customers first, while the underlying abuse simply shifts to a different route. The practical advantage of identity-based decisioning is that it turns repeat behaviour into an observable signal rather than a guessing game.

How identity context changes merchant controls

Identity-based decisioning lets merchants move from one-size-fits-all rules to conditional responses. For example, the same checkout pattern may deserve a softer review path for a known customer with stable behaviour, but a tighter challenge when the same signals appear across many recently created accounts or anonymous sessions. The control decision becomes more precise because the merchant is evaluating continuity, reputation, and recurrence, not just the transaction in isolation.

That shift also improves the quality of policy changes. Once patterns are linked to an identity history, merchants can tune friction, step-up checks, velocity limits, and review queues with less collateral impact. In practice, identity context reduces false positives because the control is responding to pattern ownership, not only pattern shape.

Why starting with policy alone usually underperforms

Pure policy changes are often blunt because they assume the same rule should protect every actor equally. In active abuse scenarios, that tends to create a moving target, since attackers adapt to the new threshold while legitimate users absorb the extra friction. Identity-based decisioning gives the merchant a better starting point because it shows which behaviours recur across the same actor, infrastructure, or session lineage.

That does not mean policy is secondary forever. It means policy is more effective after the merchant can segment the traffic. A good operating model is to identify the repeated behaviour first, then set policy at the level where the abuse is actually clustering, rather than at the level of the broadest customer population.

Practitioner Guidance

What to prioritise: Start with the recurring abuse path that causes the most operational pain, such as chargebacks, promo abuse, account takeover, or repeated high-risk checkout attempts. If the same behavioural cluster keeps reappearing, treat that as a signal that the merchant needs identity-aware decisioning before more rule tightening.

What to verify: Check whether the merchant can reliably link repeat behaviour across sessions, accounts, devices, or payment attempts without over-merging distinct customers. If that linkage is weak, policy changes will be noisy and the team will keep tuning thresholds by feel instead of by evidence.

Decision rule: If the abuse pattern is recurring and attributable, prioritise identity-based decisioning first; if the issue is isolated or one-off, a narrower policy adjustment may be enough. The goal is to avoid broad controls when the merchant still cannot tell which actors are actually driving the loss.

Practitioner takeaway: Identity-based decisioning is the better first move when repeated abuse is the problem, because it makes later policy changes more accurate and less punitive to legitimate customers.

Related resources from NHI Mgmt Group

• Should organisations prioritise external exposure or internal credential governance first?
• Should organisations prioritise password policy enforcement or data classification first to reduce identity attack impact?
• Why do identity-first security models depend so heavily on policy-based access control?
• Should banks prioritise passkeys over other identity changes first?