Allowlist vs denylist
A denylist (blocklist) forces BLOCK for listed customers, devices, or IPs. An allowlist (whitelist) can override other rules for trusted identifiers. Most traffic should still go through scoring and named rules.
| Dimension | Allowlist | Denylist / block list | Where Naiza fits |
|---|---|---|---|
| When to use | Known-good devices or customers | Confirmed-abusive fingerprints or identifiers | List type on the documented lists API |
| Failure mode | Allowing a stolen known-good device | Blocking a shared family device forever | List reasons and rule context support auditable decisions |
Denylist well
List fingerprints, IPs, or customers you have already confirmed abusive. Naiza supports blocking by email, device fingerprint, or IP with a reason trail. Do not dump entire countries into a denylist.
Allowlist carefully
Naiza supports allowlist overrides for trusted identifiers. Assign an owner, record the reason, and review the entries regularly so exceptions stay current.
The middle path
Naiza combines rules, scores, and lists to return ALLOW, REVIEW, or BLOCK. Review investigation outcomes before adding an identifier to a blocklist.
Frequently asked questions
Answers about screening, risk signals, and Naiza integration.
What is a fraud denylist API?
It lets you persist identifiers that must fail closed—device, IP, or customer—so later events BLOCK without re-litigating the case.
What is an allowlist in fraud?
A set of identifiers permitted to pass even if other signals are noisy. Keep it small and audited.
Does Naiza support both?
Yes. Naiza supports allowlists and denylists through its list controls. The API documentation covers list types, identifiers, and how they are applied during event evaluation.