> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.nvidia.com/sdgm/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.nvidia.com/sdgm/_mcp/server.

# Chargeback Fraud Detection

Chargeback fraud happens when a customer disputes a completed purchase with their bank and the merchant absorbs the reversed payment. This example makes two kinds of prediction: it scores an existing chargeback for how likely it is to be fraudulent, and it looks ahead from an order to flag the orders most likely to draw a chargeback in the coming weeks. Kumo Engine learns both from each chargeback or order's own details and from the account and order history connected to it in the graph.

## Data and relationships

The example assumes a prepared Kumo Engine `graph`, a matching `snapshot`, and these tables:

| Table         | Required columns                                                  | Purpose                                                                                                                      |
| ------------- | ----------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- |
| `chargebacks` | `chargeback_id`, `order_id`, `chargeback_date`, `label`           | The chargeback claims. `label` records how a resolved claim turned out, where `1` means fraudulent and `0` means legitimate. |
| `orders`      | `order_id` as the primary key, plus `account_id` and `order_date` | The order each chargeback disputes, and the entity the forward-looking queries score.                                        |
| `accounts`    | `account_id` as the primary key                                   | The account each order belongs to, for account-level context.                                                                |

Connect `chargebacks.order_id` to `orders.order_id` and `orders.account_id` to `accounts.account_id`. Mark `chargeback_date` as the time column of the chargebacks table and `chargeback_id` as its primary key, and mark `order_date` as the time column of the orders table. These time columns place every row in time, so each prediction is trained and scored using only information recorded before the point it looks ahead from. `label` is the value the scoring query predicts, so it is the label rather than a feature; there is no direct foreign key from `chargebacks` to `accounts`, so the forward-looking queries below run over orders.

## Score each chargeback for fraud

This query scores each chargeback for whether it is fraudulent. The target `chargebacks.label = 1` turns the recorded outcome into a yes or no label, and `FOR EACH chargebacks.chargeback_id` produces one prediction per chargeback. Because the chargebacks table is anchored at `chargeback_date`, the model learns from the account and order history that exists when the claim is filed. Predict the comparison `label = 1` rather than the raw `label` column, which Kumo Engine reads as a numeric target and scores as a regression.

```python
from kumo.engine import PredictiveQuery

query_text = (
    "PREDICT chargebacks.label = 1 "
    "FOR EACH chargebacks.chargeback_id"
)
query = PredictiveQuery(graph, query_text)
query.validate()
print(query.get_task_type())  # binary_classification
```

## Predict future chargeback fraud for an order

Scoring a claim only helps once it has been filed. To act earlier, this query looks ahead for each order and predicts whether it will draw a fraudulent chargeback in the next 30 days. `SUM(chargebacks.label, 0, 30, days)` adds up the fraud labels of the chargebacks linked to the order over the 30 days that follow the scoring time, and `> 0` turns that into a yes or no label. Because legitimate chargebacks carry a label of `0`, only a fraudulent one moves the sum above zero, so this flags future fraud specifically rather than any dispute.

```python
query_text = (
    "PREDICT SUM(chargebacks.label, 0, 30, days) > 0 "
    "FOR EACH orders.order_id"
)
query = PredictiveQuery(graph, query_text)
query.validate()
print(query.get_task_type())  # binary_classification
```

## Predict future dispute risk for an order

Some teams want to see every dispute coming, not only the fraudulent ones, so they can staff support and hold higher-risk orders for review. This query predicts whether an order will draw any chargeback in the next 30 days. `COUNT(chargebacks.*, 0, 30, days)` counts every chargeback linked to the order over the same 30-day window regardless of its label, and `> 0` turns that into a yes or no label.

```python
query_text = (
    "PREDICT COUNT(chargebacks.*, 0, 30, days) > 0 "
    "FOR EACH orders.order_id"
)
query = PredictiveQuery(graph, query_text)
query.validate()
print(query.get_task_type())  # binary_classification
```

## Reading the predictions

The scoring query returns a probability that a filed chargeback is fraudulent, which lets a fraud team rank open claims and put the riskiest ones first. The two forward-looking queries return a probability that an order will draw a fraudulent chargeback, or any chargeback, within the next 30 days, which supports acting before a claim exists, such as holding a high-risk order for verification or routing it to manual review.

All three are estimates from past behavior, not guarantees. The chargeback score is anchored at the moment each claim is filed, and the two forward-looking queries are anchored at the time you run them, so in every case the model uses only information recorded before that anchor and never sees the outcome it predicts. The 30-day window on the forward-looking queries is a starting point; widen or narrow the number of days to match how far ahead your team needs to act. Refresh the predictions as new orders and chargebacks arrive so each decision reflects the latest history.