Inspiration
Picture this: a customer in Berlin orders a phone case from a seller in Manila. Somewhere between the payment gateway and the warehouse, three things are happening in parallel — a payment is clearing, a shipment is being routed, and a fraud ring is trying to slip a stolen card through before anyone notices. The problem is, none of these systems are actually talking to each other. That's the pattern I kept noticing across e-commerce platforms: transaction engines and logistics networks run on separate, isolated databases, stitched together by slow, sequential batch jobs that take minutes or hours to flag anything. That delay isn't just an inconvenience — it's a window. Organized fraud groups can cash out before a flag is ever raised. Meanwhile, a shipment already caught in a customs delay or a storm has no system watching it and no backup plan, because nobody built one that runs fast enough to matter.
I wanted to build something that closes that window — not with another dashboard that tells a human to go check something, but with a system that actually acts.
What it does
It's an autonomous multi-agent system that watches transaction and logistics data simultaneously and takes action in real time, instead of flagging things for someone to review next Tuesday.
🕸️ Graph-based fraud ring detection — doesn't just score individual transactions, it builds a real graph of shared devices and payment identifiers to expose entire networks of connected fraud, not isolated blips. 🚚 Concurrent logistics risk scoring— evaluates shipment disruption risk (weather, customs, carrier reliability) at the same time the fraud agent is working, not after it. 🧠A Gemini-powered decision layer — takes both risk signals and actually chooses an action: freeze a payout, reroute a shipment, or escalate for human review. ⚡ A GPU-accelerated data layer — the same feature-engineering code runs up to 46x faster by swapping in NVIDIA's cudf.pandas, with zero rewrites. 📊A live risk stream — a running view of what's been flagged and what's been auto-resolved, so a human overseeing the system always knows what it just did and why.
How I built it
The architecture is deliberately layered so each piece can be reasoned about (and improved) independently:
Ingestion — transaction and logistics data land in BigQuery, structured for downstream querying. Feature engineering — cudf.pandas.install() is called before pandas is imported, so every downstream import pandas as pd call transparently runs on GPU when one is available, and falls back to standard CPU pandas when it isn't. Same code, either way. Specialist agents, running concurrently — a fraud-ring agent (graph connected-components over shared identifiers) and a logistics-risk agent run side-by-side via ThreadPoolExecutor, instead of one waiting on the other. Decision orchestration — the outputs from both agents feed into Gemini 2.5 Flash, which is given a small governance matrix and access to real tool functions (freeze_payout, reroute_shipment, flag_for_manual_review) so it can choose an action, not just describe one. Action + audit — whichever tool gets called actually executes (against mock endpoints for now), and every decision — along with why it was made — lands in an audit log a human can scroll through.
Challenges I ran into
Getting real acceleration, not a fake one. It's tempting to just hardcode a "before/after" number and call it a benchmark. We didn't want to do that — so we built in a live-measured timing for whatever's actually running in the current session, shown separately from a labeled reference benchmark, so nothing pretends to be simultaneous when it isn't. Graph detection got noisy at scale. When we scaled up to 500,000 simulated transactions, our ring-detection agent surfaced far more "rings" than we'd deliberately seeded. Turns out that's a birthday-paradox effect — with tens of thousands of shared device IDs floating around, some incidental overlaps happen by pure chance and get swept up as false "rings." That sent us down a real rabbit hole on ring-size and score thresholds to separate signal from statistical noise. Making the LLM decision layer resilient. APIs time out, models sometimes return free text instead of a clean tool call, and a fraud system that goes silent when that happens is worse than one that degrades gracefully. We built a rule-engine fallback that mirrors the same governance logic — so the system never leaves a transaction unresolved, even when Gemini doesn't cooperate. Being honest about "live" vs "simulated." BigQuery credentials aren't always available in every environment this runs in. Instead of quietly mocking it and hoping nobody noticed, we built explicit mode badges — the app tells you plainly whether it's running a live round-trip through BigQuery or a local simulation with an identical schema.
Accomplishments that I am proud of
Hitting a genuine 46x speedup on the feature-engineering pipeline with zero code rewrites — just one install call standing between "CPU-bound batch job" and "GPU-accelerated in real time." Getting fraud detection and logistics scoring to run concurrently, not sequentially, so the system reflects what real operations actually need: parallel judgment, not a queue. Building a decision layer that executes, not just recommends — freezing a payout or rerouting a shipment is a real function call with a real, logged outcome. Designing graceful degradation everywhere — GPU → CPU, cuGraph → networkx, Gemini tool call → rule engine — so the system stays useful even when a piece of infrastructure isn't available.
What I learned
The biggest lesson wasn't technical, it was philosophical: a demo that fakes its numbers is more fragile than one that's honestly smaller in scope. Every time we found ourselves tempted to hardcode a result to make a slide look cleaner, it turned out to be a shortcut we didn't need — the real pipeline, run honestly, was already interesting enough to stand on its own. We also learned that graph algorithms need real tuning at scale (thresholds matter, or noise drowns signal), and that resilience — what a system does when a component fails — deserves just as much design attention as what it does when everything works.
What's next for Multi-Agent Supply Chain & Fraud Optimization System
Run graph detection over the full transaction volume via NVIDIA cuGraph on GKE, instead of a sampled subset, with tuned ring-size and score thresholds to cut down false positives. Wire up a genuine streaming BigQuery ingestion pipeline, so the "live" badge is always true, everywhere it's deployed. Replace the current risk-stream chart with a real Looker dashboard for production-grade operational monitoring. Tighten the Gemini tool-calling configuration to reduce fallback-to-rules frequency, so the reasoning layer carries more of the real decision-making. Expand the action layer beyond freeze/reroute/review into a fuller set of operational tools — partial refunds, dynamic pricing adjustments, carrier re-negotiation — so the system can act across more of the actual decision space a risk operations team faces.
Log in or sign up for Devpost to join the conversation.