AI Prospectus Reveals 5%–7% of Revenue from Policy-Violating Customers

1. Introduction: A risk-control problem hidden in a prospectus

Imagine an AI company sprinting toward an IPO. In its prospectus is a line of numbers: for the first nine months of 2026, about 5%–7% of revenue came from customers who were later found to have violated usage policies or commercial terms. Revenue for the same period was approximately US$33 billion, which works out to roughly US$1.65 billion–US$2.31 billion. The company did not disclose how much of that revenue came from users in specific overseas markets.

Note: The data in this article are based on public reporting. The author has not verified the original prospectus. The references are used only to illustrate the problem and do not constitute investment advice.

Customers found to have violated policies usually end with account suspension or service termination, and repeat purchases are effectively impossible. Yet the revenue has already been recognized. This matters to engineering teams because it exposes a structural contradiction: revenue recognition can occur before a risk conclusion is reached.

A global AI service often faces four interacting forces:

• Commercial demands focused on growth and ARR (annual recurring revenue);
• Compliance constraints such as export controls, cross-border data rules, content classification, and minor protection;
• Security risks such as payment fraud, bulk registration, and abuse of free quota;
• User expectations for stable and predictable service.

When a company promotes localization, connects mainstream card-acquiring channels, and simultaneously bans users from regions not covered by service, the contradiction becomes visible in the most direct way.

This article does not discuss the fate of any specific company. Instead, it abstracts the issue into a reusable engineering problem: how a global AI platform can build explainable, auditable, and iterable technical governance across compliance, security, and revenue. The following sections cover geo compliance, account risk control, and revenue governance, followed by a minimal engineering blueprint.

2. Geo compliance: turning “whether we can serve” into executable rules

2.1 What compliance boundaries actually constrain

“A region is not covered by service” is usually the result of several overlapping constraints:

1. Market access and regulation: Different jurisdictions impose different requirements on generative AI services. Some require filing or safety assessment; some impose special rules on model sources or content responsibility; some impose data sovereignty requirements.
2. Export controls and technology availability: Cross-border access to high-performance computing power and certain model capabilities is affected by policy. Leading AI companies often strengthen controls on access from controlled regions, following the same regulatory logic as chip-level restrictions.
3. Payments and settlement: Whether acquirers, card networks, and clearing networks accept a merchant category directly determines whether users can pay. Some overseas payment tools also impose requirements on merchant registration locations.
4. Sanctions and list screening: Sanctioned individuals, entities, and their regions usually need to be included in blocking scope.
5. Content and minor protection: Requirements for content classification and age thresholds vary significantly across markets.

The most dangerous engineering mistake is compressing these constraints into a single boolean value: “a certain country = blocked.” Such a design neither records the source of the constraint nor adapts quickly to policy changes.

2.2 Layered judgment: a single signal is not enough

Geo judgment involves at least five layers:

Layer	Typical signals	Reliability and limitations
Network	Source IP, IP geolocation database, ASN ownership, data-center or proxy characteristics, IP type (residential, mobile, cloud host)	Real-time; can be distorted by proxies, corporate egress, and mobile network drift
Account	Declared country/region at registration, account age, email and phone number ownership	Relatively stable; self-reported and can be forged
Payment	Issuer BIN country, card network, billing address	Relatively credible; some regions allow binding foreign cards, creating mismatches
Session	IP changes across sessions, common login locations, time zone, device fingerprint	Can build long-term profiles; involves privacy and requires minimal collection
Content and behavior	Request language, business scenario features, invocation patterns	Helps infer use cases; language alone cannot be treated as geo evidence

The core principle is: any single signal is insufficient to assign responsibility. Multiple independent signals should corroborate each other. A practical approach is to maintain a risk score for each account, weighted by signal credibility and independence:

# Illustrative rule: multi-signal consistency score (values are examples only)
SIGNALS = {
    "session_ip_region_mismatch": 30,   # Session IP belongs to a restricted region
    "account_region_mismatch": 25,      # Declared account region differs from current access region
    "proxy_or_datacenter_ip": 15,       # Proxy or data-center IP characteristics
    "payment_country_mismatch": 20,     # Payment method country differs from declared region
    "controlled_use_signal": 60,        # Hit on a restricted-use feature
}
def score(session, account) -> tuple[int, list[str]]:
    hits, total = [], 0
    if session.ip_region in RESTRICTED_REGIONS:
        hits.append("session_ip_region_mismatch")
    if account.region in RESTRICTED_REGIONS:
        hits.append("account_region_mismatch")
    if session.is_proxy_or_datacenter:
        hits.append("proxy_or_datacenter_ip")
    if payment_country(session.last_payment) not in SUPPORTED_COUNTRIES:
        hits.append("payment_country_mismatch")
    if detector.hit_controlled_use(session):
        hits.append("controlled_use_signal")  # High-risk signal; can trigger on its own
    total = sum(SIGNALS[h] for h in hits)
    return min(total, 100), hits

At the policy layer, score ranges can be mapped as follows:

• High-risk signal hit alone: block immediately and log;
• 60–89: require secondary verification or manual review;
• 30–59: record the event, show a risk notice, and do not take action for now;
• Below 30: allow normally.

Three additional rules are useful:

• Cross-border exemption allowlist: Reasonable scenarios such as business travel or cross-national teams can be exempted after enterprise identity verification, avoiding “travel equals ban.”
• Layered use of IP databases: Results from self-built databases, commercial databases, and real-time detection should be labeled with source and confidence, and should have validity periods to prevent large-scale false bans caused by outdated data.
• Traceable decision basis: Each rule should be linked to a policy clause or internal specification number. When policy changes, only the rule needs to be adjusted, not the code.

2.3 Beware pseudo-signals: language, UI, and payment are not authorization

Public reports show that some AI products have added localized interfaces, local payment options, and billing-region selectors that do not match the officially supported service scope. From a product perspective, “able to pay” is often treated as “able to use,” which is exactly where the contradiction ignites. From an engineering perspective, this shows that observable signals have become disconnected from the real authorization state.

The fix is to introduce a single source of truth and explicitly model a capability matrix for each region:

# Illustrative policy configuration: region capabilities and restrictions
regions:
  unsupported_region:
    display_name: "Unsupported region"
    ui_language: supported        # Interface language is available
    payment: unsupported          # Payment channels are not covered
    signup: blocked               # Signup entry is closed
    billing_country_option: hidden  # Billing country is not displayed
    supported: false              # Whether the region is officially supported
    user_notice: "The current region is not within the supported service scope."
  supported_region:
    ui_language: supported
    payment: supported
    signup: allowed
    billing_country_option: visible
    supported: true

The same configuration should drive:

• Front-end language packs and interface copy;
• Signup entry and agreement display;
• Acquiring routes and payment method rendering;
• Billing address dropdown options;
• Risk-control rules and rejection messages.

If any side contains residual configuration from another region, it should be caught by configuration validation and integration tests, rather than being discovered only after a user has paid and used the service for a period of time.

3. Account risk control: from post-hoc bans to explainable, appealable decisions

3.1 The cost of false positives is often underestimated

In public reports, an overseas user who had been active for more than a year was banned. The system reason was “suspected to be under 18.” The user joked that this was “sudden death” rather than “dying of old age.” Behind the joke is a real risk-control design flaw.

The cost of a false ban is not limited to a support ticket. It spreads along several paths:

• Revenue loss: High-value users churn, and the loss is almost irreversible;
• Reputation and public opinion: In developer communities, account bans are one of the topics most likely to resonate;
• Support cost: Appeals and inquiries flood customer support and community channels;
• Trust damage: Payment conversion and compliance audit conclusions can both be affected.

The most common root cause of false positives is using weak evidence to support strong enforcement:

• If age judgment relies only on a birth date entered by the user, or on behavioral inference from chat content, its accuracy is inherently limited;
• If one rule can directly trigger permanent suspension, with no gradual rollout, no review, and no buffer, errors become costly.

3.2 Risk levels and enforcement ladder

A mature risk-control system should separate “risk level” from “enforcement action.” Enforcement intensity should match evidence strength:

Risk level	Evidence strength	Recommended action	Reversibility
L1 Observe	Single weak signal	Record and increase monitoring frequency	Does not require user awareness
L2 Notify	Multiple weak signals corroborate each other	Risk notice or request for additional verification	Fully reversible
L3 Restrict	Moderate evidence	Restrict some features (e.g., rate, concurrency, high-cost models)	Quickly restored after appeal
L4 Freeze	Stronger evidence or high-risk signal	Suspend the account and enter manual review	Restored or terminated after review
L5 Terminate	Confirmed by review or involves fraud	Terminate service and handle balance/data according to the agreement	Only formal appeal channel remains

Age-related judgments should follow a “verifiable evidence first” principle: prefer reliable sources such as identity verification or third-party age verification. When only behavioral inference is available, enforcement should stay at L3 at most, restricting access to restricted content rather than banning the account.

3.3 Decision logging and replayable audit

Every ban should generate a structured decision record, including at least:

• The matched rule ID and version;
• Raw values and weights of each signal;
• Model or threshold version;
• Enforcement level and execution time;
• Whether manual review occurred.

{
  "case_id": "ban-20261110-000137",
  "rule_version": "geo-policy@2026.11",
  "signals": [
    {"code": "session_ip_region_mismatch", "weight": 30, "evidence": "ip_asn=AS****", "confidence": 0.92},
    {"code": "payment_country_mismatch", "weight": 20, "evidence": "issuer_country=**", "confidence": 0.88}
  ],
  "score": 50,
  "action": "L3_restrict",
  "manual_review": false
}

Only when decisions are replayable can the system answer three questions: what evidence was used at the time, whether the rule version changed, and whether the case was corrected after an appeal. These data are also the only reliable basis for later rule optimization.

3.4 Bring appeals into the main path, not a support afterthought

Appeals should not be a peripheral customer-service process. They should be part of the risk-control loop:

• Clear notice: A ban notice should explain the reason category, such as “access region not covered by service” or “payment method does not match account region,” and provide an appeal entry. Not all rule details need to be disclosed, but the user should know what went wrong and what can be done.
• Time-bound review: Set an SLA, for example an initial conclusion within 48 hours.
• Fast restoration: When evidence is questionable, restore service first instead of making the user wait.
• False-positive feedback: Corrected cases should automatically flow back as negative samples for rule optimization.

4. Revenue governance: turning “violation revenue” into measurable metrics

4.1 Revenue cannot be viewed only by total amount

From a financial perspective, if 5%–7% of revenue at the US$33 billion level comes from violating customers, two signals are implied:

• If violations are mainly identified after revenue recognition, risk control is largely post-event;
• If many of these customers are long-term paying users, there is a large gap between the rules and the real boundaries of use.

The revenue side should therefore be broken down into at least four dimensions:

Dimension	Meaning	Management significance
Revenue share from violating customers	Share of revenue contributed by customers found to violate policies	Measures how far risk control is moved forward
Risk reserve and write-off	Provision for revenue that may be terminated or refunded	Reflects revenue quality
False-ban recovery rate	Share of users whose appeals succeed and who resume payment	Measures the cost of false positives
Restricted-region penetration	Share of traffic from restricted regions in total traffic	Indicates enforcement strength and mismatch between controls and demand

4.2 Build customer risk tiers

Not all violations are equally serious, so revenue management should be tiered accordingly:

• Category A: fraud and abuse (card fraud, stolen credentials, bulk-registration arbitrage): revenue should be written off, and the cases should be included in blocklist sharing;
• Category B: restricted region or use (from unsupported regions or restricted industries): handled according to agreement terms, while preserving room for appeal;
• Category C: minor terms violations (such as account sharing or excessive invocation frequency): mainly reminders and rate limiting, preserving customer value.

Different categories require different revenue-handling strategies and retention priorities. Treating all three the same either causes unnecessary customer loss through blanket bans or accumulates compliance risk through excessive leniency.

4.3 Use metrics to bring risk control and growth back to the same table

The conflict between risk control and growth is essentially a misalignment of incentives:

• Growth teams focus on activation, retention, and payment conversion;
• Risk-control teams focus on violation rate, fraud loss, and false-ban rate.

When both sides have their own metrics, the system can oscillate between “loosen acquisition first, ban in batches later.” The “violation customer revenue” mentioned earlier is exactly the financial manifestation of this oscillation.

The governance approach is to set a shared metric. For example, “compliance-adjusted net revenue,” meaning revenue after deducting high-risk revenue and risk reserves. When growth and risk control are accountable for the same metric, decisions naturally move upstream to acquisition: whether to invest in a market and whether to open entry for a payment method should be considered before investment.

5. Minimal engineering implementation

5.1 Policy as code: four gates using the same data source

Compliance rules should be consolidated from scattered if-else logic into versioned, testable policy configuration, enforced consistently at four key points:

1. Signup gate: Decide whether the signup entry is open based on regional policy;
2. Payment gate: Before acquiring routing, check whether the billing country matches the account region;
3. Session gate: Calculate a risk score when a session is established and decide whether to allow, challenge, or block;
4. Content gate: Identify and block restricted use cases in real time.

User request
   │
   ▼
Signup/login ──► Policy source (region × capability matrix) ──► Payment gateway (acquiring route, billing check)
   │                                              │
   ▼                                              ▼
Session access ──► Risk engine (multi-signal scoring: network/account/payment/behavior) ──► Action: allow / challenge / restrict / freeze
   │
   ▼
Content safety ──► Restricted-use detection ──► Block / alert ──► Decision log ──► Appeal and review ──► Rule iteration

5.2 New rules must run in shadow mode first

Any new or adjusted ban rule should first run in shadow mode for a period of time:

• Only record hit results; do not execute enforcement;
• Estimate expected hit volume, collateral damage, and potential revenue impact;
• After meeting the target, gradually roll out and set an emergency rollback switch.

This avoids public-relations incidents caused by “launch and mass-ban immediately.”

5.3 Full-link observability

At least the following monitoring items are recommended:

• Geo dimension: IP ownership distribution, proxy traffic share, ban rate, and appeal rate by source;
• Payment dimension: Payment success rate, billing-country mismatch rate, and chargeback rate;
• Risk-control dimension: Rule hit rate, false-ban rate, and average review time;
• Revenue dimension: High-risk revenue share and risk reserve coverage.

Each item should have threshold alerts. In particular, signals such as a sudden spike in ban rate in a region often indicate an outdated IP database or misconfigured rules.

5.4 Move compliance forward into product definition

The most economical compliance approach is to prevent users from entering mismatched paths from the beginning. Instead of banning after the fact:

• Show clear service-scope explanations on the signup page by region;
• Close the entry for unsupported regions instead of opening it and blocking later;
• Provide compliant alternatives for restricted scenarios, such as an enterprise compliance assessment channel, instead of simply refusing.

6. Conclusion: the cost of bans ultimately appears in revenue

Revenue from “violating customers” may look like proof of successful risk control, but it is actually a bill for delayed governance: the revenue has already occurred, the risk conclusion arrives late, user expectations are misaligned, and customer complaints and public opinion follow.

For AI services going global, what is truly worth investing in is not “banning harder,” but three things:

• More accurate decisions: Use multiple signals to corroborate and avoid assigning responsibility from a single point;
• More stable enforcement: Use risk tiers, shadow rollout, and fast appeals;
• Clearer accounting: Make violation revenue and risk reserves explicit so that growth and risk control are accountable for the same set of metrics.

Only when compliance no longer relies on after-the-fact bans to backstop the system will US$2.3 billion-level “ban revenue” become a number worth watching rather than celebrating.