How to Build a fraud detection Agent Using CrewAI in Python for pension funds

A fraud detection agent for pension funds flags suspicious member activity, contribution patterns, benefit claims, and administrator actions before they turn into financial loss or regulatory exposure. It matters because pension data is sensitive, long-lived, and heavily audited; a bad decision here is not just a chargeback problem, it can become a compliance incident.

Architecture

• •

  Data ingestion layer

  • •Pulls transaction logs, member profile changes, payroll feeds, claim events, and administrator actions from internal systems.
  • •Normalizes records into a consistent schema before analysis.
• •

  Risk scoring agent

  • •Uses rules plus LLM reasoning to classify suspicious patterns.
  • •Focuses on pension-specific signals like duplicate bank accounts, rapid beneficiary changes, unusual withdrawal timing, and contribution anomalies.
• •

  Investigation agent

  • •Summarizes why an alert fired.
  • •Produces an audit-friendly explanation with evidence references for compliance teams.
• •

  Policy and compliance guardrail

  • •Enforces pension fund rules: data residency, PII minimization, retention limits, and escalation thresholds.
  • •Blocks unsupported actions like auto-freezing accounts without human review.
• •

  Case management output

  • •Writes structured findings into a ticketing or case system.
  • •Includes severity, reason codes, evidence, and recommended next step.

Implementation

1) Install CrewAI and define the task boundaries

Use CrewAI for orchestration and keep the agent narrow. For pension funds, the agent should detect and explain risk; it should not make final adjudication decisions.

pip install crewai crewai-tools pydantic

Create a minimal input model so your pipeline stays explicit:

from pydantic import BaseModel
from typing import List

class FraudCase(BaseModel):
    case_id: str
    member_id: str
    event_type: str
    amount: float
    country: str
    notes: List[str]

2) Build the agents with role-specific instructions

CrewAI’s Agent class is where you encode the operating policy. Keep one agent focused on detection and one on explanation so you can audit outputs separately.

import os
from crewai import Agent

fraud_detector = Agent(
    role="Pension Fraud Detection Analyst",
    goal="Identify suspicious pension fund activity using transaction patterns and policy rules.",
    backstory=(
        "You review pension member events for fraud indicators such as "
        "beneficiary manipulation, duplicate payouts, abnormal withdrawals, "
        "and administrator abuse."
    ),
    verbose=True,
    allow_delegation=False,
)

fraud_explainer = Agent(
    role="Fraud Investigation Analyst",
    goal="Explain why an event is suspicious in audit-ready language.",
    backstory=(
        "You write concise investigation notes for compliance teams and case managers."
    ),
    verbose=True,
    allow_delegation=False,
)

If your environment uses hosted models through OPENAI_API_KEY, CrewAI will pick that up through the configured LLM provider. In production, pin the model explicitly in your app config so behavior doesn’t drift.

3) Define tasks that produce structured outputs

The pattern that works in regulated environments is: detect first, then explain. The first task should return a risk classification with evidence; the second should turn that into a case note that a human reviewer can use.

from crewai import Task

detect_task = Task(
    description=(
        "Review this pension fund event for fraud indicators.\n"
        "Event type: {event_type}\n"
        "Amount: {amount}\n"
        "Country: {country}\n"
        "Notes: {notes}\n\n"
        "Return:\n"
        "- risk_level: low|medium|high\n"
        "- reason_codes: list of short codes\n"
        "- evidence_summary: short paragraph\n"
        "- escalate_to_human: true|false\n"
        "Do not recommend account closure."
    ),
    expected_output="A compact fraud assessment with reason codes and escalation flag.",
    agent=fraud_detector,
)

explain_task = Task(
    description=(
        "Turn the fraud assessment into an audit-ready investigation note "
        "for a pension fund compliance team. Mention why this matters under "
        "member protection and recordkeeping obligations."
    ),
    expected_output="An investigation note with clear reasoning and next steps.",
    agent=fraud_explainer,
)

4) Assemble the crew and run it against a real case

Use Crew, set process=Process.sequential, and keep human review in the loop for high-risk outcomes. That gives you deterministic flow and cleaner audit trails.

from crewai import Crew, Process

def analyze_case(case: FraudCase):
    crew = Crew(
        agents=[fraud_detector, fraud_explainer],
        tasks=[detect_task, explain_task],
        process=Process.sequential,
        verbose=True,
    )

    result = crew.kickoff(inputs={
        "event_type": case.event_type,
        "amount": case.amount,
        "country": case.country,
        "notes": "; ".join(case.notes),
    })
    return result


if __name__ == "__main__":
    case = FraudCase(
        case_id="CASE-1042",
        member_id="MEM-7781",
        event_type="beneficiary_change_and_withdrawal",
        amount=48000.00,
        country="ZA",
        notes=[
            "Bank account changed twice in 48 hours",
            "Withdrawal requested shortly after beneficiary update",
            "Same device used across two member profiles",
        ],
    )

    output = analyze_case(case)
    print(output)

That is enough to get a working baseline. In a real pension environment, you would insert your own data retrieval before kickoff() and persist both inputs and outputs to an immutable audit store.

Production Considerations

• •

  Data residency

  • •Keep member PII inside approved regions.
  • •If your LLM endpoint leaves jurisdiction boundaries, redact names, IDs, bank details, and addresses before sending data out.
• •

  Auditability

  • •Store every prompt input, model output, reason code, timestamp, model version, and reviewer decision.
  • •Pension funds need traceability for regulators and internal audit.
• •

  Human-in-the-loop controls

  • •Require manual approval for high-risk cases.
  • •The agent should escalate; it should not execute irreversible actions like payment reversal or account lockout.
• •

  Monitoring

  • •Track false positives by event type: contributions, withdrawals, beneficiary changes, employer remittances.
  • •Watch for drift when new fraud patterns appear or when administrators change workflows.

Common Pitfalls

• •

  Sending raw PII to the model

  • •Don’t pass full national IDs or bank details unless you have explicit approval and contractual controls.
  • •Redact first; rehydrate only inside your secure system after scoring.
• •

  Letting the agent decide enforcement

  • •The model should recommend escalation, not freeze accounts or deny claims.
  • •Put enforcement behind deterministic business rules and human review.
• •

  Using generic prompts for regulated workflows

  • •A generic “detect fraud” prompt misses pension-specific issues like delayed employer contributions or unauthorized beneficiary edits.
  • •Encode domain signals directly in task descriptions and validation rules.

A good pension fraud agent is narrow, explainable, and boring in the right places. That’s what you want when auditors ask why a member was escalated or why a payment was held.

Keep learning

• •The complete AI Agents Roadmap — my full 8-step breakdown
• •Free: The AI Agent Starter Kit — PDF checklist + starter code
• •Work with me — I build AI for banks and insurance companies

By Cyprian Aarons, AI Consultant at Topiax.