Quick answer: A banknote and coin validator for an MXN self-service kiosk should be disqualified, not shortlisted, on four points: incomplete coverage of current Mexican banknote and coin series; a rejection rate quoted without a stated test method; no escrow or note-to-coin change path; and no documented parts-and-service route inside Mexico. Price only becomes a meaningful comparison after those four are answered in writing.
What disqualifies a validator before price even matters
A banknote and coin validator for an MXN self-service kiosk should be disqualified, not shortlisted, on four points: incomplete coverage of current Mexican banknote and coin series; a rejection rate quoted without a stated test method; no escrow or note-to-coin change path; and no documented parts-and-service route inside Mexico. Price only becomes a meaningful comparison after those four are answered in writing.
Use this page if you are an integrator, kiosk operator or OEM buyer already holding two or three candidate modules and trying to separate them on field risk. It does not restate module specifications — it converts each specification choice into the cost line it creates downstream: false rejects, technician visits and cash-dispute handling.
One condition applies to everything below: first-pass read performance and rejection behaviour change with note condition. Treat every performance claim as unverified until it is tested against your own mixed-condition note pool at sample stage. This page deliberately publishes no acceptance percentages, because a supplier page cannot substantiate them for your circulation mix.
MXN denomination coverage: the first filter
Buyers routinely collapse three different coverage questions into one, then discover the gap after deployment. Separate them in your evaluation:
- Current banknote series. Which series in circulation today does the shipped parameter set recognise, and are older and newer designs of the same denomination both handled?
- Current coin denominations. Coin validation is a separate module with its own parameter set — confirm it is scoped and quoted, not assumed.
- Withdrawn-but-still-circulating notes. Notes that are no longer manufactured can still be presented by customers and still carry value. Your acceptor should either take them or reject them with a defined behaviour, not fail ambiguously.
Banco de México publishes the authoritative reference for this: its banknote and coin exchange service page lists the current value of banknotes and coins no longer manufactured, and states that notes and coins presumed counterfeit can be sent through any bank to Banco de México for analysis free of charge. That matters commercially for two reasons — it is the source you cross-check the vendor’s coverage table against, and it is the escalation channel your operations team can name when a customer disputes a suspected counterfeit rejection at the kiosk. See the Banco de México banknote and coin exchange service .
The update question is where coverage becomes an operating cost. A future series rollout is either a scheduled parameter update your team applies remotely, or an unplanned field failure on the day the new note reaches circulation. Ask for the update mechanism in writing: file format, who supplies it, how it is installed, and whether it requires a technician on site.
Verification step: request the vendor’s written note-and-coin coverage table and check it line by line against the Banxico list on the day of your review, not against a datasheet revision from last year.
Recognition rate vs rejection handling — two specs buyers keep conflating
These are different measurements and only one of them is usually stated.
First-pass read rate describes how often a note is accepted on the first insertion. Rejection handling describes what the kiosk does after a non-read — and that is where field cost lives. A module with a modest first-pass read rate but clean rejection handling is often safer than a module with a strong headline number and no defined retry path.
Demand these behaviours as named, testable states in the spec sheet:
- Retry — the note is returned to the customer for reinsertion, with clear on-screen instruction.
- Transport return — the note is returned to the customer mouth, not held inside the mechanism.
- Final rejection with a visible, customer-readable reason — not a blank screen or generic error.
Cost the false reject honestly. A good note rejected in an unattended site typically becomes an abandoned transaction, a support contact, and in a staffed site a manual override that bypasses your audit trail. Multiply that by site count and you have a more useful comparison than price-per-module.
Sample test protocol: assemble your own notes across condition grades — crisp, average, limp, taped, folded — plus coins in worn condition, and record outcomes per grade per module. Report results as a distribution across grades, never as a single figure. That distribution is what predicts field behaviour.
Anti-counterfeit stack: UV, IR, magnetic, size — which layers you actually need
Name the layers correctly, because each establishes something different and none of them establishes everything:
- Optical / UV: detects fluorescence behaviour and visible print features. Strong on obvious reproductions, weak on higher-quality fakes that reproduce the visible design faithfully.
- Infrared (IR): reads ink reflectance and absorption patterns. Establishes whether ink behaves like the genuine security ink, and can distinguish print processes — but depends on the note being consistent with the sensor’s calibration set.
- Magnetic: reads magnetic thread and magnetic ink characteristics. This is a structural check rather than an appearance check, which makes it harder to defeat with print alone.
- Physical size and thickness: confirms the substrate dimensions. It catches obvious mismatches and multi-note feeding, but on its own it distinguishes nothing about authenticity.
The market framing is familiar: currency-exchange kiosks are commonly described as featuring built-in counterfeit detection alongside vaults and remote monitoring (see SEDCO’s description of 24/7 self-service currency exchange kiosks ). That is positioning, not a benchmark — it tells you the feature is expected in this category, not how well any particular module performs it.
Layer count is not decision quality. The acceptance algorithm and threshold policy decide outcomes: how the sensor readings are weighted, how tolerance is set, and what happens at the boundary. Two modules with identical sensor lists can behave completely differently on a limp genuine note.
Verification step: ask which sensors are physically present and which are actually enabled in the configuration that ships to you. Require that distinction in writing — hardware-present but disabled is a common source of disappointment.
Change and return logic: note-to-coin, escrow and the dispute trail
Escrow-before-commit holds the inserted note in an intermediate position until the transaction is confirmed. If the customer cancels, the note is returned. Immediate-commit accepts the note into the cash path straight away; cancelling then requires the kiosk to issue change or a refund, which introduces a failure point you now own.
For unattended MXN kiosks, escrow-before-commit is generally the lower-risk default, particularly where transaction value is high. Confirm which logic your candidate module supports, and whether it is a configuration setting or fixed behaviour.
Design walkthrough — this is an illustrative flow, not a measured result from a named deployment. A customer inserts a note. The module validates it and holds it in escrow. The customer confirms the transaction. The kiosk issues note-to-coin change from the hopper, commits the note to the vault, and writes an audit-log entry linking the transaction ID, the accepted denomination, the change paid and the timestamps. If the customer cancels before confirmation, the note returns and no log entry is committed. The value of walking your own flow this way is that it exposes every point where change availability, escrow logic and logging must agree.
Now the change path itself. Note in, coin out means the coin denominations you can pay determine whether the transaction completes at all. Two questions decide the architecture:
- Which coin denominations must the hopper pay to cover common price points?
- What is the defined behaviour at hopper exhaustion — decline the transaction upfront, accept and flag for staff, or something else?
The audit trail is not optional. Require a machine-readable export per transaction so a dispute is resolved from a log rather than an operator’s recollection. If your kiosk also takes card payments, keep the cash and card audit records reconcilable — the same discipline applies, as covered in this contactless payment module swap and recertification checklist .
Comparison table: seven criteria to score each shortlisted validator
| Criterion | What to ask the vendor | What a weak answer sounds like | Where to verify it |
|---|---|---|---|
| MXN banknote and coin coverage | Written table of banknote series and coin denominations recognised, per shipped configuration | “Multi-currency, all common denominations” | Cross-check against Banco de México’s current and withdrawn series lists |
| Sensor layers enabled at shipment | Which of UV, IR, magnetic and dimensional checks are active in the delivered parameter set | A sensor list with no statement of enabled state | Configuration file or test report at sample stage |
| Rejection handling states | Retry, return-to-customer, final rejection behaviour and customer-visible messaging | “High acceptance rate” with no rejection path described | Your own note pool across condition grades |
| Escrow / change logic | Escrow-before-commit or immediate-commit; note-to-coin change path; hopper-exhaustion behaviour | “Supports change” without denomination or exhaustion detail | Your own end-to-end transaction walkthrough |
| Audit-log export | Fields captured per transaction and export format | “Logs are stored on the kiosk” | Export a sample log and attempt a dispute reconstruction |
| Serviceable parts and MTTR path in Mexico | Spare-part SKUs, depot or field-service structure, escalation contacts, who bears site-visit cost | A distributor name with no parts or escalation commitment | Written service terms, not a verbal reference |
| MOQ and lead time | Minimum order quantity, sample availability, production lead time, parameter-update turnaround | A lead time quoted without a sample or update commitment | Purchase order terms and sample delivery timeline |
Jams, maintenance and MTTR: the cost line most RFPs miss
Note-path access drives technician time. Ask how the note path is opened and cleaned, whether the cleaning cycle is documented, and whether a site attendant can perform routine clearing without a technician dispatch.
Cash-handling kiosks are commonly supplied with secure vaults and remote monitoring in this category, and that pattern is the operational baseline you should expect: remote visibility of jams and module faults, plus physical security of the cash path. Ask what the monitoring reports and who receives the alert.
RFP ask: a mean-time-to-repair target expressed in hours, the spare-part SKU list you would keep on hand, named escalation contacts, and an explicit statement of who bears the site-visit cost. “Serviceable in Mexico” means a parts and depot plan, not the existence of a distributor.
Where these specs bite in a Mexican deployment
The criteria do not weigh the same across site types. Mall retail and other staffed, high-footfall locations tolerate a jam because an attendant can intervene — but they generate the most cash interactions, so coin hopper capacity and change availability dominate. Ticketing and transport-adjacent self-service runs unattended for longer stretches, where rejection handling and remote fault visibility matter more than hopper size. High-value note flows weight escrow logic heavily, because a mid-transaction cancellation is expensive to reverse.
Tie your shortlist to the transaction value band of the site, not to a single specification ranking. If you are building cash-accepting hardware for retail or mixed public use, review the freestanding cash-handling configuration described here: freestanding cash-handling self-service kiosk . For exchange-oriented flows where note in, coin out is the core transaction, the currency exchange kiosk shows how validation, vault and dispensing are arranged in one enclosure.
Procurement checklist and next step
- Written MXN banknote series and coin denomination coverage table.
- Sensor layers listed by enabled state, not by hardware presence.
- Named rejection handling states and customer-visible messaging.
- Escrow vs immediate-commit identified explicitly.
- Note-to-coin change denominations and hopper-exhaustion behaviour defined.
- Machine-readable per-transaction audit log with export.
- Parameter-update route for future series changes.
- Spare-part SKUs, escalation contacts and site-visit cost ownership.
- MOQ, lead time and sample timeline.
- Agreed sample test protocol using your own mixed-condition note pool.
Be precise about what sample evaluation proves. It validates your note pool against the delivered configuration — it does not prove site-level uptime, technician response, or behaviour under a new banknote series. Those are contractual and service questions, which is why they belong in the RFP rather than the sample report.
Request a quote / sample and the K101CB validation spec sheet and run the test protocol above against your own note mix before you commit to a kiosk order. Ask for the coverage table, the enabled-sensor list and the service terms in the same response, so the comparison stays on one page.
FAQ
Which MXN banknote and coin denominations should a self-service kiosk validator support?
Support should follow the notes and coins actually in circulation in your catchment, including withdrawn-but-still-circulating designs that customers still present. Confirm the vendor’s list against Banco de México’s published current and withdrawn series information on the day you review it, rather than accepting a generic coverage claim.
How do I test a banknote validator’s rejection rate before committing to a kiosk order?
Build a note set that spans condition grades — crisp, average, limp, taped, folded — and run it through the sample module in the same configuration you intend to ship. Record outcomes per grade and treat the distribution as the result. A single aggregate figure from the vendor does not describe your circulation.
What is the difference between a note acceptor and a note recycler in a cash kiosk?
An acceptor validates and moves notes into a vault, issuing change from a separate coin or note hopper. A recycler retains accepted notes and can pay them back out. Recycling reduces change replenishment frequency but adds denomination-tracking and sorting complexity to the cash path.
Can a validator be updated when Banco de México issues a new banknote series?
That depends on the update route, not on the sensor stack. Ask for the parameter file format, who supplies updates, how they are applied, and whether a technician visit is required. If the answer is unclear, treat the module as carrying unplanned field-failure risk for the next series change.
What should a cash-accepting kiosk audit log contain to resolve a customer dispute?
At minimum: transaction ID, timestamp, inserted denomination, validation outcome, escrow decision, change paid by denomination, and final transaction state. The log must be exportable in a machine-readable format so a dispute can be reconstructed without relying on staff recollection or on-screen screenshots.
