Privacy

Use the minimum information needed to run and support a ryde.

This page describes the product’s current data domains in plain language. It does not invent a controller identity, retention schedule or statutory contact that has not been supplied for publication.

Information domains

What the mobility platform can process.

Data category

Account and access

Account identifiers, contact details, account state and memberships needed to provide and support access.

Data category

Trips and vehicle state

Reservations, trip records, vehicle telemetry, parking evidence and device-command state needed to operate and investigate a ride.

Data category

Payments and credits

Transaction references, payment state, refunds and ride-credit movements. Public and support views should avoid exposing full payment credentials.

Data category

Support and administration

Support actions, maintenance records, reasons for sensitive changes and audit events needed for accountability and abuse prevention.

Product safeguards

Operational access should remain bounded and auditable.

Internal support views mask contact details by default, search only after an operator asks for a record and avoid loading wider payment or reservation datasets when individual rider history is unavailable.

Administrative changes require authenticated access and, for sensitive actions, a reason retained in the audit trail. Permissions are checked for every action.

Formal notice status

Verified legal details must be published before this becomes the final rider notice.

A final jurisdiction-specific notice still needs the verified legal operator/controller name, privacy contact, processing bases, service-provider disclosures, cross-border handling, retention periods and applicable request or complaint routes.

Until those facts are supplied, do not send identity documents or sensitive account information to an address found outside the verified product experience.

Read legal information