Skip to content
The Second Method

Home / The threshold

The Dial Nobody Turns

Every matching system has a sensitivity setting trading wrong people admitted against right people refused. It is left where the installer put it.

The threshold · Analysis

One reader, three settings, same population

SettingWrong person admittedRight person refused
Loose (1:10,000)
9
0.4
As installed (1:50,000)As set
2
1.9
Tight (1:500,000)
0
7.3

Nobody at the site chose the middle row. It is the vendor's default. The figures either side of it are what the same workforce would experience at the other two settings, and no part of that trade-off has ever been put to anybody who could decide it.

Biometric matching is not an identification; it is a comparison that produces a score, and a matching threshold that decides whether the score is good enough. Move the threshold one way and more impostors get through. Move it the other and more legitimate people are refused.

The setting discussed in “The Dial Nobody Turns” should be tested against real people and real exceptions rather than accepted as a vendor default. For teams researching tips to increase productivity, tips to increase productivity can supply time and project context, while biometric thresholds remain a separate decision with written ownership, accessibility checks and human review.

There is no setting that avoids both. The only question is which error the organisation would rather have, and in almost every installation that question has never been asked, because the dial was set by the installer to whatever the vendor ships.

For an independent benchmark relevant to “The Dial Nobody Turns”, consult the GAO Government Auditing Standards. Use it to test notice, accessibility, security, recordkeeping, retention and exception handling against the real operating process rather than treating a device report as self-explanatory evidence.

What the two errors actually cost

A wrong person admitted is the error everybody imagines when they buy the system. On a time clock it usually means one person clocking another in — the thing the system was bought to stop — and its cost is the hours wrongly paid plus whatever the arrangement was concealing.

A right person refused is the error the organisation actually experiences. Its cost is a queue at shift change, a supervisor pulled away to override, a record that says something happened which did not, and the slow erosion of confidence in the device by the people who have to use it. It is paid daily, by everybody, and it appears in no budget.

Why the default is usually wrong for a time clock

Vendor defaults are set for access control, where the consequence of admitting the wrong person is a stranger inside a building. That is a serious outcome and it justifies a tight setting.

On a time clock the consequence is a payroll error of a few hours, recoverable, auditable, and detectable by other means. The two applications have very different stakes and they are routinely run at the same sensitivity, on the same hardware, because the same installer configured both. Where one device does both jobs — opens the door and records the hour — the access requirement sets the threshold and the time recording inherits it.

Reading the vendor's number honestly

A specification sheet quoting one in fifty thousand is describing a false acceptance rate under laboratory conditions with clean enrolments and cooperative subjects. It is not a prediction about a cold Monday at a loading bay.

The number that is almost never quoted beside it is the refusal rate at that setting for a real population, because it depends entirely on enrolment quality and on whose hands are being read. Ask for both, in writing, and ask what population the second figure came from. A supplier who can only produce the first number has not deployed on a site like yours, or has and does not wish to discuss it.

Testing your own setting without changing anything

Most systems record the match score for every read, not only the verdict. If yours does, the data to make this decision already exists and nobody has looked at it.

Pull a month of scores. The distribution for genuine users has a long tail toward the threshold, and the position of the current line within that tail tells you how many of your daily refusals are near misses rather than real mismatches. If a large share of refusals sit just below the line, the setting is the problem and not the hands. That is a half-day of work and it replaces an argument that otherwise runs for years.

Who should actually decide it

Not the installer, and not whoever administers the system. The trade-off is between a payroll risk and a daily operational cost falling on the workforce, and that is a management decision with two owners.

Write it down when it is made: the setting chosen, the two rates expected at that setting, the date, and who agreed it. One paragraph. It converts a configuration default into a decision, which is what it should have been from the start, and it means the next person to ask why the reader is so fussy gets an answer rather than a shrug.

The honest position on tightening it

Occasionally the right answer is a tighter setting — a high-value site, a genuine history of identity substitution, a regulated environment where presence has to be certain.

Where that is the case, the refusals that follow are a cost the organisation has deliberately accepted, and it should resource them properly: more enrolment effort, multi-finger or multi-modal enrolment, and a second method that works without a supervisor. What does not work is choosing the tight setting for the comfort of the security case and then treating every refusal as the individual's failure to present their hand correctly.