The CORGI Risk Model
Per-merchant fraud intelligence, calibrated for agentic traffic.
CORGI is a per-merchant LightGBM ensemble that sits between payment-method collection and PaymentIntent confirmation. It scores every transaction in under two seconds and feeds p_dispute directly into the on-chain LRC reserve formula — turning a fraud model into capital efficiency.
A dedicated model per connected merchant. No cross-account weight sharing — your traffic shapes your decision boundary.
Learns from patterns spanning ChatGPT, Copilot, Perplexity, Claude and direct API agents, so risk transfers when a new agent shows up.
Channel-conditional features capture per-agent behavior — velocity, scope adherence, cart composition — so scoring and acceptance are tuned to how each agent actually buys.
How the model works
Per-merchant by design. Incremental to your existing risk stack by construction.
Separate LightGBM model per connected account (corgi_features.{account_id}_*). No cross-merchant weight sharing. Cross-platform card-fingerprint dispute signals enter as read-only features only.
Trains exclusively on traffic already approved by your current fraud solution, so learned signal is by construction incremental. Upstream risk scores enter as input features; SHAP shows top predictors are merchant- and agent-specific behavioral aggregates, not the upstream score itself.
Card-fingerprint dispute velocity, spend-spike z-score vs. card's 180-day mean, all-time-max breach detection, email-level volume anomalies, agent identity signals (Kite Passport tier, SPT scope), merchant rolling dispute history.
Isotonic regression so p_dispute is a true probability. Merchant-configurable precision floor. Monthly recalibration on a 90-day outcome window. NaN-tolerant inference via LightGBM split routing — missing features degrade gracefully.
Where CORGI sits in the payment flow
One backend route change, three frontend lines. Zero changes to authorization or settlement.
- 1ConfirmationToken
Payment Element tokenizes the card client-side.
- 2Platform backend
Token routed to CORGI's pre-auth endpoint.
- 3CORGI scoring
LightGBM + rule engine. +100–500ms, <2s total.
- 4PaymentIntent confirm
Your existing risk stack evaluates here as normal.
- 5LRC commitment
On-chain reserve sized by p_dispute × amount.
If CORGI is unavailable, requests fall through to Stripe's normal confirm flow. No changes to your existing risk rules, webhook handlers, or settlement.
From p_dispute to on-chain reserve
The same score that prevents fraud sizes the LRC commitment.
Shadow mode — measure lift before you switch on
8–12 weeks of scoring-only deployment. Zero risk to live agent traffic.
Agentic transactions your existing risk stack would have blocked that CORGI scores as safe, weighted by realized revenue without dispute.
Disputes CORGI would have prevented among traffic already approved by your current solution.
At the selected operating threshold, with merchant-configurable precision floor.
Percentage of transaction volume the model would intervene on. Typically <1%.
Dispute savings minus margin lost on false declines, using a 3× dispute cost multiplier.
Estimated good agent transactions blocked — usually the largest dollar lever as agentic commerce comes online, since existing models weren't trained on it.
Sample sizes (two-proportion z-test, α=0.05, power=0.80): ~190K payments for 0.1pp dispute-rate delta · ~75K for 0.2pp FPR delta · ~215K for 0.1pp auth-rate delta. A platform at 60–80K txns/mo reaches significance in 8–12 weeks.
Data requirements & isolation
Read-only during shadow mode. Per-merchant models, full data isolation at the infrastructure level.
- • Agent transaction records (x402 / ACP / MPP events)
- • Kite Agent Passport tier, session ID, delegation scope
- • LRC commitment lifecycle (created, triggered, expired)
- • Dispute outcomes and LRC reason codes
- • Merchant reserve balance history
- • 6–12 mo card dispute history (seeds p_dispute prior)
- • Kite identity on-chain logs at settlement block
- • SPT scope constraints per session
- • Product / SKU metadata
- • Corgi Beacon behavioural session data
Each connected account gets dedicated BigQuery tables and a scoped training run. No cross-account weight sharing, no federated learning, no shared model. Platform-level aggregate signals are opt-in and read-only.
Where Corgi Clear adds the most value — and where it doesn't
False-decline recovery is usually the largest dollar lever, not fraud reduction.
- • False-decline recovery — recovers good agent revenue that existing fraud solutions, untrained on agentic traffic, incorrectly block. Generic models see agent velocity as fraud. We see it as signal.
- • Fraud & dispute reduction — incremental to whatever your current risk stack already catches, focused on the agent channels it doesn't model. LRC reason codes surface patterns card-era tooling was never designed to detect.
- • Per-merchant, per-agent features — rolling z-scores, all-time-max breaches, agent-channel dispute history, and Kite Agent Passport behaviour that generic network models can't compute. Per-merchant isolation means your model never leaks signal to competitors.
- • Reserve capital efficiency — replace a blunt 5–10% acquirer holdback with a model-driven reserve sized precisely to your dispute probability. Low-risk merchants typically free up 70%+ of tied capital within the first 90-day window.
- • Merchants with no agentic traffic yet — the reserve architecture and LRC primitive are only relevant once you're accepting agent-initiated purchases. If all your traffic is human-initiated, start with Corgi Labs' core fraud product instead.
- • Sub-$10k monthly volume — the $10k MIN_RESERVE floor represents a meaningful capital commitment relative to small transaction volumes. Not the right fit until volume justifies it.
- • Merchants requiring real-time card network signals — Corgi Clear operates on stablecoin settlement via Kite Chain. If your checkout is card-only with no stablecoin path, the LRC primitive doesn't apply.
- • Fully decentralised dispute resolution — we are explicitly a trusted arbiter model today. If your use case requires trustless, permissionless dispute resolution from day one, we're not there yet (see our decentralisation roadmap).