Closed-loop ticketing — transit-grade architecture, end to end.
A reference for everyone designing, procuring, or operating a closed-loop fare-collection deployment. This page is a knowledge center: card platform, validator architecture, SAM custody, fare logic, anti-fraud, settlement, and the operational realities that decide whether a deployment ships or stalls.
What “closed-loop” means here
A closed-loop fare system is one where the issuer, the cards, the validators, and the back office are all under the same operator’s control. The card is not a Visa or Mastercard; it is the operator’s own credential. Fare logic, security policy, and settlement happen entirely inside the operator’s systems.
Open-loop systems — where you tap a contactless bank card — are a different problem domain (PCI scope, EMV terminal certification, online authorisation). Most metros, light rail, BRT, and city-pass deployments worldwide are still closed-loop, with open-loop as a parallel acceptance lane. This page is about the closed-loop side.
Reference architecture — layered view
Card platforms in production today
| Platform | Where it fits | Notes |
|---|---|---|
| DESFire EV2 / EV3 | The default for closed-loop transit since the late 2010s. | Diversified keys, EV2 secure messaging, transaction MAC. Mature SAM ecosystem. |
| MIFARE Plus EV1 / EV2 | Step up from MIFARE Classic for legacy estates that need AES. | Useful for upgrading installed-base; not first-choice for greenfield. |
| JavaCard applet | When the issuer needs custom card-side logic beyond DESFire’s file model. | Higher cost per card; full control. Ambimat ships JavaCard applet platforms. |
| NFC phone (HCE) | Mobile credentials, especially in megacities with smartphone-first riders. | Combine with secure-element-backed credential or attestation. Online-leaning. |
| QR / aztec on paper | One-shot tickets, tourist day-passes. | Signed by issuer. Validator verifies signature; no card crypto. |
Tap-to-decision — what fits in 300 ms
The hardest non-negotiable in transit fare collection is latency. Riders queue up; the gate opens or it doesn’t. Industry practice puts tap-to-decision under 300 ms end-to-end — sometimes 250 ms for high-throughput metros. That budget has to cover RF activation, anti-collision, application select, mutual authentication, fare logic, audit write, and gate actuation. Every layer steals from the budget. The architecture below is what we routinely fit inside it.
Anti-fraud surface, in one view
Diversified keys per card
Cloning one card teaches the attacker about that one card. The rest of the system is unaffected.
Transaction MAC (TMAC)
Every commit produces a SAM-signed receipt the issuer verifies after the fact, even hours later.
Anti-passback windows
The validator (and the back office) reject obvious double-uses inside a configurable window.
Blacklist propagation
Lost / refunded / refunded-and-blocked cards reach validators within the depot-sync cadence.
Stored-value bounds
Per-card and per-day debit limits cap the loss from a single compromise.
Audit reconciliation
Back office reconciles SAM-signed receipts against debited values; gaps flagged within 24 h.
Stored value — protections
If the card carries stored value (a balance, a trip count, a season-ticket window), the protections layered on top are:
- EV2 secure messaging on every read and write.
- Backup files for atomic update — a half-completed debit is rolled back at the next clean read.
- Transaction MAC on every commit so the issuer can reconstruct what the card believed at the time.
- Anti-tearing counters — if the card is lifted off the field mid-transaction, the next validator detects the inconsistency.
- Per-card & per-day debit caps so a single compromise has a bounded loss profile.
- Recharge happens only at attended kiosks or via signed back-office flows — a validator never increases stored value in the field on its own authority.
Connectivity — what works offline
| Operation | Online? | Notes |
|---|---|---|
| Mutual authentication & tap | OFFLINE | Card and SAM hold all the keys needed. |
| Stored-value debit | OFFLINE | Atomicity via DESFire backup files; receipt buffered locally. |
| Blacklist enforcement | OFFLINE (cached) | Validators carry the blacklist; depot sync refreshes it. |
| Stored-value top-up | ONLINE preferred | Or attended kiosk with its own SAM authority. |
| Card issuance / replacement | ONLINE | Issuer KMS in the loop. |
| Settlement & audit | ASYNC | Batched at end of shift; back office reconciles. |
Fail-safe vs fail-secure
When something goes wrong — SAM not responding, blacklist out of date, fare-config corrupt — the validator must decide: fail-safe (let the rider through) or fail-secure (refuse all taps). The right answer is operator policy, not a technical default. Most metros choose fail-safe with degraded-mode logging during peak and fail-secure during off-peak when manual intervention is available. Buses tend to fail-safe with audit trails. Inspectors’ handhelds tend to fail-secure (refuse to validate without a working SAM).
Whatever you choose, make it explicit in the firmware, log every fall-through, and reconcile in the back office. Silent failure is not an option in transit security.
Procuring or designing closed-loop?
From SAM personalisation to validator firmware to back-office reconciliation, we ship the chain. Most engagements start as “we need something like X but with Y” — tell us about Y.