Fraud Scoring

The Challenge

Fraud scoring often lives in a latency-sensitive payment flow. Extra delay can affect conversion, while missed fraud signals can create chargebacks, fees, and loss of customer trust; measure both effects in the actual flow.

The requirements are competing:

• Fast — The scoring must fit the payment flow's measured end-to-end latency budget.
• Accurate — False positives block legitimate customers and generate support tickets. False negatives let fraud through and cost real money.
• Cheap — Every transaction needs scoring. At 100K+ transactions per day, per-call pricing matters.

Rules engines handle simple patterns (velocity checks, geo-blocking, amount thresholds) but miss sophisticated fraud — account takeovers using legitimate credentials, social engineering, and coordinated fraud rings.

A live model can add useful nuance, but its latency, token usage, and provider dependency must fit the payment flow. Measure the actual model and prompt rather than relying on a generic latency assumption.

How Sparkient Solves It

A compiled fraud scoring candidate targets an under-100ms compiled stage by combining structured signals (amount, velocity, device fingerprint) with text analysis (shipping address anomalies, message content in P2P payments). Its quality and full-path latency must be validated on the intended transaction distribution.

The Three Decisions

• approve — Low risk. Process the transaction immediately.
• review — Medium risk. Flag for manual review but don't block the transaction. Optionally hold funds pending review.
• block — High risk. Decline the transaction and trigger fraud investigation.

Multi-Signal Analysis

The compiled model evaluates:

• Transaction signals — Amount, currency, time of day, device fingerprint
• Behavioural signals — Purchase velocity, category deviation, shipping address changes
• Account signals — Account age, verification status, previous chargebacks
• Text signals — Shipping instructions, payment notes, gift messages (for P2P or marketplace platforms)

CEL rules enforce hard limits:

// Block transactions over the velocity limit
ctx.transactions_last_hour > 10 ? "block" : null

// Review first-time large transactions
ctx.account_age_days < 30 && ctx.amount > 500 ? "review" : null

// Auto-approve small transactions from verified accounts
ctx.verified && ctx.amount < 50 ? "approve" : null

The compiled classifier scores everything else — the transactions that aren't obviously safe or obviously fraudulent.

Code Example

import httpx

response = httpx.post(
    "https://api.sparkient.ai/api/v1/decide",
    headers={"Authorization": "Bearer YOUR_API_KEY"},
    json={
        "decision_type": "fraud-scoring",
        "input": {
            "amount": 299.99,
            "currency": "USD",
            "account_age_days": 12,
            "verified": False,
            "transactions_last_hour": 3,
            "shipping_country_matches_billing": False,
            "device_fingerprint_seen_before": True,
            "category": "electronics",
            "gift_message": "Happy birthday! Enjoy your new headphones."
        }
    }
)

result = response.json()
# {
#     "decision": "review",
#     "confidence": 0.84,
#     "latency_ms": 37,
#     "stage": "classifier"
# }

Payment Flow Integration

async def process_payment(transaction):
    # Measure the full request path before placing it in the payment flow.
    risk = await sparkient_decide("fraud-scoring", {
        "amount": transaction.amount,
        "currency": transaction.currency,
        "account_age_days": transaction.user.account_age_days,
        "verified": transaction.user.is_verified,
        "transactions_last_hour": await get_velocity(transaction.user),
        "shipping_country_matches_billing": transaction.addresses_match,
        "device_fingerprint_seen_before": transaction.device_known,
        "category": transaction.category
    })

    if risk["decision"] == "approve":
        return await charge_payment(transaction)
    elif risk["decision"] == "review":
        await charge_payment(transaction, hold=True)
        await queue_for_review(transaction, risk)
        return {"status": "pending_review"}
    else:  # block
        await log_blocked_transaction(transaction, risk)
        return {"status": "declined", "reason": "Transaction flagged for security review"}

Why Compiled Fraud Scoring

| Approach | Latency | In payment flow? | Nuance | |----------|---------|-------------------|--------| | Rules only | <1ms | ✅ | Low — misses subtle patterns | | Live model scoring | Model and prompt dependent | Measure first | Depends on model and policy | | Traditional ML | Model and infrastructure dependent | Often possible | Depends on data and design | | Compiled model (Sparkient) | Compiled stage targets <100ms | Candidate—measure end to end | Purpose-built for the defined outcomes |

You do not need a historical customer dataset to create a first candidate. Sparkient can generate synthetic starting examples, but synthetic coverage is not evidence that a scorer is safe or accurate in a real payment flow.

Upload historical examples when available, then evaluate false approvals, false blocks, calibration, distribution shift, and the cost of manual review on a representative held-out set. Fraud scoring is an application example, not one of Sparkient's four published validation domains.

Get Started

Define your risk thresholds and transaction schema, then train a compiled fraud scorer. Start with the free tier — 5,000 one-time credits, no credit card required.