Seasonality and the Business Calendar

Organisational behaviour is periodic. Month-end, quarter-end, payroll runs, audit periods, product releases, holidays. A model treating all days as exchangeable will flag every one of them, forever.

The cycles that matter

Daily. Working hours, lunch, batch windows overnight. The most commonly modelled and the most fragile for distributed workforces.

Weekly. Weekends, Monday backlogs, Friday deployments or deployment freezes. A weekday feature is cheap and eliminates a large class of noise.

Monthly. Finance close, invoicing, reporting, payroll. Sharp, predictable spikes in specific systems by specific roles.

Quarterly. Board reporting, tax filings, contract renewals, sales quarter-end. A ninety-day baseline barely contains one instance, which means quarterly patterns are almost never learned.

Annual. Audit, budgeting, open enrolment, year-end. Effectively invisible to any practical baseline window.

Irregular but scheduled. Product launches, migrations, mergers, layoffs. Not periodic, and knowable in advance.

Approaches

Explicit calendar features. Day of week, day of month, business-day index, is-holiday. Cheap, interpretable, and they resolve most weekly and monthly noise. The best value per unit of effort in this area.

Separate baselines per period. A distinct model for month-end for the finance population. More precise and more data-hungry.

Decomposition. Separate the series into trend, seasonal and residual components, and score the residual. Statistically sound, requires enough history to estimate the seasonal component, and therefore unavailable for annual cycles in practice.

Suppression windows. Simply do not alert on the finance population during close. Blunt, effective, and it creates a predictable window an attacker could use. Prefer raising the threshold to disabling detection.

Holidays

An underrated source of recurring noise.

A global organisation has holidays on different days in different countries. A model without holiday awareness sees a country's activity drop to nothing and treats it as anomalous, then sees it return and treats that as anomalous too.

Maintain a holiday calendar per country and attach it as a feature. This is a small data set, easily obtained, and it removes a predictable annual noise pattern.

The inverse is a genuine signal: activity from an entity during their own national holiday, when their entire peer group is absent, is worth a look.

The organisational events nobody encodes

Some of the largest behavioural shifts are known in advance and never fed to the model.

Migrations. Everyone starts using a new system on the same day.

Reorganisations. Peer groups invalidate wholesale.

Layoffs and redundancy programmes. Departure-related behaviour rises across a population, and the risk genuinely rises with it — this is the one case where the noise and the signal coincide, and suppression is exactly the wrong response.

Office closures and return mandates. Location and hour features shift for everyone.

Incident response. A major incident produces enormous legitimate anomalous activity by responders.

The practical measure: a simple mechanism for security to record known events with dates and affected populations, consulted during triage. A shared calendar is enough. It is astonishing how often an analyst spends an hour on an anomaly that a colleague could have explained in a sentence.

Detecting the loss of periodicity

Worth stating because it inverts the usual framing.

A service account that runs every night at 02:00 and stops is anomalous by absence. A finance system that shows no month-end spike may indicate that the process ran somewhere else.

Most implementations detect activity, not its absence. Absence detection requires modelling the expected periodicity explicitly, and it catches a class of events — disabled logging, redirected processes, disrupted jobs — that nothing else does.

Building a business calendar

A small piece of reference data that removes a large amount of recurring noise.

Public holidays per country you operate in. Freely available, changes annually.

Your own closure days and reduced-service periods.

Financial calendar: month-end close, quarter-end, year-end, audit windows, budget cycles.

Operational calendar: release windows, freeze periods, maintenance weekends, scheduled migrations.

Known projects with dates and affected populations.

Incident periods, recorded as they happen, so that later analysis can exclude them.

Attach these as features where the model can use them, and expose them to analysts during triage. The second use is worth as much as the first: an analyst who can see that today is quarter-end resolves a finance anomaly in seconds.

Common false positives

Calendar-driven noise, all of it predictable in advance:

Month-end and quarter-end volume in finance, reporting and sales roles.

Holiday absence producing zero activity that reads as anomalous, followed by return activity that reads as a spike.

Deployment freezes ending, with a burst of accumulated change.

Audit periods, where auditors legitimately access broadly and unusually.

Annual compliance exercises that recur outside a ninety-day baseline and therefore look novel every year.

Seasonal business cycles — retail peaks, academic terms, tax season — that dominate an industry's whole workforce simultaneously.

Blind spots and assumptions

That the baseline window covers the cycle. Ninety days does not cover quarterly or annual patterns, and never will.

That periodicity is stable. Business calendars change.

That suppression is free. Every suppression window is a period of reduced detection, and a predictable one.

That the model learned it. Without an explicit feature, a model may have averaged the cycle into the baseline rather than learning it — which widens the baseline and reduces sensitivity for the rest of the month.