Payback Abuse Detection Solution

Solution Background and Business Value

Payback abuse is a form of fraud commonly found in buy-now-pay-later (BNPL) platforms. It is closely related to credit card fraud and certain types of insurance fraud. The core challenge in detecting payback abuse is making real-time transaction-level decisions to prevent fraudulent activity before financial losses occur.

An effective machine learning model helps businesses:

• Reduce financial losses by blocking high-risk transactions before they go through.

• Improve fraud detection rates by analyzing transaction patterns.

• Minimize false positives to avoid blocking legitimate users.

A key business metric is $-amount weighted recall@K and precision@K, which ensures the model maximizes profit while minimizing fraudulent transactions.

Data Requirements and Schema

Building an effective fraud detection model requires a structured dataset that captures user transactions, payment history, and account details.

Core Tables

1. Transactions/Orders Table

   • Stores details about each transaction.

   • Key attributes:

     • order_id: Unique transaction identifier.

     • account_id: Links the transaction to a user account.

     • timestamp: Time of transaction.

     • Optional: Order value, merchant details, transaction type.

2. Payments Table

   • Tracks payments made for each transaction.

   • Key attributes:

     • payment_id: Unique payment identifier.

     • order_id: Links the payment to a specific order.

     • timestamp: Time of payment.

     • outstanding_amt: Remaining balance for the order.

     • Optional: Payment method, status.

3. Accounts Table

   • Stores user account details.

   • Key attributes:

     • account_id: Unique account identifier.

     • Optional: User demographics, credit history, risk score.

Additional Tables (Optional)

For improved fraud detection, consider including:

• Merchants Table: Static data about merchants (for example, reputation or fraud risk).

• Items Table: Information about products involved in transactions.

• Account 360 Table: Aggregated account data (for example, transaction history, credit checks, or previous fraud cases).

Entity Relationship Diagram (ERD)

Predictive Queries

The predictive query structure depends on how you define a fraudulent transaction. Two common approaches are:

1. Unpaid Orders After X Days

If a fraudulent order is defined as one that remains unpaid after X days, train a model to predict this behavior:

PREDICT LAST(payments.outstanding_amt, 0, X, days) != 0
FOR EACH orders.order_id

Requirements:

• The payments table must include an initial payment record for each order with outstanding_amt = order_value.

• This ensures that a negative label (not fraud) is generated for orders with no remaining balance.

2. Custom Fraud Labeling

If fraud is defined based on multiple signals (for example, previous fraud history or chargeback patterns), store precomputed fraud labels in the transactions table:

PREDICT orders.fraud_label == 1
FOR EACH orders.order_id

Here, fraud_label is a boolean column (1 = fraudulent, 0 = legitimate, None = pending prediction).

Deployment Strategy

1. Batch Fraud Detection for Inspection Teams

• Suitable for scenarios without strict real-time requirements.

• Predictions are generated in batches (for example, every hour or daily).

• Fraud analysts can review flagged transactions manually.

To filter transactions within a time window:

ENTITY FILTER: orders.TIMESTAMP > MIN_TIMESTAMP

2. Real-Time Fraud Detection Using Embeddings

For real-time fraud detection, Kumo embeddings can be combined with real-time transaction features to produce instant fraud scores.

1. Generate user and transaction embeddings in batches.

2. Store embeddings in a feature store for quick retrieval.

3. Combine embeddings with real-time transaction features to calculate a fraud risk score at the time of purchase.

Building models in Kumo Fine-Tune SDK

1. Initialize the Kumo Fine-Tune SDK

1
import kumoai as kumo
2
3
kumo.init(url="https://<customer_id>.kumoai.cloud/api", api_key=API_KEY)

2. Connect data

1
connector = kumo.S3Connector("s3://your-dataset-location/")

3. Select tables

1
accounts = kumo.Table.from_source_table(
2
    source_table=connector.table('accounts'),
3
    primary_key='account_id',
4
).infer_metadata()
5
6
orders = kumo.Table.from_source_table(
7
    source_table=connector.table('orders'),
8
    time_column='timestamp',
9
).infer_metadata()
10
11
payments = kumo.Table.from_source_table(
12
    source_table=connector.table('payments'),
13
    time_column='timestamp',
14
).infer_metadata()

4. Create graph schema

1
graph = kumo.Graph(
2
    tables={
3
        'accounts': accounts,
4
        'orders': orders,
5
        'payments': payments,
6
    },
7
    edges=[
8
        dict(src_table='orders', fkey='account_id', dst_table='accounts'),
9
        dict(src_table='payments', fkey='order_id', dst_table='orders'),
10
    ],
11
)
12
13
graph.validate(verbose=True)

5. Train the model

1
pquery = kumo.PredictiveQuery(
2
    graph=graph,
3
    query="PREDICT LAST(payments.outstanding_amt, 0, X, days) != 0 FOR EACH orders.order_id"
4
)
5
pquery.validate(verbose=True)
6
7
model_plan = pquery.suggest_model_plan()
8
trainer = kumo.Trainer(model_plan)
9
training_job = trainer.fit(
10
    graph=graph,
11
    train_table=pquery.generate_training_table(non_blocking=True),
12
    non_blocking=False,
13
)
14
print(f"Training metrics: {training_job.metrics()}")