Legal
Privacy Policy
Renaro runs dispatch operations for transportation operators, which means handling real personal data: passenger details, driver records, live locations, payments, and messages. This policy says exactly what is processed, why, who sees it, how long it is kept, and the rights you have over it.
Who we are and the roles we play
Renaro ("Renaro", "we") provides dispatch, booking, fleet, communications, and payment operations software for taxi, private hire, and chauffeur operators. Renaro is based in London, United Kingdom. This policy covers the marketing site at renaroapp.com, the operator dashboard at app.renaroapp.com, Renaro-hosted booking and tracking pages, the public API, and the Renaro Driver and Renaro passenger mobile apps.
Renaro plays two distinct roles. For the operational data an operator brings onto the platform - their passengers, drivers, vehicles, bookings, messages, and trip payments - the operator decides why and how that data is used, and Renaro processes it on the operator's documented instructions under the Data Processing Addendum. For the data Renaro needs to run its own business - operator staff accounts, billing, security and audit logs, product analytics, support, and this website - Renaro decides the purposes and is the controller.
If you are a passenger whose trip was arranged through an operator that uses Renaro, that operator is responsible for your data and is your first point of contact for questions and requests; this policy explains what Renaro does with your data on the operator's behalf.
Who this policy covers
- Operator staff - owners, dispatchers, and administrators with dashboard accounts.
- Drivers - people who drive for an operator and use the Renaro Driver app.
- Passengers and customers - people whose trips are booked, dispatched, or paid for through the platform, including corporate travelers and hotel guests.
- Corporate account contacts - bookers, billing contacts, and travel coordinators at an operator's corporate clients.
- Website visitors - people reading renaroapp.com, which sets no cookies and runs no analytics.
Information about operator staff
For each dashboard account we process the name, email address, phone numbers, profile image, language preference, role and permissions, and organization membership. Sign-in is handled by WorkOS, our authentication provider, which also records the IP address and browser details of sign-ins. Session records - a hashed session token, IP address, device and browser description, and last-activity time - support the security controls operators can apply to their own staff, such as IP allowlists and access schedules.
Information about drivers
Driver records are created and maintained by the operator the driver works with, together with the driver's own use of the Renaro Driver app. They are among the most sensitive records on the platform and can include: identity and contact details; date of birth; driving licence and permit numbers; national insurance or tax identifiers where the operator records them; work-authorization and background-check status recorded by the operator; home address and coordinates used for going-home dispatch preferences; insurance details; employment dates and pay or commission settings; payout account references (bank name and last digits only); uploaded documents such as licences, insurance certificates, permits, and vehicle registrations; shift records; vehicle assignments; ratings; performance and dispatch-scoring inputs; speed-limit violation events with location; suspension history with reasons; and free-text notes entered by dispatchers.
The driver app additionally processes device identifiers and push-notification tokens, an app sign-in PIN (stored only as a salted hash), and - only while the driver is on shift - the location data described below. Voice commands are processed on the device through the platform's speech recognition; Renaro does not store raw voice recordings from voice commands.
Information about passengers
Passenger records are entered by operators, imported from an operator's previous dispatch system, or provided by passengers themselves through booking pages, the passenger app, or an operator's booking channels. They can include: name, phone number, and email address; date of birth and anniversary dates where an operator records them; saved pickup and dropoff locations, which can include building names, suite numbers, and gate codes; emergency contacts; communication preferences including SMS, email, and push opt-ins, marketing opt-outs, and quiet hours; booking history with pickup and dropoff addresses, times, and trip status; accessibility and service needs recorded on bookings, such as wheelchair or child-seat requirements; payment references described under Payments; wallet, loyalty, and promotion balances; ratings and feedback; and free-text notes operators keep for service quality, such as trip preferences or billing instructions.
Operators also maintain service-history measures about passengers - for example reliability, cancellation, and no-show rates, VIP status, or a do-not-serve flag with the reason - which the platform computes or stores on the operator's behalf to support their dispatch and customer-service decisions.
Where an operator's corporate clients book on behalf of travelers, or a hotel books for a guest, the platform processes the traveler or guest details the booker provides, such as name, contact details, room number, and special requests.
Location data
Driver location is the heartbeat of dispatch. While a driver is on shift, the driver app reports position - latitude, longitude, heading, speed, and accuracy - which streams into a short-lived live buffer (expiring within minutes) and is then written to trip and fleet records roughly every 30 seconds. Location reporting stops when the driver ends their shift; background location is used only during an active shift. Location history is kept for 90 days by default (operators can configure this) and is then permanently deleted on a daily schedule.
Bookings carry pickup and dropoff addresses and coordinates, including structured address details returned by our geocoding providers. Trip records can also include location-stamped operational events - for example speed-limit violations during a trip or the location attached to an SOS alert - which operators use for safety and compliance.
Payments
Payment processing is provided by Stripe. Card numbers and full bank account numbers are entered into Stripe-hosted fields in the browser, the passenger app, or a Stripe card reader, and go directly to Stripe - they never touch Renaro's servers. Renaro stores tokenized references along with the card brand, last four digits, billing name and address, and for bank debits the bank name and last digits plus the authorization record for the debit mandate.
To operate payments on an operator's behalf, Renaro shares the payer's name, email, and phone with Stripe when saving a payment method, and receives back charge outcomes, disputes, refunds, and payout records. Operators and drivers who receive payouts onboard directly with Stripe, entering their own identity-verification details on Stripe-hosted pages; Renaro sees verification status, not the underlying documents.
Financial records - charges, refunds, invoices, ledgers, payout history, and tax-relevant records - are retained even after account deletion where accounting, tax, dispute, or audit obligations require it, with personal fields minimized wherever possible.
Messages, calls, and recordings
The platform sends booking-lifecycle messages - confirmations, driver-on-the-way updates, receipts, payment requests, reminders, and account-security messages - by SMS, WhatsApp, email, and push notification, using Twilio for SMS, WhatsApp, and voice and Resend for email. Message content is generated from operator-configured templates and can include the passenger's name, pickup and dropoff addresses, fare, driver name and vehicle, booking reference, and links such as live-tracking or payment pages. Sent messages, including their content and recipient address, are stored so operators have a communications record; retention is described below.
Number masking connects drivers and passengers through an intermediary phone number so neither sees the other's real number; establishing the session requires sharing both real numbers with Twilio. Where an operator uses a phone booking line, the call is answered by an automated voice system: Renaro receives the caller's number and, when the caller speaks an address, a text transcription of what was said. Dispatcher conference calls are recorded only where the operator turns recording on; recordings are produced and stored by Twilio, and Renaro stores the call reference. Confirmation and receipt emails can embed a small static map of the trip; when the email is opened, the map image loads from Mapbox, which receives the trip coordinates in the image address and the reader's IP address.
Documents, files, and signatures
Uploaded and generated files - driver identity and compliance documents, vehicle documents, passenger trip-completion signatures, generated receipts, invoices, statements and manifests, bulk-import spreadsheets, and data-export archives - are stored privately in Cloudflare R2 object storage. Files are never publicly accessible: every upload and download uses short-lived signed links, and uploads pass through malware scanning and quarantine before entering the main store. Passenger signatures captured as trip-completion evidence are retained for up to seven years for legal claims and statutory evidence, or longer under a legal hold.
How we use information
- Run the service an operator configures: dispatch, booking management, routing and ETAs, driver assignment, passenger tracking, communications, payments, billing, invoicing, reporting, and support.
- Keep accounts secure: authentication, session and device controls, abuse and fraud detection, provider webhook verification, audit logging, and incident investigation.
- Meet legal obligations: accounting and tax records, responding to lawful requests, and enforcing agreements.
- Improve the platform: aggregated, de-identified operational telemetry and pseudonymous product analytics; learned corrections such as ETA models are built from operational patterns, not from content that identifies another operator's passengers.
- Communicate about the service: onboarding, operational notices, changes to terms, and support conversations.
Automation and scoring
Dispatch automation is explicit and auditable by design. When the platform recommends or auto-offers a driver for a booking, it uses a weighted score over operational inputs such as distance and estimated arrival time, availability and shift state, vehicle suitability, and service-history measures like ratings or reliability - with the scoring factors and weights visible to the operator, who can always override and assign manually. Demand forecasting and learned ETA corrections work on aggregated historical patterns. Flight tracking can adjust a booking's pickup time automatically when the operator enables that mode, with the passenger notified of the change.
Some rule-based automation affects drivers directly, on the operator's configuration: dispatch eligibility is suspended automatically when a verified compliance document expires, and operators can enable automatic suspension when ratings fall below their chosen threshold. These are transparent, threshold-based rules rather than opaque profiling; the operator sees, controls, and can reverse them, and drivers can raise any such action with their operator, who is responsible for the decision as their employer or principal.
Passenger service-history measures (for example no-show rates or a do-not-serve flag) are tools operators maintain for their own customer relationships; Renaro computes and stores them on the operator's instructions and does not use one operator's records to profile people for anyone else.
International transfers
Renaro's production infrastructure - database, compute, cache, and most subprocessors - runs in the United States, and Renaro serves operators in the United Kingdom and elsewhere. Where personal data protected by UK or EU data-protection law is transferred internationally, Renaro relies on the safeguards in its vendor agreements - the UK International Data Transfer Addendum and EU Standard Contractual Clauses as applicable, alongside each vendor's published data-protection commitments - and keeps transfer documentation available to operators through the Data Processing Addendum.
How long we keep information
Retention is purpose-scoped rather than one-size-fits-all. The defaults that matter:
- Driver location history - 90 days by default (operator-configurable), then permanently deleted on a daily schedule; the live location buffer expires within minutes.
- Message content - SMS messages are cleared after 90 days, email and push message records after 30 days, and chat and WhatsApp threads after 180 days.
- Passenger trip-completion signatures - up to seven years, as statutory evidence for claims.
- Data-export archives - available for 7 days, then removed.
- Financial ledgers, invoices, payout and tax records - retained for accounting, tax, dispute, and audit periods even after deletion requests, with personal fields minimized.
- Audit and security logs - retained to preserve the integrity of the platform's audit trail; access is restricted and personal identifiers are anonymized when the underlying account is erased.
- Everything else follows the account lifecycle: active while the record is in use, soft-deleted when removed, and anonymized or erased through the deletion flow below.
Deletion and your choices
Operators can export their organization's data as JSON or CSV at any time; exports are prepared asynchronously and downloaded through a private link that expires after seven days. Drivers and passenger-account holders can request an export of their own data from their account controls.
Deletion is a deliberate, verifiable flow. An organization, customer, or driver deletion request must be separately confirmed; confirmation freezes the account and starts a 30-day grace period during which the requester can cancel. When the period ends, Renaro revokes access, anonymizes or deletes personal fields, removes private files and cached entries, and deletes the corresponding identities at providers such as WorkOS and Stripe where lawful. Records that must survive - the financial, audit, and evidence categories above - are kept with personal fields anonymized, and legal holds (tax, disputes, unresolved payouts, security investigations) can pause erasure until resolved.
Passengers without their own account should contact the operator that arranged their trips; the operator can correct, export, or delete their record, and Renaro supports the operator in fulfilling those requests. You can opt out of SMS at any time by replying STOP, and out of an operator's marketing through the unsubscribe or preference options in those messages.
Your legal rights
If UK or EU data-protection law applies to you, you have rights of access, rectification, erasure, restriction, portability, and objection, which you can exercise against the controller of your data - the operator for trip and customer records, Renaro for the account and business records it controls. Renaro responds to requests about data it controls at the contact below, and passes requests about operator-controlled data to the right operator without undue delay. You also have the right to complain to a supervisory authority - in the UK, the Information Commissioner's Office (ico.org.uk).
If a US state privacy law applies to you, you have equivalent rights of access, correction, and deletion, exercisable through the same contacts, and the descriptions in this policy of what is collected and shared serve as the required notice. Renaro does not sell or share personal data for cross-context behavioral advertising, so there is nothing to opt out of on that front.
Security
Security is architectural, not aspirational. Every tenant-scoped query is organization-bound with row-level security as defense in depth; sensitive access and every write produce audit records including the acting user; data is encrypted in transit everywhere; stored integration credentials are encrypted at rest with authenticated encryption; API keys and session tokens are stored only as cryptographic hashes; files live in private storage behind short-lived signed links with malware scanning and quarantine on upload; server logs pass through a redaction layer covering hundreds of sensitive field paths; error reporting excludes request bodies and known secret patterns; session replay is disabled in analytics and error tooling; and the mobile apps pin Renaro's API certificates. No system is perfectly secure, and Renaro will notify affected operators without undue delay if a breach affects their data, as the Data Processing Addendum describes.
Mobile apps and device permissions
The Renaro Driver app asks for location (including background location, used solely during an active shift), notifications, camera and photo access for document capture and QR workflows, microphone and speech recognition for hands-free voice commands, and biometric unlock. The passenger app asks for foreground location, camera, and biometric unlock. Each permission is requested in context with an explanation, works only for the feature described, and can be revoked in device settings - revoking a permission disables that feature but not the app.
Crash and performance diagnostics from the apps go to Sentry with identifiers limited to internal account and organization IDs. Push notifications are delivered through Expo and the device platform; tokens are removed when the account is deleted.
Analytics and error reporting
The operator dashboard uses PostHog for pseudonymous product analytics and feature flags - internal identifiers and role only, no autocapture, no session recording - as described in the Cookie Policy. Error reporting uses Sentry across the platform; reports carry technical context and internal identifiers, and on the operator dashboard they include the signed-in operator's email so incidents can be traced to affected accounts. The marketing site carries no analytics at all.
Children
Renaro's services are business tools for operators and are not directed at children, and Renaro does not knowingly collect personal data from children on its own behalf. Operators sometimes transport minors - school runs, family bookings - and may record a traveler's details to fulfil those trips; that data is entered and controlled by the operator or the responsible adult, and Renaro processes it only as the operator's processor.
Changes to this policy
This policy supersedes the April 30, 2026 version and was expanded on July 18, 2026 to describe the platform's data handling in full. Material future changes will be posted here with a new effective date, and operators with active accounts will be notified through the platform or by email before material changes take effect.
Contact
Privacy questions and requests: support@renaroapp.com. Post: Renaro, Privacy Desk, London, United Kingdom. When contacting us about a specific record, include your operator name and enough detail to locate the record; do not include card numbers or passwords in email.