All example architectures
Fintech / Risk

From end-of-day fraud reports to real-time alerts

Scenario: a regional payments processor replaces a nightly SQL batch with a streaming flow: every card transaction becomes an event, a scheduled flow scans the trailing 24h window through an LLM analyst, and anything flagged fans out to email + in-app alerts. LLM spend is logged line-by-line so finance can tie alerts to cost.

Illustrative scenario — not a customer deployment. Numbers are targets for comparable workloads.

Target outcomes (illustrative)

Alert lead time

Before22 h
After0.0 h

False-positive rate

-0%

LLM rescore layer cuts noise from the rules engine

Daily LLM spend

Provider mix tuned weekly via the ledger dashboard

Coverage

Before12 %
After0 %

The flow

Click any node to inspect it. Traveling dots are live — each colour is one packet path through the pipeline.

streamsuspectwindowpayloadverdictalertalertusageTransactionscard.authorized~42/sRules enginefast-path filterNightly scancron · 02:00 UTCEnrichMongo + historyLLM analyststructured verdictVerdict routeroutput.name == alertEmail alertops@In-app pushSSE + websocketLLM ledgerper-call cost
Click any node
The inspector shows what it does and what edges connect it to the rest of the flow.

The scenario

A rules engine catches known patterns but raises too many false positives, and the SQL job that cleans them up runs nightly. Fraud that happens at 2 AM gets a response at 10 AM.

The flow

Two flows. A hot-path flow subscribes to the transaction stream and sends rules-engine suspects straight to an LLM analyst that scores them against recent history enriched from Mongo. A second, cheaper batch flow sweeps every 5 minutes for anything the hot path dropped.

Cost discipline

Every `redelay/llm-chat` invocation writes to the `llm_calls` ledger with `{provider, model, tokens, latency, cost_usd}`. Finance queries the same collection the alerts are scored from — no separate billing pipeline.

Where the targets come from

Lead time shrinks because the analyst runs per transaction, not per day. The false-positive target assumes the LLM sees the full context (recent transactions, geo, device) that the rules engine never does. LLM spend is expected to trend down as the model mix is tuned from the ledger dashboard.

The stack

  • Hot flow: redelay/event-source(card.authorized) → core/if (rules) → redelay/llm-chat → core/if (verdict) → fan-out
  • Batch flow: redelay/scheduler-cron-trigger → mongoops/find → redelay/llm-chat → same router
  • go-ai/ledger + admin dashboard under /llm/usage