Edited edition / Comprehensive Anti-Bot and Anti-RMT System for Path of Exile 2 /

1. Brief Problem Summary (Why This Matters)

The mass use of bots and multi-accounting (multi-boxing) allows farming factories to generate vast amounts of in-game currency and rare items, which are then sold on RMT (Real Money Trade) platforms. This leads to rapid market crashes and fluctuations, undermining the core in-game economy.
There are commercial bots and entire "bot farms", as well as external marketplaces ready to buy/sell currency and items for real money. This channel motivates large-scale automated resource production.

Conclusion: The solution must be comprehensive: real-time bot detection and blocking + limiting monetization channels (limiting transactions, markets, etc.) + manual moderation processes and measures to reduce the profitability of RMT.

2. How Bots and Intermediaries Operate — Tactics (Specific)

Based on public materials and discussions, the main tactics can be summarized as:

Mass Farming via Multi-accounts / Multi-boxing

Typically, one physical machine/operator runs dozens of bots/clients, controlled by scripts or specialized bots. This enables 24/7, scalable farming.

Automated Routes and Exploits

Bots use pre-set routes, exploiting predictable spawns, artifacts, or mechanics (clearing specific maps/zones with high yield). Some publicly describe bot settings and zones in guides.

Use of Commercial Bots/Software

The market has ready-made solutions and equivalents for sale and support; this lowers the entry barrier for RMT organizers.

Conversion of Currency into Real Money via External Platforms

Once resources are accumulated, they are transferred to intermediaries/sellers and listed for sale on platforms or specialized RMT sites.

Behavioral Camouflage

Bots can imitate human-like delays, periodic pauses, account switching, click falsification, etc., to avoid detection by simple anti-bot systems.

Conclusion: Effective suppression requires methods that don’t rely on simple signatures — behavioral/graph analytics and multi-layered heuristics are necessary.

3. Data to Collect (Telemetry)

To detect and investigate, the following should be gathered and stored (minimum set):
Transaction Logs (in-game trades, prices, volumes, timestamps).
Sessions/Activity: logins/logouts, coordinates during farming, actions (attack/movement/interaction) with timestamping.
Trade Graphs: who sells/buys from whom, frequency of repeat transactions between accounts.
IP, Device Fingerprint (devices/aggregated data), proxy/AS info.
Premium stash tab purchases, mass email/phone number bindings.
Player reports and manual verification results (labels for training).

Storage Requirements: Time series and metadata in storage, fast access to "last X hours" (real-time), and long-term archives for investigations (6–12 months, considering GDPR/privacy rules).

4. Signatures and Features for the Detector

I’ll divide them into "simple heuristics" and "ML/graph-based" features.

Simple Heuristics (fast, low FP cost)
Number of accounts registered from one IP/device over N days.
Login/logout frequency with identical time patterns (e.g., 24/7 without deviations).
High action speed (actions every 100–200 ms from multiple sources).
Repeated trades between the same account pairs (trade loops).
Obvious "farming paths" — accounts spending 90% of their time in the same zone, repeating the same routes.

Behavioral/Statistical Features
Variability in time between clicks/actions (human vs. deterministic bot).
Sales distribution: significantly differing from market volume/price (e.g., selling items at prices far below/above the median for the item).
"Create-sell" ratio — how many items/currency have been posted/sold per account over X days.
Synchronous metrics: multiple accounts performing similar actions simultaneously (indicator of multi-boxing/bot stack).

Graph-based Features (for botnet detection)
Community detection / clustering in the trade graph (identifying groups of accounts that trade intensively with each other).
Centrality measures — nodes (accounts) with unusually high degrees of connections/reselling.
Temporal motif detection — recurring patterns of item/currency transfer (e.g., A→B→C periodically).

5. Detection Model — Architecture and Algorithms

I propose a layered system: “real-time + analytics”.

5.1. Stream Processing (Real-Time)
Tools: Apache Kafka (ingest), Apache Flink or Apache Spark Streaming for real-time feature calculation. (Kafka + Flink — low latency).
Fast heuristics are run in the stream (rate limits, IP counts, trade sweeps). Once a threshold is exceeded, the account is marked as “needs review” or temporarily restricted.

5.2. Feature Store
Feature store (e.g., Feast or custom) for aggregated signals; supports online/offline features.
Fast access via Redis/ElastiCache for real-time scoring.

5.3. Anomaly Detection (ML)
Unsupervised: Isolation Forest / Local Outlier Factor / Autoencoder (sequence-based) for anomaly detection without labeled data. Especially useful in early stages.
Temporal models: LSTM-autoencoder or Transformer-based sequence encoder for modeling action sequences and detecting deviations.
Graph ML: Node2Vec / GraphSAGE / GNN + community detection for detecting botnets and intermediaries in trade graphs.
Supervised: Once labels are collected (ban/no-ban after investigation), train classification models (XGBoost/LightGBM/NN).

5.4. Scores, Explainability, and Thresholds
Each account receives a set of scores: heuristic risk (0-100), ML anomaly (0-100), graph risk (0-100).
Combined risk = weighted sum; thresholds for automatic actions:
90 → automatic block/soft block (e.g., trade restrictions).
60–90 → "soft actions": trade cooldown, CAPTCHA, verification.
30–60 → mark for manual review.
Important: Implement explainability (shap, LIME) for analysts to understand why an account is at risk → reduces FP during appeals.

6. Infrastructure Components (Stack)

Ingest/streaming: Kafka (events), Flink/Spark Streaming (processing).
Storage: PostgreSQL (metadata), ClickHouse / BigQuery (event analytics), Elasticsearch (quick incident search).
Feature Store: Feast or custom (Postgres + Redis).
ML Infrastructure: MLflow (pipeline & models), TensorFlow/PyTorch/LightGBM.
Graph Processing: Neo4j or for large-scale GraphFrames/GraphX or TigerGraph.
Alerting/SIEM: Grafana, Prometheus, Sentry + integration with ticketing system (Jira).
Investigation UI: internal web interface (analyst sees timeline, route replay, network graph, action buttons).
Rate limits/enforcement: edge services (API gateways, game servers) integrated with Redis for fast quotas and blocks.

7. Tactical (Operational) Measures — Short & Medium Term

7.1. Immediate / Low-Cost Actions
Introduce transaction limits: max N large transactions/ currency transfers per day, progressive limits for new accounts.
Require verification (email + SMS) for accounts involved in trading, with threshold requirements on trade volume until confirmed.
Start honeypots: deploy "lures"/unique markers in items to track chains and identify RMT intermediaries.
Limit number of accounts per IP/device fingerprint (with exceptions for families/houses — soft exceptions via KYC).

7.2. Medium-Term Actions
Rollout anomaly detector (see section 5), initially in "alert-only" mode, then gradually enable automatic sanctions.
Shadow-ban trade listings from suspicious accounts (visible only to the seller/their network).
Implement temporary "cooldown" for listing unique/rare items (e.g., items created/received within X hours of account registration cannot be sold for Y days).

7.3. Long-Term Actions / Structural Changes
Revise trade system: implement internal restrictions/market cooldowns, dynamic price ranges, and confirmation for trades above a threshold.
Build an official internal marketplace (with transparent price histories and fiat price control mechanisms) — reduces the incentive for using external platforms.
Develop and publish a transparent punishment policy + appeals process.

8. Escalation Policy

Tier 0 (automatic soft actions): CAPTCHA, trade limits, email/phone verification requirements.
Tier 1 (restrictions): Trade ban (no selling/transfer), premium purchase ban, loot freezing.
Tier 2 (full block): Temporary bans (7/30 days), then permanent if recurrence occurs.
Forensics & legal: When commercial RMT signs are present (working with payment services, gathering evidence) — block + provide data to law enforcement/payment systems upon request (in accordance with legal procedures).

Appeals: Mandatory appeals process; analysts must return logs of reasons and action playlists that led to the ban.

Part ||

Infinito, [16.10.2025 11:59]
English version

VII. Market Manipulation Analysis and Economic Stabilization
1. Price manipulation schemes

One of the key forms of hidden RMT and manipulation is artificially inflating or deflating prices via chains of trades between linked accounts. This creates the illusion of a “new market level,” which allows actors to:
increase the value of rare items for later sale on external marketplaces;
crash competitors’ prices;
legitimize bot-mined resources through fictitious trades.

Example scheme: “Price Loop”
1. Several linked accounts form a chain of transactions: item A is bought and then sold back at progressively higher prices.
2. market-perception systems detect the “price increase,” and automated trading bots adjust to it.
3. As a result, the item’s price is artificially raised and then sold to a real player at an inflated cost.
4. Profits are distributed among scheme participants, and the excess is cashed out via RMT.

Detection points:
cyclic trades between the same accounts;
unusual time intervals between purchase and resale;
synchronization by IP/device;
abnormal divergence of market price from the median in a short period.

⸻
2. Countermeasures

To stabilize the market, implement a system of dynamic price control and trade-pattern analytics.

A. Price dynamics control
Automatic monitoring of median prices across all item categories.
If a price deviates > X% from the median within a short window, the transaction is flagged as suspicious.
If repeated anomalies occur between the same accounts, the link is recorded in the suspicion graph.

B. Contextual trade verification
Evaluate trade context: time, source, frequency, participants’ history.
Compute a “market honesty” coefficient — a score that lowers trust rating for manipulators.

C. Dampening mechanism (economic “anti-spike”)
If an item’s price rises or falls abnormally fast, the system applies a smooth restriction on range changes — stabilizing the market without manual intervention.

⸻
3. Scalpers’ behavior and profiles

Scalpers often operate in a “gray zone”: formally legal trades aimed at continuous profit extraction. They:
monitor new leagues and demand spikes;
buy rare items immediately after content releases;
create artificial scarcity and then resell at higher prices.

Detection of such accounts can be done via:
margin analysis (difference between buy and sell prices);
tracking the number of resold items over a period;
graph correlation with accounts generating excess resources.

⸻
4. Self-regulation strategy for the economy

Instead of blanket bans, implement architectural self-balancing levers:
Dynamic transaction tax that increases under suspicion of anomalous activity (similar to fintech risk systems).
Market transparency coefficient that displays a product’s and trader’s “reputation” to players.
Economic cooling algorithm — automatic throttling of suspicious accounts (slower responses, rate limits on trades).

⸻
5. Objective

Create a game economy resilient to manipulation. Bots and speculators should be able to exist only until they disturb system equilibrium — after which the system itself “pushes” them out of the economic loop.

The economy should not punish offenders as a primary tool, but should make exploitation unprofitable.

⸻

VIII. External Currency Purchase Scheme and Its Analysis (example with “divine / divans”)
1. Scheme description (user example)

The scheme looks like this:
1. On an external marketplace (e.g., in China), a large amount of currency/items is purchased (in the example — “divans,” a colloquial stand-in for divine). The price there is lower (e.g., ~5–6 rubles per unit in local equivalent).
2. Resources concentrate at the external seller, then through the external platform a transfer is arranged to a middleman in the target country (in the example — a Russian middleman).
3.


The middleman receives the “divine spheres” on an in-game account; then they create the appearance of market demand: listing items or unique lots on the internal platform at inflated prices (or asking the buyer to list a “nice/unique” item which the middleman then purchases).
4. The in-game assets are sold to a real buyer, money flows through external channels, and profit is distributed among scheme participants.

The scheme’s key objective is to convert in-game resources into real currency while capturing a premium for “legitimization” and inflated visible value.

⸻
2. Vulnerability points and scheme indicators

Behavioral / graph signals:
Fast “list → buy” cycles between the same or linked accounts.
Lots with identical/similar stats (or hidden markers) appear and disappear following a pattern.
Middleman accounts receive inbound transfers from many disparate accounts, then suddenly list large volumes.
Repeated cycles of listing and buying the same item or items with very similar parameters.
Time correlation with external activities (inflows on the external marketplace / social mentions).
IP/device correlation between external sellers (via proxies) and internal middlemen — or matching payment patterns on the external platform.

Economic indicators:
Artificial price increases in a specific item class (e.g., XL2) without real demand change.
Illogical margins when comparing internal median prices with external listings.
• Repeated short-term sales volume spikes on the local marketplace.

⸻
3. Technical and product countermeasures

A. Monitoring and detection
Implement an “anti-cycling” rule: flag and block repeated trades where the same item/type returns to the market within a short window between the same or linked accounts.
Detect buyer-seller pairs: a high list→buy ratio for accounts — raise an alert.
Correlate internal trades with parsed public ads on external marketplaces (keywords, unique descriptions).
Track synchronicity of listings and buys: if account A lists a lot and account B (linked in the graph) systematically buys similar lots — increase risk score.
Use marker honeypot items (invisible tags) and track their appearance on external sites and suspicious accounts.

B. Product limits and economic levers
Introduce a “cooling period” for items after listing — limit the ability to relist/buy the same item in short intervals.
Limit the number of buybacks/returns of the same item between the same accounts within X minutes/hours.
Dynamic commissions/taxes: raise fees on trades where participant behavior indicates possible legalization chains.
Require verification (KYC) for accounts participating in large trade volumes or frequently acting as sellers/buyers of large lots.
New-account restrictions: caps on large listings/buys within N days.
Expose seller reputation metrics on the marketplace (honesty rating, history of returns/fast sales).

C. Policies and automated responses
Auto-block/quasi-block trading activity for a cluster when strong scheme indicators are detected (manual review required before final sanctions).
Generate detailed tickets with connection graphs and temporal patterns for analyst review.
Deploy user alerts (e.g., “items with anomalous prices — proceed with caution”).

⸻
4. Recommendations for presenting to developers (how to package the report)

Attach cases: a concrete example (500 divans), with prices, time windows, and typical scheme steps.
Provide a draft detection algorithm: list of indicators (see above) + priorities (which signals are critical).
Describe economic impact: expected attacker margins, league price effects, and honest-player experience degradation.
Propose microfinancial measures: temporary fees, cooling periods, limits — and demonstrate how they technically reduce scheme profitability.
Include effectiveness metrics for testing: reduction in suspicious sale volume, reduced median volatility in class XL2, number of honeypot triggers.

⸻
5. Metrics and success criteria

Infinito, [16.10.2025 11:59]
Reduce share of suspicious cyclic trades by X% within Y weeks after deployment.
Reduce price dispersion in target item classes (e.g., XL2) to a predefined threshold.
Number of detected items legalized through external platforms (honeypot) — approach zero.
Number of manual reviews confirming fraud — decreasing trend over time.

⸻
6. Final objective

Ensure any economic scheme aimed at cashing out game resources via external platforms (including the “divan/divine” example) ceases to be profitable. The goal is not mass bans but architectural economic barriers — limits, fees, delays, and reputational transparency — that automatically neutralize attackers’ profit.