Part 6 of 6 · Biometric Identity Programme Series — previous: Managing a Fleet of Identity Terminals

Biometric Terminal RFP: The Specs That Matter

By Xinhong Smart Engineering Team · Published 31 October 2026

Quick answer: An identity tender fails when it lists adjectives instead of measurable acceptances. The specifications that decide the outcome are the capture class, the platen dimensions, the minimum quality score, the document chip protocols if documents are involved, the matching and deduplication interface, the data flow and deletion rules, the fleet management process, and the spare and support lead times. Write those eight, state who measures each one, and say what happens when a number is missed.

Most RFPs in this field describe a device. The ones that succeed describe a measurement instead, and let suppliers compete on how they meet it.

1. Capture class, stated as a requirement

Name the class the programme needs: PIV/FAP-class single-finger devices for supervised 1:1 verification, or Appendix F hardware where records are exchanged with an AFIS. Saying "FBI certified" without the class invites a quotation for the wrong product, and the difference is not visible from the datasheet.

2. Platen dimensions and the population

Give the platen in millimetres and describe who will be enrolled. A larger platen tolerates misplacement and larger fingers; a smaller one keeps the device light. This is a decision about your population, not about the sensor.

3. Quality floor and the behaviour below it

State the minimum quality score, name its scale (NFIQ 2.0, or the module score with its equivalent), and say what the workflow does below it: block, prompt, or flag. A floor that is recorded but not enforced moves the failure downstream to deduplication.

4. Document chip protocols, if documents are read

List the protocols the programme requires: Passive Authentication, BAC or PACE, Chip Authentication, Terminal Authentication where the protected groups are read. Require the supplier to state which the build performs and to demonstrate them on your sample documents.

5. Matching and deduplication interface

Say what the terminal must hand over: record format, quality score, retry log, and the interface to the ABIS your programme uses. If deduplication is in scope, state the pre-filter and the candidate list size, and ask how borderline cases are adjudicated.

6. Data flow, retention and deletion

Require a data flow diagram with the tender: what the device stores, for how long, encrypted how, deleted when. Include the behaviour of a remote wipe on unsent records. This section is where most bids are vague, and vagueness here is expensive later.

7. Fleet management and version control

State the enrolment method, the managed configuration, the certificate renewal process and the version-pinning rule. Ask the supplier to name the firmware and application versions being quoted and what happens when a change is needed.

8. Spares, lead time and support

Build and dispatch time, spare-part lead time, repair turnaround, and who answers when a district calls. Ask for the numbers in writing; "fast" is not a commitment.

The acceptance test that makes the rest enforceable

Close with a measurement: a stated number of people, a stated number of attempts, stated lighting and environmental conditions, and the numbers each specification has to reach. Two pilot units before the order, tested against your own population, settle arguments about adjectives before there are hundreds of devices in the field.

What Xinhong does with an RFP like this

We answer each of the eight in writing, including the ones we cannot meet, and we quote the firmware version we will ship. Where a requirement depends on a certificate we do not hold, we say so instead of implying compliance. Two units can be built and dispatched before the order and tested against your acceptance script.

Frequently asked questions

Should we specify a brand of fingerprint module?

Specify the class and the performance you need, and name preferred modules only where an existing backend requires them. Naming one module can exclude a build that meets every measurable requirement, while naming none lets a bid substitute a weaker part.

How many units should we pilot?

Two is the usual starting point: one for capture testing against your own population and one for the SDK and integration bench. More is useful when the pilot covers several districts with different conditions.

Is it fair to require an acceptance test before the order?

Yes, and it is the single clause that changes supplier behaviour. A test written before the order is designed around; one written after is argued about. Ask for the results to be recorded per requirement, on the firmware version that will ship.

What if no bid meets every specification?

That is useful information, not a failure. Rank the requirements by what breaks the programme if missed, and say so in the tender, so both you and the bidders know which ones are negotiable and which are not.

Should the RFP fix the operating system version?

Fix the version that was tested, and require notice plus a re-test before any change. An unannounced OS or application update during an enrolment drive is one of the few failure modes that can stop every district at once.