Self-Service Kiosk RFP Procurement Checklist (2026)

Overview

A bank kiosk tender becomes comparable the moment it names five things in writing: a use-case baseline with volumes and cash-flow direction, specifications split into mandatory and optional, certification requirements stated as verifiable evidence, itemized pricing lines on a locked template, and acceptance criteria defined before award. Leave interface, certification or acceptance wording vague and the evaluation inevitably collapses to lowest total price — not because the committee is lazy, but because nothing else in the bids can be placed side by side. This page runs through a self-service kiosk RFP procurement checklist line by line, and each line is framed as the mechanism that either preserves or destroys bid comparability. Treat it as a self-service kiosk RFP template you lift section by section into your own document.

Step 1: Fix the requirement baseline before any hardware is named

Describe the transaction, not the box. A tender that opens with “supply self-service kiosks” invites each vendor to imagine a different machine, and every downstream price becomes non-comparable. State transaction types, peak-hour volume, typical session length, and explicitly whether cash is accepted, deposited or recycled — each of these changes the peripheral set that gets quoted.

• Pin a physical envelope constraint: footprint, counter or floor-stand, and the clear-floor allowance your branch design requires. Without it, vendors optimize to different form factors and return prices for different products.
• Require a use-case narrative covering at least one branch scenario per transaction type, so evaluators score fit rather than spec-sheet length.
• Do not omit volumes. A baseline without transaction volumes and cash-flow direction is the most common trigger for mid-evaluation scope changes, which reset the clock and invalidate the comparison you have already built.

Step 2: Split the kiosk specification for tender into mandatory and optional

Publish two separate tables. In the first, list only items that break acceptance if absent: enclosure and mounting, display size and touch technology, card reader approval level, cash module capability, receipt printing, and power/network provisioning. In the second, list optional rows with a price column, so a vendor’s add-on can be lifted in or out without rewriting the bid.

Optional rows carry the differentiators that drive branch-level upside — biometric or ID scanners, barcode scanning, a second screen, UPS, remote monitoring agents. A single undifferentiated list lets vendors pad mandatory scope with optional hardware and inflate the apparent base price, which is exactly how a comparable tender turns into an apples-to-oranges one.

Step 3: Require certification evidence, not certification claims

Every certification line in a kiosk procurement checklist should specify the evidence artifact, not the certificate’s nickname. For card acceptance, require the EMV Level 1 and Level 2 approval status per reader model, verifiable against EMVCo’s published approval listings at emvco.com. For cash-accepting kiosks, require a written statement of where the payment path sits inside or outside the vendor’s PCI DSS scope, checked against the standards published by the PCI Security Standards Council at pcisecuritystandards.org.

• For electrical and wireless compliance, require the certificate number, the issuing laboratory and the test standard version for the market of deployment — a market-by-market approach covered in more depth in our guide to verifying CE, FCC, RoHS and ISO 9001 line by line .
• State in the RFP that a claim of “CE certified” or “PCI compliant” without a certificate number and issuing body is not an evaluable response and scores as non-compliant.
• Remember that a framework document is not a product-level approval. A vendor citing a standard has not thereby proven the specific model complies with it.

Step 4: Pin down interfaces and SDK so integration quotes line up

Integration effort is the largest hidden variable in bank kiosk bids, so make it a written deliverable. Require the vendor to name which host interfaces are exposed — network API, serial, USB HID, GPIO — and at what documentation level.

• Ask for the supported OS baseline, the security patch cadence commitment, and who owns firmware and application updates over the service life. Update ownership that goes unstated resurfaces as lifecycle cost, a topic examined in Android kiosk hardening and update ownership .
• Require a written statement on whether an SDK is included, licensed or chargeable, and under what redistribution terms.
• Require a response on downtime reporting, error-code exposure and remote diagnostics, so operations teams score supportability instead of assuming it.

Step 5: Write kiosk acceptance criteria that a factory test can satisfy

Define acceptance as observable conditions per unit: a named transaction set completed end to end, a defined cash-acceptance and dispensing cycle count, and a defined print and card-read pass condition. Attach an acceptance-test record format to the RFP so every vendor returns the same evidence shape.

Specify sample-unit or pilot obligations before mass production, including who pays freight, who bears rework on failure, and what constitutes a failed pilot. Acceptance criteria written after award are effectively unenforceable, which is why these kiosk acceptance criteria belong inside the tender document, not in a post-award quality plan.

Step 6: Make service, spares and SLA a priced line, not an appendix

Require response and restore commitments as separately priced tiers — for example next-business-day versus four-hour — with the included spare-parts pool named, rather than one opaque “support” line. Ask for the field-replaceable unit list with part numbers and the stated spare availability window for the committed service life.

• Require disclosure of where spares are held and the shipping terms governing replenishment, so service cost compares fairly across vendors quoting from different regions.
• Require explicit warranty exclusions, consumable definitions and wear-part lists. An undefined consumable is a recurring unbudgeted cost.
• Treat vendor lead-time claims as unverified ranges until they are contractually fixed with named dependencies.

Step 7: Standardize the line-item pricing table so totals are comparable

Supply the pricing table as a locked template with fixed rows: unit hardware, payment module, cash module, software license, integration, freight, installation, training, and service tier.

A kiosk procurement checklist without a locked pricing template re-introduces the exact non-comparability the rest of the tender was designed to remove. For how peripheral, integration and service choices change bank kiosk TCO after quotes arrive, see the post-quote TCO comparison method .

Step 8: Set evaluation weights before responses arrive

Publish scoring weights inside the RFP itself, covering technical compliance, certification evidence, integration fit, service model, total cost and past performance. Give mandatory compliance a pass/fail gate rather than a scored line — a non-compliant bid should never be rescued by a low price. Weight total cost on the normalized priced template, not the headline unit price; that single choice is the mechanism that resists lowest-total-price selection. Reserve a defined clarification round so missing certificate numbers or interface statements are resolved in writing and on the record.

Step 9: Fix contract, delivery and Incoterms terms in the tender

Name the Incoterm and its edition, referencing the ICC’s published Incoterms 2020 at iccwbo.org, so responsibility for freight, insurance and duty is unambiguous. Require the vendor to state the customs classification approach and country of origin, with reference to the World Customs Organization’s harmonized system materials at wcoomd.org, because classification drives landed cost.

Ask for lead time as a band with stated dependencies on payment milestones, sample approval and component availability. Require acceptance, payment and remedy clauses to reference the same acceptance criteria defined earlier in the tender.

What cannot be verified from a datasheet

Some tender items are answered only by physical verification, and saying so in the RFP protects the evaluation. Factory process control, actual build quality, cash-module behaviour across a real note mix, and the reliability of a stated service footprint all require a factory audit, sample testing or a reference visit. Bank branch pilots typically run on sample units through a scripted transaction set before production release, with results signed off against the acceptance record. Write that sequence into your kiosk tender requirements and require vendors to accept it, rather than letting each bidder define its own proof standard.

Frequently asked questions from bank tender teams

What should be included in a self-service kiosk RFP?

Include nine blocks: a use-case and volume baseline, mandatory and optional specification tables, certification evidence requirements, interface and SDK disclosure, acceptance criteria and test record format, priced service and spares tiers, a locked line-item pricing template, published evaluation weights, and contract, delivery and Incoterms terms. Each block exists to keep returned bids comparable.

How long does a kiosk procurement process usually take?

Plan in phases rather than a single date: specification drafting, clarification rounds, sample evaluation and acceptance testing before mass production. Because duration depends on how many clarification rounds your specification triggers, publish milestone dates rather than promising a total, and treat vendor production lead-time claims as ranges until they are contractually fixed.

Do cash-accepting kiosks need to be PCI DSS compliant, and who proves it?

PCI DSS applies to the payment path handling account data, and responsibility depends on where the module sits inside or outside your acquirer’s scope. Require the vendor to state the scope boundary in writing, and verify any compliance statement against the standards published by the PCI Security Standards Council rather than accepting the label alone.

Who owns kiosk software and firmware updates after deployment?

Ownership must be stated per layer — OS baseline, firmware, application and security patches — with a named party, a cadence commitment and the cost treatment for each. Unclear update ownership becomes a recurring lifecycle cost and a security exposure, so make it a scored, written response in the tender.

How do you compare kiosk vendor quotes when the specifications differ between bidders?

Normalize before you compare: map every bid onto your mandatory table, treat unlabelled certification claims as non-compliant, price only the locked rows, and place vendor-chosen extras in a separate optional table. The comparison is valid only where the specification was identical to begin with.

Get your draft RFP specification quoted and sampled

If you already have a draft specification, the fastest way to test whether it is genuinely comparable is to send it to a manufacturer and see which lines come back unanswered. Ask us to request a quote, sample and datasheet against your draft RFP specification for a cash-handling self-service kiosk configuration, and we will tell you plainly which items we can answer from documentation — interfaces, module configurations, certification evidence — and which need sample testing, a pilot run or a factory audit before any number is fixed.