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:

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.

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.

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.

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.