TG-Staff 团队 avatar TG-Staff 团队

What to Do About Telegram Bot Risk Control False Positives? A Complete Guide to Sensitive Word Splitting, Whitelists, and Audit Reviews

telegram-bot risk control troubleshooting TG-Staff Pro

What to Do When Telegram Bot Risk Control False Positives Occur? A Complete Guide to Sensitive Word Group Splitting, Whitelists, and Audit Review

In cross-border customer service, Web3, and overseas businesses, false positives in Telegram Bot risk control are a frequent pain point. When agents send messages like “Please provide your USDT receiving address” and it gets blocked, or discussions about “risk control” trigger the word “risk,” customer service efficiency drops sharply, and user experience suffers. This article starts from the root causes of false positives, combined with TG-Staff Pro’s content risk control features, to provide a complete optimization plan from word group splitting, whitelist configuration, to audit review, helping you upgrade your risk control from “one-size-fits-all” to “fine-grained.”

Why Do Telegram Bot Risk Control False Positives Occur? Understanding Common Root Causes

The essence of false positives is that risk control rules are too broad or lack contextual awareness. In B2B SaaS customer service scenarios, common false positives stem from the following contradictions: business keywords (such as “payment,” “address,” “risk”) heavily overlap with risky words, but rules cannot distinguish between “normal inquiries” and “inducing transfers.” Understanding these root causes is the first step in optimization.

Common False Positive Scenario Analysis

Here are three typical false positive cases, covering customer service, operations, and compliance scenarios:

  • Scenario 1: Payment address inquiry blocked Agent reply: “Please provide your USDT receiving address, and we will make the payment after confirmation.” Result: Because the term “receiving address” or “address” is hit, the message is intercepted by a popup, requiring the agent to confirm twice before sending, prolonging user wait time.

  • Scenario 2: Business risk discussion triggers risk word Agent discussing in internal group chat: “We need to evaluate the risk control strategy for this project.” Result: Because “risk” is configured as a sensitive word, normal business communication is misjudged as violating content, affecting team collaboration efficiency.

  • Scenario 3: Wallet address fragment accidentally catches daily conversations Configured TRC20 address fragment “T9” (the shortest address start) as a monitoring word. Result: When agents send irrelevant messages like “Please reply before T9 o’clock,” they are mistakenly blocked, causing unnecessary operational interruptions.

Impact of False Positives on Customer Service Efficiency and User Experience

The ripple effect of false positives cannot be ignored:

  • Session interruption: Popup interception forces agents to pause replies; users see “typing…” and then sudden silence, worsening experience.
  • Increased operational cost: Agents must click “Continue sending” or “Cancel” each time; with high-frequency false positives, a single interception can waste seconds, significantly reducing daily handled sessions.
  • Extended user wait time: During peak hours, false positives can delay critical information delivery, causing users to leave due to long waits.

Therefore, precisely optimizing risk control rules is not optional but a must to improve customer service efficiency.

Step 1: Precisely Split Sensitive Word Groups — From “One-Size-Fits-All” to “Fine-Grained”

Most false positives arise from configuring long phrases or vague words as single entries. For example, setting “receiving address” as a single risk word will intercept any message containing that exact phrase. The correct approach is: split word groups and manage them independently by business scenario.

Principles of Word Group Splitting: Length, Uniqueness, and Business Relevance

  • Length principle: Avoid using overly short entries (like “TX” or “USDT”), which cause many false positives. Suggest entry length ≥ 4 characters, or use complete address fragments (≥ 8 characters).
  • Uniqueness principle: Separate high-frequency business words from high-risk words. For instance, split “receiving” and “address” into two independent entries, each associated with different risk levels.
  • Business relevance principle: Enable entries only for specific business scenarios. For example, enable “receiving” only in the “payment-related” project group, but disable it in the “technical support” project.

Practical Operation: Using TG-Staff Pro Risk Control Rules as an Example

In TG-Staff Pro’s content risk control backend, you can configure word groups as follows:

  1. Enter risk word group management: In the console, go to “Content Risk Control → Risk Word Groups” and click “New Group.”
  2. Enter entries: For example, input “TRC20 address fragment: TXYZ12345678” (complete or at least 8 unique characters).
  3. Associate projects: Select to enable only for the “Payment and Transfer” project, avoiding impact on daily conversations in other bots.
  4. Set risk level: Choose “High” or “Medium” to decide whether a popup confirmation is required when intercepted.

In this way, you can treat wallet address keywords (such as TRC20/ERC20/BTC address fragments) as independent word groups, avoiding false positives on normal inquiries like “Please confirm your wallet address.”

Caution: Risk of False Positives for Wallet Address Keywords

When configuring TRC20/ERC20/BTC address fragments, avoid using overly short fragments (such as “TX”), as they may match a large number of normal messages. It is recommended to use full addresses or unique fragments of at least 8 characters, and combine them with whitelist contexts (e.g., enable only for specific projects).

Step 2: Configuring Whitelist Contexts—Let Normal Business Conversations Pass Unhindered

Whitelist contexts are the “exemption channel” that reduces false positives. They allow you to bypass risk control rules under specific conditions, such as allowing normal messages for particular projects, agents, or user tags. The core logic is: Rules do not block normal business; they only intercept real risks.

In TG-Staff Pro, whitelist contexts are configured at the risk phrase level. The specific operations are as follows:

  • Exempt by project: Disable all risk phrases for the “Internal Testing” project, enabling them only in the “External Customer Service” project.
  • Exempt by agent: Set up whitelists for senior agents (e.g., team leads) to allow them to send business instructions containing risk words.
  • Exempt by user tag: Enable exemptions for VIP users or verified users to avoid blocking high-value customer inquiries.

For example, when an agent sends “Please provide your payment address,” if the message comes from a conversation tagged as “Verified User” and the project’s whitelist is enabled, the message will not be blocked.

Step 3: Using Audit Logs to Identify the Root Cause of False Positives

Even with the most detailed rule configuration, false positives can still occur. In such cases, audit logs are the most powerful tool for pinpointing issues. TG-Staff Pro’s audit logs record detailed information about each trigger, helping you quickly determine whether it is a false positive.

Understanding Audit Log Fields

In the console under “Content Risk Control → Audit Logs,” you can see the following key fields:

FieldDescriptionUsed to Determine False Positive
Risk WordThe specific word that was hit (e.g., “payment”)If the word is used as normal business terminology in context, it is a false positive
Trigger TimeTimestamp when the message was blockedCombined with conversation time to determine if it is peak hours
AgentThe agent account that sent the messageIf the agent frequently sends normal business messages, false positive is more likely
Conversation IDThe conversation number the message belongs toClick to view full context and confirm surrounding dialogue

Review Process: From Logs to Rule Adjustments

Here is a standard review procedure:

  1. Detect a false positive: An agent reports a blocked message, or audit logs show unusually frequent triggers.
  2. View logs: Go to audit logs, filter by target conversation or risk word, and click “View Context.”
  3. Analyze context: Read the full conversation before and after the trigger message to determine if it is a normal business inquiry (e.g., “What is your payment address?”) or a solicitation (e.g., “Send money to this address”).
  4. Adjust rules: If it is a false positive, perform one of the following:
    • Split the phrase (e.g., split “payment address” into separate words).
    • Add a whitelist (e.g., exempt the project or agent).
    • Delete or downgrade the risk level of the phrase.
  5. Verify: Send a similar message using a test bot to confirm the rule takes effect.

Step 4: Gradual Optimization—An Iterative Strategy from Loose to Precise

To avoid a large number of false positives from overly strict initial configurations, it is recommended to adopt a “gradual optimization” strategy:

  • Phase 1 (Loose): Only block high-confidence risk words (e.g., full wallet addresses, scam phrases), and temporarily disable common business terms (e.g., “payment,” “address”).
  • Phase 2 (Observe): Run for 1–2 weeks, collect trigger records from audit logs, and mark phrases with frequent false positives.
  • Phase 3 (Tighten): Based on log feedback, gradually add medium-risk phrases and configure whitelist contexts.
  • Phase 4 (Iterate): Regularly (e.g., monthly) review rules, removing outdated or high-false-positive phrases.

This strategy effectively balances risk control intensity and customer service efficiency, avoiding business disruptions from a one-size-fits-all approach.

Preventing Future False Positives: Rule Maintenance and Team Training

Optimization is not a one-time task but an ongoing process. Here are key measures to prevent future false positives:

  • Regular rule audits: Check the risk phrase library monthly, removing phrases no longer used in business (e.g., old payment addresses).
  • Update phrase libraries: Add new phrases promptly based on new business scenarios (e.g., new token types) and test false positive rates.
  • Team training: Educate customer service agents about risk control rules (e.g., “which words may trigger blocks”) and inform them of the process for handling false positives (e.g., clicking “Continue to Send” or contacting an administrator). Training can reduce repeated blocks caused by agent errors.

Tip: How to Distinguish 'False Positive' from 'Real Interception'

When an agent’s message is blocked, a popup will display the triggered risk word. If the word is a normal term in business conversations (e.g., “wallet address” in “Please confirm your wallet address”), it is a false positive; if it is malicious or deceptive content (e.g., “Send money to this address”), it is a correct interception. Use TG-Staff Pro’s audit logs to quickly review the context.

FAQ

Q: If a sensitive word is incorrectly flagged, can an already sent message be recalled?
A: TG-Staff Pro’s content moderation intercepts messages before they are sent by agents, so false positives do not result in messages being sent. If an agent confirms it’s a false positive, they can click “Continue to Send” or “Cancel” in the popup without needing to recall afterward. If a message has already been sent (e.g., due to outdated rules), remote recall via TG-Staff is not currently supported; deletion must be done manually in the Telegram client.

Q: How can I determine if a flagged word is a false positive or a real risk?
A: We recommend assessing based on the full conversation context in the audit log. If the word appears in normal business inquiries (e.g., “What is your payment address?”), it’s likely a false positive. If it appears in contexts inducing transfers or scams (e.g., “Send money to this address immediately”), it’s a real risk. TG-Staff Pro’s audit log records messages before and after the trigger for easy review.

Q: Can whitelist contexts be configured per agent or project?
A: Yes. TG-Staff Pro’s content moderation supports associating risk phrases per project, allowing different whitelist rules for different projects. For example, enable lenient rules for customer service projects (blocking only high-risk words) and strict rules for internal test projects. Whitelist contexts are currently configured at the risk phrase level; it’s recommended to set up exempt phrases separately.

Q: After splitting phrases, how can I test if new rules are effective?
A: After adjusting rules, send test messages containing the new phrases via a test bot or simulated conversation to see if they are correctly blocked or allowed. TG-Staff Pro’s console supports real-time trigger logs; you can check the audit log immediately after sending test messages to confirm rule effectiveness.

Act Now: Experience Accurate Moderation

Optimizing Telegram Bot content moderation false positives is not achieved overnight, but through phrase splitting, whitelist configuration, and audit review, you can significantly reduce false positive rates and improve agent efficiency. TG-Staff Pro’s content moderation features are designed for B2B teams, supporting flexible rule configuration and audit logs.

  • Free Trial: Register for a 3-day trial to experience Pro version content moderation auditing and tuning. Visit https://app.tg-staff.com/ to start.
  • Read Docs: For detailed configuration guides, see TG-Staff Documentation.
  • Contact Support: Reach out to our support bot @tgstaff_robot for Pro plan inquiries or false positive optimization advice.