Your anomalies board shows a spike in failed payments from one consumer. Finance sees overdue invoices piling up for another. SRE notices an error flood from a single IP range.
Each finding is real. Each has evidence attached. But none of them, by themselves, answer the question an operator actually asks:
“Is this one bad actor, a broken integration, or a customer having a bad week — and what should we do next?”
That gap between detection and investigation is what Finno’s abuse investigation workflow closes.
Anomalies and investigation cases are related — but not the same tool
Anomaly detection scans your ledger, payments, settlements, and gateway telemetry in the background. When something crosses a rule — ledger imbalance, settlement failure, credit near limit, and dozens of others — Finno opens a finding ranked by money at risk.
That is excellent for “something in the books or the pipeline looks wrong.”
Abuse investigation management takes a step further. It groups signals (from anomalies and from dedicated rules) into review cases tied to a subject — often a consumer or a pattern — with a score, a severity tier, an audit history, and a place for a human decision.
Think of it this way:
- Anomaly: “Payment failures for consumer 8842 exceeded threshold this hour.”
- Investigation case: “Consumer 8842 — medium severity — three correlated signals — review recommended — last seen 12 minutes ago.”
You still need people to judge. The case gives them a desk to work at, not a scattered list of alerts.
What you can use today
Finno ships Phases 1–3 of revenue abuse detection and investigation in the dashboard today:
- A cases board where operators open, review, escalate, and close episodes.
- Signals attached to each case — where they came from (an anomaly id, a payment row, a deposit pattern), with deduplication so the same evidence is not copied ten times.
- An audit trail of case events — when severity changed, when someone overrode a suggested decision, when a case was resolved.
- A background worker that runs on its own schedule (like the anomaly loop), under leader election, so only one dashboard instance drives the sync at a time.
Important honesty for buyers: automatic blocking on the API hot path is not the default. Gateway “observe mode” exists for future enforcement work, but today the product value is investigation and alerting, not silently cutting off customers mid-request.
That is intentional. Billing infrastructure should not freeze traffic because a batch job had a hunch.
Where the signals come from
Every few minutes, the abuse-investigation worker does two kinds of work.
First, it reads selected open anomaly findings — the ones you already trust enough to show on the live board (not shadow-mode statistical experiments). Examples include repeated payment failures, dangerous credit exposure, or error floods from one source.
Second, it runs nearline rules written directly against your operational tables: deposits that look like test-then-drain patterns, bursts of service requests inconsistent with history, payment proofs that do not match what the ledger expected, and similar checks that do not need a full anomaly episode to fire.
Each hit becomes a risk signal. Signals roll up into investigation cases by subject. Severity can increase when new signals arrive; operators can override a suggested decision once, and the system remembers that a human took ownership.
One especially sensitive path is PSP proof mismatch — when what the payment provider confirms does not match what Finno intended to charge. That surfaces quickly because it is exactly the kind of issue where waiting until month-end is unacceptable.
A day in the life ( fictional but realistic )
Monday 09:14 — Anomaly detector payment_failures opens a finding: consumer “Nimbus Labs,” $2,400 at risk, four failed wallet top-ups in twenty minutes.
Monday 09:19 — The investigation worker attaches a signal to case FC-2026-0412, severity review. No auto-block. Nimbus’s API traffic continues.
Monday 09:47 — Finance opens the case, sees the anomaly evidence JSON, notices the same consumer increased credit limit last week. They escalate to high and leave a note.
Monday 10:02 — Notification channel posts to Slack #billing-ops because the case crossed the configured threshold.
Tuesday — After speaking with Nimbus, finance closes the case as “integration misconfiguration on their staging key.” The audit trail remains for next quarter’s audit.
Nothing in that story required editing production configs under pressure or grep-ing logs. The case was the workspace.
How this fits with anomalies and notifications
You do not pick one system and disable the other.
| If you need… | Use… |
|---|---|
| Continuous integrity checks on books and pipeline | Anomaly detectors |
| A place to investigate a subject with history | Abuse investigation cases |
| To ping the on-call channel when something opens or escalates | Notification channels |
Channels can fire on fraud.opened and fraud.escalated separately from anomaly events, with cooldowns so one flaky hour does not spam fifty messages.
What is still on the roadmap
Later phases may add stronger enforcement — precomputed risk flags consulted on the hot path, always within strict latency bounds. Machine-learning or vendor scores may arrive as inputs to cases, not as opaque autoblocks.
Until then, we describe the product accurately: strong detection, structured investigation, human decision.
If you want to see the cases board and how it sits next to anomalies, start at Revenue assurance on the features page or book a walkthrough.