Methodology

What is on the site

51 jurisdictions — 50 states and the District of Columbia. Of those, 14 require landlords to pay interest on a security deposit, and the rest do not. Between them the rate rules are described by 37 date-bounded periods.

A verified "no interest required" is as much a result as a yes, and it takes the same work. The 37 pages that say no say it because someone read the statute and confirmed there is no interest provision — not because nothing was found.

Sources

Every legal value comes from a primary source: the state legislature's own publication of its code, a state agency that administers the rule, or the state attorney general's consumer guidance. Each state page shows the section it came from and links to the official text.

Deliberately not used as sources: other deposit calculators, law-firm marketing blogs, encyclopedias, and AI-generated summaries. Those are frequently out of date and, more importantly, they are unverifiable — you cannot tell which statute a blog post was reading or when.

How a value gets onto the site

There is exactly one path, and it is worth describing because it is the whole reason to trust the numbers.

1. The rule is read from the statute and recorded in a single spreadsheet, one row per state, with the citation and the date it was checked.
2. A script regenerates the site's data file from that spreadsheet. Nothing is typed into the data file directly — it carries a do-not-edit header, and a hand edit would be silently overwritten the next time the script ran.
3. The site's pages are built from that data file. No page contains a rate, a threshold or a deadline written into its own source.

The practical effect is that a legal value can only enter the site through the sourced record. There is no back door and no override table.

The two checks

Both run automatically on every change, and a failure blocks the change.

Regeneration check

The data file is rebuilt from the spreadsheet and compared byte for byte with the one committed. If they differ, either someone hand-edited the data or someone changed the spreadsheet and forgot to regenerate. Both are caught.

Round-trip check

This one matters more, and it exists because the first check has a blind spot. The regeneration check only proves the data file is what the script currently produces — if the script itself has a bug that transforms a value consistently, it produces the same wrong bytes every time and the comparison stays clean forever.

So a second program reads the spreadsheet with its own independent parser, evaluates the published data, and compares all 1,562 values field by field. It passes only on zero mismatches. That approach was tested by deliberately introducing exactly the kind of quiet corruption described above: the regeneration check passed, and the round-trip check failed and named the three affected cells.

The calculation engine

The arithmetic is a separate concern from the data, and is covered by its own tests — written before the engine itself, with every expected figure worked out by hand from the statute rather than produced by running the code. Each test is named for the state whose real rule forces it, so a failure points at a rule rather than at a fixture.

The tests run against the live dataset, not against fixtures, so the data and the engine cannot drift apart without something going red.

When the answer is "we don't know"

Two situations produce no figure, on purpose.

No published rate. 9 of the 14 interest states tie the rate to whatever the account holding the deposit actually earned. No table of those rates exists anywhere, because the number depends on the individual landlord's bank. The result gives the accrual period and tells the tenant what to request, instead of substituting a plausible market rate.

An unsettled statute. Where a state's text supports two readings that produce different amounts and no court has resolved it, the result says so. This is recorded as a property of the rule in the source record, not decided case by case.

Update cadence

Several states reset their rate annually, and the data structure is built so that a new year's rate is one new row rather than a code change. Those are checked at the start of each calendar year.

Everything else is re-checked opportunistically: when a reader reports a change, when a linked source moves, and in a full pass at least annually. Every state page carries its own last-verified date rather than a single site-wide one, so you can see the age of the specific rule you are relying on.

Known gaps

• City ordinances are not covered yet. Several cities set their own deposit interest rules that supersede the state rule. Those pages do not exist, and until they do a tenant in one of those cities should check the local ordinance.
• Deposit caps are not held as structured data. Most state summaries describe the cap in prose, but there is no column for it, so no comparison table is published. The guide on caps explains the mechanics instead.

If you find something wrong, please say so. A correction to the source record propagates to every page built from it.