Thresholds should reflect your users and transactions. A supplier's example value may not represent normal behavior in your application.
Evaluation approach
Assess signal accuracy, transaction loss and user impact together. Different policy classes may be appropriate for low- and high-risk flows.
Application example
Viewing information and adding a payment recipient may require different responses to the same score.
Limits and considerations
A lower block rate is not necessarily an improvement; more attacks may be accepted.
Account for the cost of wrong decisions
Changing an operating threshold can catch more events while affecting more legitimate transactions. Missed incidents and false blocks have different costs, which should be assessed by transaction type.
Keep confirmed incidents, uncertain cases and normal traffic distinct. Do not select thresholds from total event counts alone. Reassess the balance after version or population changes.
Checks and decisions
- Measure both error types
- Separate transaction classes
- Version policy changes
Manage thresholds with reasons and evidence rather than leaving them as unexplained constants.
Sources
The primary references above provide the technical basis. Example workflows and evaluation suggestions are this publication’s explanations, not independent test results for a particular product.