> For the complete documentation index, see [llms.txt](https://sdk-doc.tyrads.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://sdk-doc.tyrads.com/getting-started/tyrads-fraud-suite-v2-sdk.md).

# TyrAds Fraud Suite V2 (SDK)

Fraud Suite v2 Documentation:

{% file src="/files/Dp9eWj3Hh8aD6CGGlwdc" %}

#### 1. The Two-Layer Defense

* Layer 1: User Risk Scoring (Proactive): An automated system that scores every user at the moment they enter the SDK. Using 200+ data sources (including device fingerprints, location, and multi-accounting patterns), it blocks "High Risk" users before they can engage with any offers.
* Layer 2: Anomaly Detection (Reactive): A machine-learning system that monitors in-game activity. If a user bypasses Layer 1 but exhibits abnormal behavior patterns, their progress is rejected in real-time.

#### 2. For Anomaly Detection Layer

Our system analyzes post-install event patterns. If a user’s behavior is flagged as non-human or anomalous, the system triggers an automatic rejection.

Standardized Lookback Rules:

* **14-Day Window**: All conversions are subject to a 14-day lookback window, aligning with industry MMP standards.
* **CPI Model**: If an anomaly is detected within 14 days, both the install and all associated events are retroactively rejected.
* **CPE Model:** The specific anomalous event is rejected, and the user is flagged to prevent all future payouts on that campaign.
* **Post-14 Days**: The initial install remains approved, but specific anomalous events are rejected and non-payable.

#### 2. Technical Integration (Postback Macros)

If you needed to be notified on the rejections to your platform, please do consult Tyrads team to setup a rejected type Postback URL  \[**especially for CPI campaigns where we retroactively reject the install together with the event and make the install non-payable as well]**

The following are the important macros for rejected type postback:

| Macros                | Description                             | Example or Expected Value |
| --------------------- | --------------------------------------- | ------------------------- |
| `{conversion_status}` | The state of conversion                 | `rejected`                |
| `{reject_reason}`     | The rejection reason for the conversion | `Anomoly%20Detection`     |
| `{conversion_id}`     | Unique ID of a specific conversion      | `2563391781`              |

Example of suggested rejected postback URL:

{% tabs %}
{% tab title="Rejected Postback Format Example" %}
[https://your-api-endpoint.com/postback?id={conversion\_id}\&conversion\_status={conversion\_status}\&reject\_reason={reject\_reason}](https://your-api-endpoint.com/postback?id={conversion_id}\&status={conversion_status}\&reason={reject_reason}) + all existing macros setup in Ad Unit that is required
{% endtab %}
{% endtabs %}

***

Rejected postback Integration Checklist

* [ ] Ingest rejected type postback in your system if needed
* [ ] Map rejections using `conversion_id` 

{% hint style="warning" %}
Please do not reward the user upon receiving the rejected type postback if implementation of rejected postback is required.
{% endhint %}