Risk treatment suggestions

Geelab provides risk evidence and signal information; your business system determines the final disposition. Current recommendations can be grouped into pass, review, and reject. They are guidance for your team, not a final decision returned by Geelab.

Pass

Suitable for:

• Signal risk is low.
• confidence is not enough to support strong disposition.
• The business is very sensitive to false interceptions.
• There are no other abnormalities in user behavior and history.

Letting go does not mean ignoring the signal. You can still record the event as a basis for subsequent observations and model analysis.

Record observations (review)

"By Observation" is suitable for scenarios where further confirmation is needed, but immediate rejection is not desired. Flexible processing can be used:

• Require additional verification code or SMS verification.
• Delay in issuance of benefits.
• Reduce the limit for a single operation.
• Added logs and manual review marks.
• Continue to observe subsequent device and account behavior.

For login, payment or content access scenarios where misjudgment costs are high, it is recommended to give priority to observation or enhanced verification rather than direct bans.

Enhanced verification

Enhanced verification is suitable for scenarios where the risk signals are clear but still require users to complete additional proofs, such as:

• SMS or email verification code.
• Multi-factor authentication.
• Log in again.
• Manual review.
• Secondary verification of order or identity information.

Authentication methods should match business risk to avoid adding unnecessary friction to all low-risk users.

Restrict operations

When you wish to reduce risk rather than deny access entirely, you can limit specific actions:

• Suspension of receiving benefits.
• Limit registration or withdrawal frequency.
• Limit the amount or number of transactions per transaction.
• Suspend high-value operations.
• Only viewing is allowed, no modification or submission is allowed.

Restriction policies should target risky actions as much as possible, rather than indiscriminately blocking entire accounts or devices.

Block (reject)

"Reject" is suitable for scenarios where multiple signals appear simultaneously, risk confidence is high, and the business clearly allows blocking. Blocking can appear as:

• Deny the current request.
• Pause current operation.
• Ask to contact human support.
• Cool down high-risk actions.

For blocking sensitive services, it is recommended to use observation, enhanced verification or restriction operations first, and then expand the blocking scope after confirming the misjudgment rate.

Don’t ban permanently based on a single signal

There may be reasonable explanations for individual signals, and they may be affected by the platform, network, and device environment. Unless your business is fully verified and explicitly accepts the cost of miscalculation, it is not recommended to permanently ban a user or device based on a single signal.

A safer approach is:

1. Combine multiple signals.
2. View the historical events of Device ID.
3. Compare the account number and business behavior.
4. Evaluate level, confidence, and the cost of false positives.
5. Use observation or enhanced verification first.
6. Continuously monitor disposal results and adjust strategies.