Anomaly Detection
Techniques that identify patterns deviating from expected behavior, unusual logins, odd transaction shapes, abnormal usage, so humans can investigate before small oddities become incidents.
Why it matters
Rules catch what you predicted; anomalies are what you did not. It matters because fraud, abuse, and failures usually announce themselves first as statistical weirdness: an approval at 3 a.m., a branch's expenses doubling, a user suddenly exporting everything. Catching deviation early converts incidents into questions.
How it works
Baselines are learned from historical behavior (per user, branch, or system), then live activity is scored against them, statistically (thresholds, distributions) or with machine learning for complex patterns. Good systems route scored anomalies to humans with context, tune to keep false positives tolerable, and feed confirmed outcomes back to improve the model.
A real-world example
An expense platform learns each branch's rhythm. One branch's fuel vouchers spike far beyond baseline in a week; the system flags it with the comparison attached. The review takes minutes: either a legitimate campaign explains it, or a conversation begins, weeks earlier than a quarterly audit would have noticed.
Common mistakes
- ✗ Alerting on everything, training humans to ignore the channel
- ✗ Static thresholds forever, businesses drift and baselines must follow
- ✗ Anomaly scores without context, flags nobody can act on
- ✗ Using detection as the only defence instead of a layer atop controls and logs
Best practices
- ✓ Baseline per entity (user, branch, tenant), not one global average
- ✓ Deliver anomalies with the evidence that made them anomalous
- ✓ Tune alert volume to what reviewers can genuinely investigate
- ✓ Close the loop: confirmed outcomes retrain the detector
Frequently asked questions
Do small businesses need anomaly detection?
At small scale, simple per-entity baselines and review of outliers already deliver most of the value, sophistication can grow with data volume.
Machine learning or rules?
Both: rules for known-bad patterns, statistical or learned baselines for the unknown. Rules are explainable; learning finds what rules cannot enumerate.
What data does it need?
Reliable event history, which is why immutable audit logs come first. Detection is only as good as the record it studies.
AEGIBIT's platforms are built log-first, the foundation anomaly detection needs, with per-branch visibility that makes deviations obvious early.
AEGIBIT's security engineering →Related concepts