Dibein

Anomaly Radar

Catch the transaction that shouldn't be there.

Every transaction is scored against the normal pattern for that vendor, category, and amount. Radar surfaces duplicate payments, subscription creep, and fraud-shaped outliers before month-end close, with a stated reason for every flag.

<2%

false-positive rate on live customer transaction volume

Anomaly detection has a trust problem: most tools flag so much that finance teams learn to ignore the alerts within a month. We built Radar backwards from that failure mode — it was tuned against real customer transaction data specifically to keep the false-positive rate low enough that a flag is worth opening.

It doesn't look for one thing. It runs several models in parallel — duplicate-payment matching, vendor-behavior drift, category-spend outliers, and a lightweight fraud-pattern classifier — and only surfaces an item when it clears a confidence bar, with the specific reason attached.

Nothing is blocked or held. Radar is read-only by design, same as the rest of Dibein: it tells you what looks wrong, in plain language, and links straight to the source transaction in your bank or ledger so you can act on it there.

How it works
01

Score every transaction

As transactions sync, each is compared against the historical pattern for that specific vendor and category — not a generic company-wide threshold.

02

Cross-check for duplicates

Payments are matched on amount, payee, and timing window to catch duplicate invoice payments and double-paid subscriptions before they'd otherwise surface at month-end.

03

Track vendor drift

A vendor whose invoice amount, frequency, or bank details change from their established pattern is flagged, which is the exact shape most vendor-impersonation fraud takes.

04

Explain, don't just flag

Every alert states which model triggered it and why, in a sentence a non-technical reviewer can act on without opening a black box.

Try it

See Radar in action on a sample workspace.

No signup required. This runs on fixed sample data — nothing here touches your own accounts.

July ledger · Solen Studio
10 transactions · demo mode · sample data
Jul 02
Adobe Creative Cloud
Software
-€1,240
Jul 02
WeWork Paris La Défense
Rent
-€8,200
Jul 03
Metrics Cloud Analytics
Software
-€2,150
Jul 04
Atlas Retail — refund
Client refund
+€3,400
Jul 05
Léon Girard (freelance)
Contractors
-€4,800
Jul 08
Structura Print Co.
Vendor payment
-€6,750
Jul 08
Payroll run
Payroll
-€94,600
Jul 09
NovaHost Cloud Infra
Software
-€5,940
Jul 10
Bureau Plus
Office supplies
-€310
Jul 11
Groupama Pro
Insurance
-€1,180
Run the scan to see how Radar scores each transaction and explains every flag.
Capabilities

Duplicate payment detection

Catches the same invoice paid twice, including near-duplicates with a slightly different reference or a split payment that adds up to the original amount.

Subscription creep tracking

Surfaces recurring charges that increased silently, tools nobody uses anymore, and overlapping subscriptions across departments paying for the same category twice.

Vendor-change alerts

Flags a change to a vendor's bank details or a first-time payment at an unusual amount — the two signals most associated with business email compromise fraud.

Category outliers

Highlights spend that's statistically unusual for its category and time of month, tuned per business rather than against an industry-wide benchmark.

One-click resolution

Mark a flag as expected, false-positive, or resolved directly from the alert, which retrains that vendor's baseline going forward.

FAQ
Can Radar stop or reverse a payment?

No. Dibein's bank connections are read-only, deliberately. Radar flags for a human to review and act on inside your bank or ledger; it never holds, blocks, or initiates a transaction.

How is the false-positive rate measured?

Against labeled outcomes from live customer accounts, where a finance user marks each alert resolved, expected, or false-positive. The 2% figure is the trailing-90-day false-positive rate across that labeled set as of this quarter.

Does it need a training period before it's useful?

Category and duplicate-payment detection are active from day one. Vendor-behavior drift needs roughly 3 vendor payment cycles to establish a baseline, so it strengthens over the first one to two months.