How to Build a transaction monitoring Agent Using CrewAI in Python for lending

A transaction monitoring agent for lending watches borrower account activity, flags patterns that suggest fraud, cash-flow stress, or policy breaches, and routes suspicious cases for review. In lending, this matters because missed signals turn into higher default rates, weaker underwriting feedback loops, and compliance exposure when suspicious activity is not documented.

Architecture

• •

  Ingestion layer

  • •Pulls transactions from core banking APIs, loan servicing systems, or event streams.
  • •Normalizes fields like amount, merchant, counterparty, timestamp, and account ID.
• •

  Policy and rules layer

  • •Encodes lending-specific thresholds.
  • •Examples: repeated cash deposits before repayment dates, salary diversion, circular transfers, or sudden balance depletion.
• •

  CrewAI agent layer

  • •Uses a crewai.Agent to classify transactions and explain why they are suspicious.
  • •Uses a crewai.Task to produce structured outputs for downstream case management.
• •

  Evidence retrieval layer

  • •Feeds the agent with borrower profile data, repayment schedule, historical behavior, and policy text.
  • •Keeps the model grounded in lender-specific context.
• •

  Case management output layer

  • •Writes alerts to a queue, database, or ticketing system.
  • •Stores reasoning traces for audit and model governance.

Implementation

1) Install dependencies and define the data contract

Start with CrewAI plus a small schema for transactions. Keep the payload strict so your agent does not infer fields that do not exist.

pip install crewai pydantic

from pydantic import BaseModel
from typing import Optional

class Transaction(BaseModel):
    transaction_id: str
    account_id: str
    amount: float
    currency: str
    merchant_category: Optional[str] = None
    counterparty: Optional[str] = None
    timestamp: str
    direction: str  # debit or credit
    channel: Optional[str] = None

2) Create a monitoring agent with explicit role and guardrails

Use Agent with a narrow job. For lending, the agent should not make credit decisions; it should only triage and explain risk indicators.

from crewai import Agent

transaction_monitor = Agent(
    role="Transaction Monitoring Analyst",
    goal=(
        "Review borrower transactions for fraud signals, repayment stress indicators, "
        "and policy breaches relevant to lending operations."
    ),
    backstory=(
        "You are a risk analyst supporting loan operations. "
        "You must produce concise alert rationales backed by the provided transaction data "
        "and borrower context."
    ),
    verbose=True,
)

3) Define a task that returns structured monitoring output

Use Task to force the agent into a repeatable format. In production, this output becomes your alert record.

from crewai import Task

monitor_task = Task(
    description=(
        "Analyze the provided borrower transaction set and identify suspicious patterns. "
        "Focus on cash-flow stress before repayment dates, unusual counterparties, "
        "rapid in-and-out movement of funds, and signs of income diversion."
    ),
    expected_output=(
        "A JSON-like summary containing risk_level, alert_reasons, recommended_action, "
        "and evidence references using only the supplied data."
    ),
    agent=transaction_monitor,
)

4) Run the crew and persist the result for audit

For lending workflows you want every decision traceable. Save both input context and output so compliance can reconstruct why an alert was raised.

from crewai import Crew

def monitor_transactions(transactions: list[Transaction], borrower_context: dict):
    crew = Crew(
        agents=[transaction_monitor],
        tasks=[monitor_task],
        verbose=True,
    )

    payload = {
        "borrower_context": borrower_context,
        "transactions": [t.model_dump() for t in transactions],
        "policy_notes": [
            "Flag repeated debit reversals within 72 hours.",
            "Flag salary-like credits followed by immediate cash withdrawals.",
            "Flag transfers to unrelated accounts before installment due dates.",
        ],
    }

    result = crew.kickoff(inputs=payload)
    return result


if __name__ == "__main__":
    txns = [
        Transaction(
            transaction_id="tx_001",
            account_id="acc_123",
            amount=950.0,
            currency="USD",
            merchant_category="cash_withdrawal",
            counterparty="ATM",
            timestamp="2026-04-20T09:15:00Z",
            direction="debit",
            channel="ATM",
        )
    ]

    context = {
        "borrower_id": "bor_789",
        "loan_type": "personal_loan",
        "next_due_date": "2026-04-25",
        "monthly_installment": 420.0,
        "country": "KE",
    }

    alert = monitor_transactions(txns, context)
    print(alert)

That pattern is enough to get a first production pilot running. The key is that Crew.kickoff() receives all relevant context up front so the agent can justify its output without guessing.

Production Considerations

• •

  Keep data residency explicit

  • •If borrower data must stay in-region, run the CrewAI worker in the same jurisdiction as your core banking data.
  • •Do not send raw PII or full account histories to external endpoints unless your legal basis and vendor contracts allow it.
• •

  Add deterministic pre-filters before the agent

  • •Use rules to shortlist only relevant transactions.
  • •This reduces cost and makes alerts easier to defend during audits because obvious threshold breaches are captured outside the LLM.
• •

  Log inputs, outputs, and versioned prompts

  • •Store task.description, policy notes, model version, timestamps, and final alert text.
  • •Lending compliance teams will ask why an alert was generated months later.
• •

  Put human review on high-risk cases

  • •The agent should triage; it should not auto-close or auto-escalate loans.
  • •Route high-severity alerts to an analyst queue with clear evidence references.

Common Pitfalls

• •

  Letting the agent make credit decisions

  • •Mistake: using the monitor as an approval/decline engine.
  • •Fix: keep it scoped to detection and explanation. Final lending decisions need separate policy logic and human oversight.
• •

  Feeding unbounded raw history into every run

  • •Mistake: sending months of transactions for every request.
  • •Fix: pre-filter by due date windows, anomaly scores, or rule hits so the agent works on a tight evidence set.
• •

  Ignoring auditability

  • •Mistake: only storing the final alert label.
  • •Fix: persist input payloads, prompt versions, output text, reviewer actions, and timestamps so you can defend decisions in compliance reviews.
• •

  Skipping jurisdiction checks

  • •Mistake: processing borrower data in whatever region your app happens to run.
  • •Fix: align deployment region with banking secrecy laws, local privacy rules, and internal retention policy before going live.

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.