DEV Community: Yash Fadadu

FraudLens: We Built a Fraud Investigator on TigerGraph, Not a Fraud Classifier

Yash Fadadu — Thu, 24 Sep 2026 03:05:21 +0000

FraudLens: building a fraud investigator on TigerGraph, not a fraud classifier

By Team TrustMeBro (Yash, Manan, Priyank), built at Goa Hackerhouse 2026 with @TigerGraphDB and @247pmstudio

Why we didn't build a classifier

Before Goa Hackerhouse 2026, none of us had used a graph database seriously. The challenge changed that. We were given a bank's card transactions, a history of closed fraud investigations, and 20 open alerts, and asked to build an agent that investigates.

That word matters. A classifier looks at one transaction and outputs "fraud: 0.91". But the data warns that most high-scoring alerts are actually legitimate. A real analyst doesn't stop at the score. They ask:

Does this purchase fit how this customer normally spends?
Has this device been used on other cards?
Have we seen this pattern before, and how did that case end?
Is there an innocent explanation?
Is it worth calling the customer before blocking the card?

Almost all of those questions are about relationships. That's why we built on a graph.

What FraudLens does

Give FraudLens an alert (a risk score, a customer complaint, or an analyst note) and it runs a full investigation:

Confirms the alert makes sense. Does the transaction exist, belong to that card, and does the card belong to that customer?
Gathers evidence from the graph. Transaction history, spending baseline, devices, regions, email domains, connected cards.
Tests the known fraud patterns. Card testing, account takeover, new-device online fraud, out-of-region use, and recurring charges that were disputed but are really legitimate.
Looks for the innocent explanation. This step is required, not optional.
Retrieves similar past cases from the bank's closed-case history.
Estimates probability and uncertainty, then makes an initial decision.
Asks for more evidence only if the answer could change the decision. For example, it can ask the customer to confirm the purchase. If no possible answer would change the recommended action, it skips the request.
Makes a final decision, filing a suspicious activity report (SAR) when policy requires one.
Writes the whole case back to TigerGraph, then reads it back to confirm the write actually happened.

Architecture

            Alert (risk score / complaint / analyst note)
                                │
                                ▼
                   ┌─────────────────────────┐
                   │ LangGraph investigator  │  plan → evidence → counter-evidence
                   │   (stateful workflow)   │  → memory → assess → need more?
                   └────────────┬────────────┘
           business tools only  │  (no raw database access)
                                ▼
                   ┌─────────────────────────┐
                   │ TigerGraph (Savanna)    │  schema, ~26 installed GSQL queries,
                   │ GSQL + graph algorithms │  ring discovery, case memory
                   └────────────┬────────────┘
                                ▼
    ┌──────────────────┐  ┌───────────────────┐  ┌──────────────────────┐
    │ Policy engine    │  │ Evidence simulator│  │ LLM (Gemini)         │
    │ R1–R10, routes   │  │ seeded responses  │  │ planning + prose only│
    │ auto / L1 / L2   │  └───────────────────┘  │ deterministic backup │
    └──────────────────┘                         └──────────────────────┘
                                │
                                ▼
          FastAPI  →  React analyst workbench  +  20 validated answer files

Each layer has one job, and a clear list of things it is not allowed to do:

Layer	Owns	Never owns
TigerGraph + GSQL	Relationships, traversal, pattern evidence, case memory	Fraud verdicts
Policy engine	Rules R1–R10, approval routes, when a report is required	Reasoning or graph access
LangGraph agent	State, which evidence to gather, when to stop	Approving any action
LLM	Planning, summarising, explaining	Facts, policy, IDs, probability

The split we care about most: the LLM cannot approve anything. It can recommend blocking a card. A deterministic policy engine decides whether that action is allowed and who has to approve it: auto, a level-1 analyst (L1), or a level-2 analyst (L2). The API checks this a second time, so a client calling the API directly can't execute an action that needs approval either.

How we used TigerGraph

The graph model

We didn't turn all 400+ columns in the dataset into vertices. Only the things investigations actually walk through became vertices. The rest stayed as transaction attributes.

Core entities: Customer, Card, Transaction
Shared origins: DeviceProfile, EmailDomain, BillingRegion (how separate cards turn out to be linked)
Case memory: FraudCase, Evidence, EvidenceRequest, ActionDecision
Key edges: OWNS, MADE, FROM_DEVICE, BILLED_IN, INVOLVES, SIMILAR_TO, HAS_EVIDENCE, RECOMMENDS

One detail we liked: a NEXT edge links each card's transactions in time order. Looking at "what happened around this transaction" then becomes a short walk along those edges, not a scan of the whole table.

Data loaded: 590,742 transactions, 13,553 customers, 14,317 cards, 9,702 device profiles, 576,425 NEXT edges, and 5,565 closed historical cases.

GSQL does the graph work

We had one rule: if a question is about relationships, TigerGraph answers it. No Pandas joins, and no asking the LLM to guess whether two accounts are connected. We wrote about 26 installed queries, grouped like this:

Anchor and context: get_case_anchor, get_card_window, get_customer_baseline
Pattern detection: detect_card_testing, detect_account_takeover, detect_region_anomaly, detect_cnp_burst, detect_recurring_charge
Relationships: find_device_connections, get_shared_origin_ring
Graph algorithms: connected_cards_component, find_high_fanout_origins, refresh_device_fanout
Case memory: find_similar_cases, get_case_history, get_case_graph
Write-back: upsert_case, add_case_evidence, add_action_decision, verify_case_bundle

Every read query takes a cutoff time. A case opened on 5 December must not see anything from 6 December. We made the cutoff a required parameter rather than a convention, so it can't be forgotten, and it can be tested.

Here is part of get_shared_origin_ring, which finds other cards that used the same device, region, or email domain inside the time window:

RingTxnsByDevice = SELECT t FROM OriginMatch:o -(DEVICE_USED_BY>)- Transaction:t
                   WHERE datetime_diff(cutoff, t.ts) >= 0
                     AND datetime_diff(t.ts, window_start) >= 0;
RingTxnsByRegion = SELECT t FROM OriginMatch:o -(BILLING_REGION_OF>)- Transaction:t
                   WHERE datetime_diff(cutoff, t.ts) >= 0
                     AND datetime_diff(t.ts, window_start) >= 0;
RingTxnsAll = RingTxnsByDevice UNION RingTxnsByRegion UNION RingTxnsByEmail;

RingCards = SELECT c FROM RingTxns:t -(MADE_BY>)- Card:c
            WHERE c.card_id != exclude_card_id
            ACCUM @@connected_cards += c.card_id,
                  @@connected_customers += c.customer_id
            LIMIT max_cards;

MCP: small tools, not a database connection

The agent reaches TigerGraph through tools named after what an investigator does: find_connected_accounts, trace_money_flow, find_device_connections, find_similar_cases, and so on. Our own MCP server exposes 12 of these tools, all read-only and all enforcing the cutoff. The official tigergraph-mcp server is also registered, restricted to read-only tools.

Writing is deliberately not a tool the model can call. A model that can write arbitrary graph data could create its own evidence. Case write-back goes through one checked persistence step instead.

Evidence that can be checked

Every piece of evidence records its source and the exact query that produced it, for example query:get_case_anchor(card_id=C12382-K1, customer_id=C12382, txn_id=3514030). An analyst can re-run the query and check the claim. Conclusions the agent draws are stored separately and never presented as facts.

Case memory that has to be earned

When a case closes, FraudLens writes the case, its evidence, evidence requests, actions and links to similar past cases into the graph. Each case gets a fixed ID, so re-running a case overwrites it instead of creating a duplicate. Then verify_case_bundle reads it back and compares counts and a hash. The answer file only says written_to_graph: true if the two match.

Past bank cases and our agent's own cases are stored the same way, but each is tagged with a trust tier. That way, the agent's own conclusions are never cited as if they were the bank's confirmed outcomes.

Results

We ran all 20 benchmark cases in time order against the live TigerGraph graph, so earlier cases became memory for later ones.


Cases investigated	20 of 20, all passing the answer validator
Written to graph and verified by read-back	20 of 20
Verdicts	7 fraud, 12 legitimate, 1 uncertain
Suspicious activity reports	6
Graph queries per case	21–34

The mostly-legitimate split is intended. The challenge warns that about half these alerts turn out to be legitimate, and an agent that blocks everything scores badly.

The evidence request made a visible difference. In one case the initial recommendation was to monitor the card, and after new evidence it changed to block (L1 approval). In another, an initial block became close, no fraud once the customer confirmed the purchase.

The system also keeps working if the LLM is down. When our free-tier model quota ran out, the explanations fell back to evidence-based template text, and every verdict, action and report stayed the same.

What we learned

Test data only finds the bugs you expect. Our small test data passed everything. Real data and a live database found new problems:

Fake links. The most "shared" device profiles were unknown | unknown | unknown (1,011 customers) and one very common Windows + Chrome setup (842 customers). Those are common settings, not real devices, but they linked unrelated people. That pushed our report rate to 70%. Requiring a profile to be specific before it can link anyone brought it down to 6 of 20.
GSQL surprises on a live instance. Case and count are reserved words, so we renamed our vertex type to FraudCase. Boolean defaults didn't parse the way we expected. Loading files by column name failed on Savanna because the server can't see our local files, so we switched to column positions. In some query outputs, field names came back prefixed (TheCase.bundle_hash instead of bundle_hash). That silently broke our write-back check until we renamed every field explicitly.
Check the graph directly, not the logs. Our first bulk load reported success but was missing about 14,000 transactions. Only comparing vertex counts against the source file caught it.

What's next

Calibrate the fraud probability against the bank's closed-case history, measured over time.
Load the policy and regulatory documents into the graph as searchable chunks. The schema for this (Document, DocumentChunk, CITES) is already in place.
Route the investigator's own tool calls over MCP. Today it calls the same tool functions directly.

Thanks to @TigerGraphDB and @247pmstudio for Goa Hackerhouse 2026. We came in knowing tables and left thinking in graphs. 🙌

Team TrustMeBro: Yash, Manan, Priyank

🚀 What Really Happens When You Call .add() Twice? Classic BLoC vs BlocSignal

Yash Fadadu — Thu, 06 Aug 2026 17:57:52 +0000

We've all been there.

You're building a Flutter app with BLoC, and somewhere in your business logic you write:

myBloc.add(LoadUserData());
myBloc.add(FetchUserPreferences());

Immediately, a thought pops into your head...

🤔 "Wait... did I just overwrite the first event before the UI even had a chance to rebuild?"

Or maybe:

Will EventB execute before EventA finishes?
Will the UI skip StateA?
If I read bloc.state immediately after .add(), what state do I get?
What happens if I call .add() 10,000 times?

Let's lift the hood and compare Classic BLoC and BlocSignal.

🤯 The Common Misconception

Many developers imagine something like this:

EventA
   ↓
StateA

EventB
   ↓
StateB

↓

UI only sees StateB 😱

The fear is that rapid-fire .add() calls somehow overwrite each other before Flutter can render.

Fortunately...

That's not how either implementation works.

The difference lies in how state propagates, not whether events get lost.

🐢 Classic BLoC (Streams)

Traditional flutter_bloc is built on top of Dart Streams.

A simplified flow looks like this:

.add(Event)

        ↓

 StreamController

        ↓

 Event Handler

        ↓

 emit(State)

        ↓

 State Stream

        ↓

 BlocBuilder Listener

        ↓

 markNeedsBuild()

        ↓

 Flutter Frame

Notice something important:

Flutter does not rebuild immediately.

It simply marks the widget as dirty and rebuilds during the next rendering frame.

So what happens?

Imagine:

bloc.add(EventA());
bloc.add(EventB());

Internally it behaves more like:

EventA

↓

Handler runs

↓

emit(StateA)

↓

Widget marked dirty

↓

EventB

↓

Handler runs

↓

emit(StateB)

↓

Widget marked dirty again

↓

Flutter renders

↓

Latest state displayed

No event is lost.

Both handlers execute.

The UI simply paints the latest settled state when Flutter decides to render the next frame.

⚡ BlocSignal (Signals)

BlocSignal keeps the familiar BLoC programming model...

bloc.add(...)
emit(...)

...but replaces Streams with Signals.

Its propagation path is much shorter.

.add(Event)

      ↓

Handler

      ↓

emit(State)

      ↓

Signal

      ↓

BlocSignalBuilder

      ↓

markNeedsBuild()

      ↓

Flutter Frame

The biggest difference is:

The handler executes synchronously.

Meaning this:

bloc.add(EventA());

print(bloc.state);

already prints

StateA

because the state has already been updated before .add() returns.

Then...

bloc.add(EventB());

starts.

So EventB always sees the latest state.

🤔 Doesn't that rebuild the UI every time?

This is probably the most interesting question.

Suppose you do something completely unreasonable 😂

for (int i = 0; i < 10000; i++) {
  bloc.add(IncrementEvent());
}

Many people imagine:

markNeedsBuild()

↓

Build

↓

markNeedsBuild()

↓

Build

↓

markNeedsBuild()

↓

Build

10,000 times.

Fortunately...

Flutter is much smarter than that.

🎨 What `markNeedsBuild()` Actually Does

Calling

markNeedsBuild();

does not immediately rebuild the widget.

It simply tells Flutter:

"This widget is dirty."

Internally it's roughly equivalent to:

_dirty = true;

If it's already dirty...

Setting

_dirty = true;

again changes nothing.

markNeedsBuild()

markNeedsBuild()

markNeedsBuild()

markNeedsBuild()

still results in

_dirty == true

Once Flutter reaches the next frame...

it performs one build using the latest state.

📊 Classic BLoC vs BlocSignal

Feature	Classic BLoC 🐢	BlocSignal ⚡
State Propagation	Stream-based	Signal-based
Handler Execution	Stream/event pipeline	Direct synchronous execution
`bloc.state` immediately after `.add()`	Depends on propagation timing	Updated immediately
Internal Dispatch	Stream subscriptions	Signal dependency graph
UI Rendering	Flutter frame pipeline	Flutter frame pipeline
Widget Rebuild	Deferred to Flutter	Deferred to Flutter
Developer Experience	Mature & battle-tested	Familiar API with Signals underneath

🎯 So... what does BlocSignal actually optimize?

The optimization isn't that Flutter suddenly rebuilds faster.

Flutter's rendering pipeline is exactly the same.

Instead, BlocSignal removes much of the reactive plumbing:

❌ StreamController

❌ Stream subscriptions

❌ Stream dispatch

❌ Async propagation through streams

Replacing it with:

✅ Direct synchronous state updates

✅ Signal dependency propagation

✅ Immediate state availability

This makes the execution path shorter and more predictable.

💙 Final Thoughts

Calling:

bloc.add(EventA());
bloc.add(EventB());

is perfectly safe.

Neither Classic BLoC nor BlocSignal loses events.

The key difference is how the new state travels from your business logic to the UI.

🐢 Classic BLoC uses a Stream-based propagation pipeline.
⚡ BlocSignal replaces that pipeline with synchronous Signal propagation.

Both still rely on Flutter's rendering engine, which intelligently batches widget rebuilds into the next frame.

So no matter how many times you call .add(), Flutter only paints what actually matters—the latest settled state.

🔥 Solved 1000 LeetCode Questions — Here's What I Learned (and Didn't)

Yash Fadadu — Fri, 30 May 2025 06:25:58 +0000

✅ 1000 LeetCode Questions — Done!

Just hit a huge milestone:

Hello I'm Yash Fadadu, I’ve completed 1000 questions on LeetCode ✌️

And no — I’m not at Google. Not yet at Microsoft either.

But that’s not what this post is about.

✨ Was it worth it?

Short answer: Yes. But not for the reasons you might think.

❓ Did I become a DSA expert? – Not yet

💼 Got an offer from FAANG? – No

🧠 Learned something deeper? – 100%

💡 What I Actually Learned

Solving LeetCode isn’t about flexing IQ.

It’s about consistency, discipline, and learning to think like a developer.

You can study all the patterns and still get stuck. That’s normal.
You won’t love every part of it — but that’s the point.
It teaches you to show up even when it’s tough.
It’s about building mental endurance as much as technical skill.

I often felt like ditching LeetCode to focus on building real-world things — AI tools, beautiful UIs, full-stack apps.

But this journey reminded me:

🔁 “You grow most when you don’t feel like it.”

📝 Tips If You're Just Starting

Here’s what helped me — and might help you:

📚 Master the basics: Arrays, Strings, Linked Lists, Trees
🎯 Learn core patterns: Two Pointers, Sliding Window, Binary Search, Recursion
🤏 Start with easy problems — they build confidence
⏱️ Stuck for more than an hour? Read the solution
🧠 Study a topic before attempting questions on it
🔁 Make it a daily habit, not a sprint
🔍 Get good at time & space complexity — it’ll make your intuition stronger

✅ Real Benefits I’ve Seen

🧩 Understanding DSA helped me in blockchain, AI/ML, game dev, and full-stack work.
💡 I write cleaner, more optimized code.
🔐 Most of all, it changed my mindset: I now look at problems with more clarity and confidence.

🛠️ Let's Connect

🚀 What’s Next?

1000 done.

Now chasing 2000 🧠⚡

Because the goal is never just a number — it’s to become better than yesterday.

If you're on the same journey, let’s connect.

Drop your milestones, tips, or struggles in the comments! 🙌

🧠 The S-400 and Smart Defense: How AI Algorithms Could Revolutionize Automated Air Defense

Yash Fadadu — Fri, 23 May 2025 10:06:25 +0000

The S-400 Triumf air defense system is a marvel of military engineering. With the ability to track and destroy aircraft, drones, and missiles over 400 km away, it’s one of the most feared SAM systems in the world.

But here’s the reality: while the S-400 uses advanced automation, it doesn't yet use true AI—as in learning algorithms that improve over time.

So, what if we applied real machine learning? Let’s explore the algorithms that could bring the next level of intelligence to air defense systems like the S-400.

**🔄 Current Automation in the S-400
The S-400 currently uses:

Rule-based threat prioritization: if X is moving fast at Y altitude, treat it as a missile.

Predefined radar tracking filters: such as Kalman filters to estimate object trajectories.

Hard-coded decision trees for assigning missiles to targets.

These systems are fast and reliable, but they’re not adaptive. They can’t learn from new types of threats or behavior.

🤖 What AI Can Add: The Algorithms That Matter
Let’s go over specific AI/ML algorithms that could supercharge an air defense system:

1. 🧮 Convolutional Neural Networks (CNNs) for Visual Target Identification

If integrated with optical or infrared sensors:

Purpose: Classify aircraft, drones, or decoys visually.

How it works: CNNs learn patterns in images (like turbine shapes, wing profiles) and can outperform traditional object detection in noisy environments.

Example use: Detect if a low-flying object is a real UAV or a decoy balloon.

2. 📈 Reinforcement Learning (RL) for Engagement Decision-Making

Purpose: Learn optimal defense strategies through simulation and feedback.

How it works: RL agents (like Deep Q-Networks or PPO) try different missile-target strategies in a simulated battlefield. Over time, they learn what decisions lead to success.

Example use: Learn the best firing sequence when faced with a saturation drone swarm attack.

3. 🧠 LSTM (Long Short-Term Memory) Networks for Trajectory Prediction

Purpose: Predict where a target will go based on past movement.

How it works: LSTMs are a type of Recurrent Neural Network (RNN) that can learn temporal patterns—perfect for motion prediction in noisy environments.

Example use: Predict where a hypersonic missile will be 3 seconds from now, even if it suddenly changes direction.

4. 🔍 Anomaly Detection with Autoencoders

Purpose: Spot spoofed or jammed radar signals.

How it works: An autoencoder learns the "normal" signal patterns. When it sees a signal that doesn’t fit, it flags it as a potential threat or decoy.

Example use: Detect radar jamming or stealth aircraft signature anomalies.

5. 🧾 Decision Trees + XGBoost for Threat Classification

Purpose: Classify threats based on structured data (speed, altitude, radar cross-section).

How it works: These models excel at classifying tabular input—like sensor values—into risk levels.

Example use: Score each target in real-time with a “threat score” from 0 to 100.

🔐 Why This Matters

The future battlefield will be filled with:

Swarm drones
Hypersonic missiles
AI-driven stealth aircraft
ECM (Electronic Counter Measures)

To survive, air defense systems need to be just as smart as they are fast.

🧑‍💻 Developers: Your Skills Matter

If you're a developer working in:

AI/ML
Embedded systems
Edge computing
Signal processing

...you can help build the brains behind these next-gen defense systems. It's not just about writing software—it's about writing code that makes life-and-death decisions smarter, safer, and more accountable.

🧠 Final Thoughts

The S-400’s automation is solid—but static. By integrating real AI algorithms, we could enable defense systems to learn from experience, adapt to new threats, and respond faster than any human could.

💬 What’s your take on using machine learning in defense systems? Exciting? Risky? Both? Drop your thoughts below.

Ghibli Art Generation AI — The Fusion of Machine Learning and Animated Aesthetics

Yash Fadadu — Wed, 14 May 2025 14:10:08 +0000

🧠 Overview

Ghibli-style art generation through AI represents a fascinating application of generative deep learning models, particularly those based on diffusion architectures. These systems are capable of producing high-quality, stylized illustrations that resemble the iconic aesthetics of Studio Ghibli’s animation—characterized by soft color palettes, emotional atmospheres, and richly detailed environments.

🔍 How It Works

Ghibli art generation is typically powered by text-to-image and image-to-image models, such as Stable Diffusion, DreamBooth, or LoRA-tuned variants. These models are trained or fine-tuned on large datasets of artwork that resemble or replicate the Ghibli aesthetic.

Key components include:

Diffusion Models: Probabilistic generative models that iteratively denoise random noise into meaningful images. When trained on Ghibli-style datasets, these models learn to reproduce similar artistic features.

DreamBooth / LoRA Fine-Tuning: Techniques used to customize a base model to learn specific art styles. DreamBooth helps the model internalize unique visual characteristics by overfitting on a small curated dataset (e.g., 100–500 images of Ghibli-style frames or fan art).

Text Prompt Engineering: Users describe scenes in natural language (e.g., “a magical forest with floating lanterns”), and the model interprets this to generate corresponding imagery, integrating the learned Ghibli-like features.

Image-to-Image Translation: Users can input photos or sketches, and the model reinterprets them in Ghibli style, preserving structure while applying the aesthetic transformation.

📊 Dataset Considerations

Due to copyright constraints, training typically avoids using original Studio Ghibli frames directly. Instead, fine-tuning datasets often consist of:

High-quality fan art

Open-source anime-style illustrations

Stylized concept art that reflects similar themes and color schemes

Data augmentation (color jittering, cropping, flipping) is used to improve generalization while preserving artistic coherence.

🧠 Technical Stack

While implementations vary, a standard Ghibli-style art generation stack might include:

Model Backbone: Stable Diffusion 1.5 or SDXL

Fine-Tuning Framework: DreamBooth, LoRA, or Textual Inversion

Inference Backend: Python + PyTorch with Hugging Face Transformers & diffusers

Frontend Interface: Web apps built with React or Gradio for demo interactions

Deployment: GPU-accelerated platforms like Hugging Face Spaces, Replicate, or custom servers using NVIDIA GPUs

✨ Applications

Creative Art Generation: Allowing users to visualize fantasy scenes or original characters in a beloved animated style.

Concept Design: Useful for illustrators and indie animators needing quick prototyping in an established aesthetic.

Education: Demonstrating how AI can learn and replicate complex visual styles from limited data.