Security and trust
Built so your fares,
your riders, and your data stay yours.
Every layer of mobl.city -- the card, the reader, the dashboard, the payment hardware, the field device -- is designed against a clear set of threats. Here is what we do and why.
Cards
How we protect cards.
Mutual authentication on every tap
AES-128 DESFire EV2/EV3 mutual authentication between the reader and the card. Every card carries its own per-card key, derived from a fleet master at provisioning time, so a stolen card never compromises the rest of the fleet.
Replay protection via rolling nonce
Every mobl.city closed-loop card carries a rolling nonce that the server checks on each tap, so previously captured card traffic can't be replayed to spend the same value twice.
Nothing valuable lives on the card
The rider's balance is held in their mobl.city account, not on the card. A lost card can be deactivated immediately from the dashboard or the rider's app; the balance moves to the replacement card with no loss.
Operators
How we protect operator accounts.
Multi-factor authentication
Multi-factor authentication is required on every administrator account. New users enrol a TOTP authenticator on their first sign-in and use it on every session afterwards.
Reload operators on their own pool
Counter staff who reload rider cards sign in against a separate identity pool with per-operator daily limits, so a compromised counter login can't move large amounts of money before the unusual activity is flagged.
Append-only audit log
Every change in the dashboard -- every fare edit, every card suspension, every operator role change -- is written to an append- only audit log. The log is protected at the infrastructure level against update and deletion: even an administrator cannot edit history.
Payments
How we protect riders' money.
Card-present hardware at the kiosk
Kiosks accept EMV chip, contactless, and magstripe through a dedicated payment terminal. The bank card data never touches the kiosk's main computer; it stays inside the payment terminal's secured firmware until it reaches the payment provider.
In-app reload through an integrated provider
Reload through the mobl.city app runs against an integrated payment provider with the same scope reduction. mobl.city does not store card numbers at any layer.
Idempotent crediting
Every payment intent is recorded against a unique transaction identifier. If a webhook is delivered twice -- and at internet scale they sometimes are -- the rider's balance is only credited once.
Resilience
How we keep running.
Offline-tolerant field devices
On-board terminals and kiosks keep accepting taps and selling rides through a network drop. When connectivity returns they reconcile with the cloud and the operator dashboard catches up.
Tamper-aware enclosures
Field devices ship with reed-switch and accelerometer tamper sensors. Opening the case or knocking the device off the wall fires a tamper event that is written to the audit log and visible to the tenant's operations team within seconds.
Daily currency-rate refresh
For multi-tenant operators settling across currencies, exchange rates are refreshed daily from a single trusted source and pinned into each transaction at the moment of the tap. A rate provider outage doesn't strand riders.
Want the deeper detail?
Talk to our team.
For procurement questionnaires, threat-model conversations, or details about how a specific control is implemented, the fastest path is to reach our engineering team directly.
Talk to our team