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-proof at the server

A rolling-nonce check on the server side blocks any attempt to replay a previously-recorded tap, even if the attacker has read the card's traffic in full. Every successful tap rotates the nonce.

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