How to Build a Simple, Modular, and AI-Powered Fraud Detection Workflow

Fraud doesn’t wait. Neither should your defenses.

This blog is a step-by-step visual guide to building a smart, AI-assisted fraud detection workflow using Orkes Conductor.

It's designed for developers, built to scale, easy to extend, and surprisingly fun to work with. The core logic stays clear, visible, and modular throughout.

People try to game the system all the time. Stolen cards, fake claims, identity fraud, you name it. We need a smart way to stop that.

OK, story time: a sneaky little transaction troll tries to slip through your defences.

For some teams, that’s a disaster. A reputational scandal. Monetary loss. Maybe even their business goes down. But not for you.

Why? Because they run straight into your Orkes-powered workflow:

• An LLM scores the fraud risk
• Business logic routes the case
• A calm human reviewer (coffee in hand) handles the high-risk stuff

The end. And maybe that's not the most thrilling story, but a solid fraud defense? Absolutely.

So how do you actually build something that slick? I'm so glad you asked.

What You’ll Build

Before you know it, you’ll create a modular, AI-powered fraud detection workflow that:

• Generates sample transaction data using an LLM.
• Analyzes each transaction and assigns a fraud risk score using AI.
• Routes high-risk cases to a human reviewer for decision-making.
• Automatically processes low-risk transactions via a dedicated payment_flow sub-workflow.
• Logs all decisions and outcomes for auditability and traceability.

Why modular? Because fraud logic evolves. With a modular setup, you can update prompts, change routing rules, or plug in new services without touching the rest of the workflow. It keeps things flexible, testable, and easy to scale.

And most importantly, you’ll have a workflow that’s smart, scalable, and always ready to catch the next bad actor.

Let’s jump right in.

💻 Let’s Build It: The “FraudDetection” Workflow

GitHub repo: https://github.com/conductor-oss/awesome-conductor-apps/tree/main/javascript/fraud_detection_management

Workflow Overview

The whole fraud detection setup uses 2 AI prompts and 3 smaller workflows. They are built to keep things modular, reusable, and easy to tweak as you go.

The workflow is triggered automatically for every transaction, acting as a real-time fraud scanner that evaluates, scores, and routes each one without delay.

The 2 AI Prompts:

• fraudDetector: Generates sample transactions
• riskScore: Evaluates fraud risk on a scale of 0–3

The 3 Workflows:

• generate_transaction_workflow
• execute_Rules
• payment_flow

Prerequisites (if you want to follow along)

You'll need:

• Access to Orkes Conductor UI (you can use our Developer Edition)
• OpenAI credentials

And you're good to go!

🧑‍💻 Step-by-Step: Build the Workflow in Conductor

Using the Conductor UI, you can visually build and manage the entire fraud detection workflow without writing backend code. Don’t come at me, coders. Writing code is great, but you’ll see just how powerful and awesome it is to build and orchestrate everything visually in the Conductor UI.

Bonus for the curious: Every action you take in the UI is automatically translated into JSON behind the scenes. That same JSON can be exported, version-controlled, or used programmatically via Orkes SDKs (available in Java, Python, Node.js, and more).

So whether you're a visual thinker or a die-hard developer, you've got options.

We’ll start by writing the two AI prompts that will power our workflow, so we have them ready and configured before wiring everything together in Conductor.

AI Prompt 1: fraudDetector

Generates 3 sample financial transactions per run, with realistic fields for fraud analysis.

Key Output Fields:

• transaction_id → A unique alphanumeric string
• user_id → A unique identifier for the user
• amount → (0 to 1,000,000)
• transaction_type → e.g., wire_transfer
• source → (sender ID)
• destination → (receiver ID)
• fraud_history → (yes/no)

Prompt Behavior:

• Returns structured JSON only. No extra explanations or formatting.
• Built to make the next steps easy to handle.

fraudDetector AI Prompt template:

Generate 3 random transaction records across multiple entities for fraud detection analysis. The transactions should include:
transaction_id: A unique alphanumeric string.
user_id: A unique identifier for the user.
amount: Random values from 0 - 1,000,000
transaction_type
source: random identifier representing the sender (src)
fraud_history: yes or no
destination: random identifier representing the receiver (dst)
Return ONLY a valid JSON array with no explanations or markdown code blocks

We want a clean output we can use, and some LLMs can include extra explanation in their results so it's good to explain what return you'd want.

Sample output:

[
  {
    "transaction_id": "TXN9A2L7X5",
    "user_id": "USR1034",
    "amount": 743219.50,
    "transaction_type": "wire_transfer",
    "source": "SRC8712",
    "fraud_history": "no",
    "destination": "DST4591"
  },
  ...
]

AI Prompt 2: riskScore

Each transaction is scored on a 0-3 fraud risk scale.

• 0-1: Low Risk
• 2-<3: Medium Risk
• 3+: High Risk

Prompt Template Highlights:

• Scores each transaction using GPT.
• Returns only the score and confidence.
• Routes high-risk cases to manual review.

riskScore AI Prompt template:

You are a fraud detection system analyzing financial transactions for potential fraud.
Given the following transaction details:

Transaction ID: ${transaction_id}

User ID: ${user_id}

Transaction Amount: ${amount}

Transaction Type: ${transaction_type}

Source: ${source}

Destination:${destination}

Past Fraudulent Activity (Yes/No): ${fraud_history}

Using the information provided only return a fraud risk score (0-3) with no additional information where:

0-1: Low Risk

2-3: Medium Risk

>3: High Risk

If data is missing just state To provide a fraud risk score based on the transaction details, I would need specific values for the placeholders you provided (e.g., transaction_id, user_id, amount, transaction_type, source, destination, and fraud_history)
Finally also return a confidence score

Where do the ${transaction_id}, ${user_id}, and other variables come from?

These placeholders are automatically populated with real values from the sample transactions generated by the first AI prompt (fraudDetector). When the generate_transaction_workflow runs, it creates structured JSON output containing transaction data. That data is then passed into the riskScore prompt using Conductor’s variable substitution. So ${amount} becomes something like 743219.50, ${user_id} becomes USR1034, and so on. This is handled visually using the UI's built-in data mapping.

💡 Pro tip for developers:

When you're testing an AI Prompt inside the Conductor UI, you can manually enter test values for these variables to simulate real-world input. This makes it easy to fine-tune your prompt, validate output, or debug without needing to run the full workflow every time.

This built-in substitution keeps your prompts dynamic, reusable, and perfectly aligned with your data-driven workflow.

Now time for those workflows!

Workflow 1: generate_transaction_workflow

You can check out the workflow code on GitHub.

This is a simple sub-workflow that:

• Runs the fraudDetector AI prompt.
• Parses the results into valid JSON
• Sends results into the fraud detection pipeline.
• Is made up of 3 tasks: fraud_prompt, parse_transactions, and send_transaction.

Workflow 2: execute_Rules

You can check out the workflow code on GitHub.

This is where risk scoring and decision logic happen.

The workflow begins by going through the generate_transaction_workflow sub-workflow.

Once generate_transaction_workflow finishes, its outcomes (the transactions generated) are passed to the next task in the flow. In this case, the outcome is passed to the do_while loop. he workflow enters a loop that processes each transaction individually.

Workflow 3: payment_flow

You can check out the workflow code on GitHub.

This sub-workflow is where the real action happens, only for transactions that have cleared all fraud checks, whether they breezed through as low risk or got the green light from a human reviewer.

Here, we validate the data, kick off the payment, log what happened, and maybe even send out a few notifications. In this demo, there’s just a placeholder task to show where things go, but this is your spot to plug in the real payment logic.

It runs automatically for low-risk payments and only kicks in for high-risk ones after approval. Keeping payment stuff separate from fraud detection makes everything cleaner, easier to manage, and way more flexible when you're ready to scale or swap out components.

Why This Modular Design Works

• Separation of concerns: Keep fraud logic and payment flows decoupled
• Scalable: Modify fraud rules or payment methods independently
• Auditable: Logs everything clearly
• Flexible: Easy to test and extend

What's Next

You’ve just seen how to build an AI-assisted fraud detection workflow — smart enough to flag risky behavior, fast enough to act in real time, and flexible enough to grow with you.

But this is just your launch pad.

Here’s how to level it up:

• Add alerts to notify teams in real time
• Use review decisions to retrain your models
• Integrate dashboards and CRMs
• Add more logic like geolocation or device checks

Try it instanly

Want to see it live in under 5 minutes?

• Sign up for the free Developer Edition — no setup, no waiting.
• Paste in the provided JSON from the GitHub repository, and watch an entire workflow spin up before your eyes.

Join the conversation

Come hang out on Discourse, share ideas, and help us catch the next wave of fraud innovation. I am on there to answer any questions.