How Tabi handles personal information

Updated 14 October 2026

Tabi is operated by ANCODE (PTY) LTD, registration number 2021/315476/07, of 2nd Floor Edward IV, 120 Edward Street, Bo-Oakdale, Bellville, Western Cape, 7530, South Africa. ANCODE (PTY) LTD (we, us, or our) is the responsible party for the personal information described in this policy.

For privacy questions, information-access requests, correction or deletion assistance, email support@tabifamilyrides.co.za and address the request to the Information Officer of ANCODE (PTY) LTD.

This policy explains how Tabi handles information when parents, guardians, drivers, family members, and linked child-device users use the Tabi mobile app, website, support services, and ride-safety features.

The beta practices described below apply when the relevant feature is available. New beta features and deletion updates are being prepared for activation; contact support to confirm feature availability or completion of a deletion request.

1. What Tabi does

Tabi helps families coordinate ride requests and offers, match trusted family drivers, manage children and vehicles, follow approved active trips, receive notifications, link a child device, send a child SOS alert, review completed trips, and report ride or safety concerns.

Tabi is not an emergency service. In an emergency, contact the appropriate local emergency service and a trusted adult.

2. Information we collect

We collect information that users provide, information generated by use of Tabi, and limited technical information collected by our service providers and software development kits.

2.1 Account and identity information

• Firebase user ID and authentication provider information;
• name, email address, phone number, family role and relationship;
• self-reported South African province, city/town and neighbourhood/suburb;
• account, profile-completion, consent-version, notification, and onboarding status;
• public-beta notice acknowledgment timestamp and notice version, recorded separately from Terms and Privacy acceptance;
• for drivers, verification status, driver-profile details, optional profile photograph, and licence number and expiry information;
• for an approved hosted identity check, an identity number transmitted transiently through Tabi's protected backend to Bitventure, consent and audit timestamps, limited request metadata, and a normalised outcome; the reviewed hosted flow does not persist the full identity number or its last four digits;
• records used to prevent abuse, secure accounts, or administer test/reviewer access.

Authentication may use email and password, Google Sign-In, or phone verification. The relevant provider may process login and security information under its own terms and privacy notice.

General area names are saved to the account profile. For eligible adult parents and guardians with nearby ride alerts enabled, Tabi uses the platform geocoding service to resolve the saved suburb, city and province to an approximate area centre. The signup form does not request a street address, house number or live GPS location. Tabi stores the approximate centre privately and compares it with the pickup point of a new public ride request or offer within 20 km. Nearby alerts contain a general message without child names, pickup addresses or coordinates. Delivery depends on device notification permission, connectivity and service availability. The alert opens discovery around the saved area; it does not grant access to another family's private trip.

Account holders can update their area or turn off Nearby ride alerts through Profile > Edit Profile. Nearby area registration is refreshed when the adult uses the app and expires after 30 days without refresh. Expired centres are excluded immediately from matching and removed by scheduled cleanup. A centre is invalidated when the area changes, nearby alerts are disabled or the account becomes ineligible, and removed during account deletion. This feature does not collect a child device's location. Saved general area fields and these approximate centres are separate from ride pickup/drop-off and live trip location data.

2.2 Family and child information

• family name, family identifiers, membership, parent/admin roles and permissions;
• a child's name, school, grade, pickup notes, guardian notes, medical notes, status, and family relationship;
• linked child-device identifiers, device name/platform, pairing and revocation status, and last-seen information;
• emergency-contact name, phone number, and relationship entered by a user.

Parents and guardians should provide only information necessary for ride coordination and safety. Do not enter detailed medical records or other highly sensitive information unless it is necessary for the child's care during a ride.

2.3 Ride, vehicle, and route information

• ride requests and offers, participating families and users, child passengers, driver and vehicle assignments, seats and accessibility attributes;
• vehicle make, model, colour, year, registration, photographs, current/default status, and child-seat or accessibility details;
• pickup and drop-off labels, addresses and coordinates, dates and times, waypoints, favourite places/routes, ride notes, acceptance and lifecycle status;
• active-trip records, ordered stops, arrival events, interruptions, route deviations, completion status, and route geometry/baselines;
• completed-trip reviews, ratings, safety confirmations, belongings/missing-item reports, descriptions, support outcomes, and audit events.

2.4 Location information

With permission, Tabi processes approximate or precise device location for map, route, live-trip, and safety features.

For a driver, live location sharing begins only after the driver chooses Start Live Tracking for an eligible active ride. Tabi may continue collecting precise location while the app is in the background or not visible, for example while the driver uses Google Maps. A persistent Android notification indicates that sharing is active. Location may include latitude, longitude, accuracy, timestamps, route points, arrival/deviation events, and interruption information. It is made available to authorised participants in that ride and processed by our mapping and cloud providers.

For a linked child device, Tabi may collect precise location during an authorised active trip, including latitude, longitude, accuracy, altitude, speed, heading, timestamps, device/trip identifiers, and sharing status. This information is visible only to authorised family and ride participants under Tabi's access rules. Operation while a child device is backgrounded or terminated may depend on the device, operating system, permissions, connectivity, and battery-management settings.

Child SOS and automated safety events may include the most recent available child or trip location.

Users can stop a driver live-tracking session in the app. Tracking also stops when the relevant ride is completed or cancelled according to the app's trip state. Device operating-system settings can withdraw location permission, although doing so disables location-dependent features.

2.5 Photos and identity verification

Users may choose a photo from the camera or gallery for supported driver or vehicle profile features. Tabi uploads the selected image and a thumbnail to cloud storage for those features.

Hosted Bitventure identity verification is restricted to approved test users and is not available to ordinary public-beta users. In that hosted process, Tabi transmits an approved identity number from its protected backend and opens Bitventure's secure page. Bitventure captures and processes the face/liveness scan and compares it with its available reference image. Tabi does not upload an identity-document image or selfie to Firebase for this flow.

Tabi retains limited request metadata, consent and audit timestamps, and the normalised outcome of the hosted check. The reviewed hosted flow does not store the face/selfie images, biometric templates or facial/liveness scores in Tabi's database. Provider-held information has its own processing and deletion requirements. Identity verification alone does not approve a person to offer rides or independently verify a driving licence.

Alternative identity verification, such as a live video call showing an identity document and the user's face, is a possible future process and is not currently offered to ordinary public-beta users. Before such a process is offered, Tabi will explain the information involved, who may access it, whether calls or images will be recorded, the purpose and applicable consent, retention, and available privacy rights.

2.6 Notifications and device information

Tabi processes push-notification tokens, Firebase installation identifiers, app version, device/app identifiers, platform information, notification preferences, and delivery status to send ride, family, tracking, and safety notifications. Notification payloads are designed not to include precise coordinates.

The Google Maps SDK may automatically process request and device metadata, IP address, a Maps-specific pseudonymous identifier, SDK crash metrics/stack traces, and, depending on use, map interaction events such as pan and zoom. Firebase SDKs may process IP address, installation/app identifiers, SDK/app versions, user-agent information, authentication identifiers, and developer-defined data sent through Firebase products.

2.7 Support and communications

If a user submits a safety concern, Tabi may send the concern to authorised support personnel. A safety report may be sent to authorised support personnel through Tabi's email and hosting provider. It may include the reporter's name and email, driver and family identifiers, trip title, child names, pickup and drop-off addresses, review rating or status, request or offer identifiers, and the user's description. Do not include unnecessary sensitive information in free-text fields.

Voluntary general feedback and bug reports save the selected report type, message, optional chosen screenshot, account identifier and email, email-verification state, basic app version/build/platform details, submission reference, and review/delivery status privately. Authorised Tabi staff review these reports. Tabi may send a notification and the selected screenshot as an attachment to its controlled support mailbox through the configured email provider.

Before submission, screenshots are re-encoded to remove EXIF/location metadata. Details visible in the image or message remain, so remove unnecessary personal or sensitive information before sending. The feedback form does not request GPS or automatically attach child profiles, trip routes, addresses, phone numbers or device identifiers. Screenshots are stored with the private report rather than through a public download link. Support may follow up using the account contact information; immediate responses are not guaranteed.

The optional beta survey saves submitted ratings for overall experience, ease of use and confidence; problem and recommendation choices; selected improvement areas and optional comments; account identifier; survey version; basic app version/build/platform details; and submission/review status. Answers are private but linked to the adult account and are not anonymous. Answers are sent only when the user submits the survey. Authorised staff review them privately; survey answers are not automatically emailed.

To delay survey invitations, Tabi records the first qualifying Home check and evidence of a return on another South African day, capped at two participating days, together with completion, snooze or dismissal choices. Invitations become eligible after 72 hours and a return on a second day. Not now saves a seven-day snooze; No thanks dismisses that survey version. Timing collection stops when the required day evidence is recorded or the survey is completed or dismissed. This does not record browsing history, use duration, trip activity or GPS. The survey does not automatically copy email, phone, child/family/ride details or screenshots.

If a user sends a separate shuttle enquiry, Tabi privately records the requester's name, account email and phone number, account and family references, pickup and destination, requested travel date and time, seats, optional notes, consent version/timestamp, and request/support status. The enquiry is emailed to authorised Tabi support through its email provider. It is an enquiry rather than a confirmed ride booking.

Sending a shuttle enquiry requires explicit consent for Tabi to share relevant enquiry information and contact details with a suitable independent shuttle company so that company can contact the requester about availability and arrangements. Provider forwarding is handled by Tabi staff, rather than an automatic provider booking. Do not include unnecessary child, medical or other sensitive information in enquiry notes. An independent provider's own privacy practices apply to information it receives.

When a parent or guardian selects Ask Tabi to arrange return for a missing or found item, authorised staff may receive a private support email containing case/issue references, the child's display name, item category and description, and the requesting adult's and assigned driver's names, emails and phone numbers. Staff contact the parties separately and must not reveal either party's contact details to the other without permission. Ordinary item-return emails exclude home addresses, medical information, live location and route history.

2.8 Safety, SOS, review and trust information

Tabi processes safety information when a linked child sends SOS, when trip monitoring records GPS loss, driver and child separation or route deviation, and when a user completes a post-ride safety confirmation or report. Records can include the event type/status, family/child/driver/trip/request identifiers, recipient parent IDs, recent available location/accuracy/timestamp, separation/deviation metrics, a user narrative, belongings status, support outcome and audit timestamps.

Completed-trip reviews can include a rating and optional notes. Tabi uses reviews and ride outcomes to maintain driver trust summaries and private trust evidence. Missing-item flows can include a category, description, status, participant view and support and audit events. These records are limited to relevant participants, trusted backend processes, and authorised support according to their sensitivity.

2.9 Information Tabi does not currently collect for monetisation

Tabi does not use advertising SDKs, the Android Advertising ID or payment-card entry in the app. Open Beta is free and checkout is disabled. The Android app includes a dormant Google Play subscription integration for a later paid launch. No beta-end date or payment authorisation is set; after Open Beta ends, the planned three-calendar-month Tabi-funded trial will require no purchase, and subsequent paid access will require an adult to explicitly confirm a store purchase. Billing data practices and store disclosures must be published before paid checkout is activated. Tabi does not sell personal information or use it for targeted advertising.

2.10 Optional error diagnostics

Tabi offers optional Android crash reports and technical diagnostics through Firebase Crashlytics. The new opt-in is off by default and can be changed in Profile using Share crash reports and diagnostics. The choice is stored on this device and applies to its app sessions. Turning it off disables optional reporting and asks Crashlytics to delete unsent reports; it does not erase reports already submitted or disable operational processing by Maps, authentication, notifications, app integrity or other services. Native collection settings from an earlier app version may still apply during its upgrade startup until the new preference is loaded. Development builds do not enable optional reporting.

Reports submitted by Tabi's application error handler include a fixed error category, the affected startup service where relevant, and filtered source-code stack locations. Tabi does not deliberately attach names, account IDs, contact details, child profiles, area names, trip routes, GPS coordinates, screenshots, feedback text, arbitrary exception messages or widget diagnostics to those reports. No Google Analytics breadcrumbs or custom user identifiers are configured.

The native Crashlytics SDK also processes crash traces, relevant application state, app/version and device/operating-system metadata, installation and session identifiers. Native reports are outside Tabi's application-message filter and may contain exception text from a failing service. Diagnostics are not anonymous and cannot be described as containing no potentially identifying information. Google processes them for technical reliability; this is separate from optional feedback and survey participation.

3. How we use information

We use personal information to:

• create and secure accounts and family memberships;
• provide ride coordination, matching, maps, route planning, live tracking, child-device pairing, SOS, notification, and support features;
• show ride participants the information needed to carry out an accepted ride safely;
• maintain trip history, handle reviews, missing-item reports, and safety follow-up;
• administer beta acknowledgment, privately review voluntary feedback and survey answers, and time optional survey invitations;
• handle separately consented shuttle enquiries and coordinate private item returns;
• perform hosted identity and face/liveness checks only for approved test users while public access remains unavailable;
• prevent misuse, investigate incidents, enforce our terms, and protect users and the service;
• diagnose failures and maintain service reliability;
• comply with law and respond to valid legal requests; and
• communicate about accounts, rides, security, support, and material service changes.

We process personal information only where there is a lawful basis under applicable law. The applicable basis may depend on the purpose, the user's relationship with Tabi, and the country concerned.

4. When information is disclosed

We disclose information only as needed for the purposes described here:

• Authorised family and ride participants. Accepted-trip participants may see relevant names, child/driver/vehicle details, contact details where the user has enabled sharing, pickup and drop-off information, ride notes, status, and live location.
• Google/Firebase and Google Maps/Routes. These services provide authentication, cloud database/functions/storage, app integrity, push messaging, mapping, geocoding, directions/routes, Crashlytics error monitoring, and related security/diagnostic processing.
• Email/hosting provider. The configured provider processes private safety-concern, feedback, shuttle-enquiry and item-return support emails, including chosen feedback screenshots and the contact or case details described above.
• Independent shuttle providers. After explicit provider-sharing consent, relevant enquiry and requester contact details may be shared with a suitable company to discuss availability and arrangements. This does not authorise unrelated marketing or unrestricted disclosure of internal account/family records.
• Bitventure. For approved restricted test access, the provider receives the identity number and hosts the face/liveness check. This feature is unavailable to ordinary public-beta users; alternative verification remains prospective.
• Support, professional advisers, and authorities. We may disclose information to authorised personnel, legal/privacy/security advisers, or competent authorities where necessary and lawful.
• Business transfer. Information may be transferred in a merger, acquisition, financing, reorganisation, or sale, subject to law and appropriate notice/protection.

We do not make precise live location public. Some ride requests and offers may be visible to eligible authenticated parent accounts according to the app's matching and access rules.

Where information is processed across borders, the safeguards described in section 9 apply.

5. Children and family accounts

Adults arrange rides and manage passenger profiles. Children under 13 may be passengers managed through an adult account; they must not use Child Mode. Paired Child Mode is for ages 13 and over, and a parent must confirm this minimum age before generating a pairing code. Existing links without that confirmation must be paired again. A parent or authorised guardian creates/manages the family relationship and pairs or revokes a child device. Tabi may process a child's profile, ride, location, device, SOS, and safety information as described above.

Parents and guardians can review and manage child profiles and linked devices in the app. Deleting an adult account may not automatically erase child profiles, shared ride records, historical tracking information, safety records, or information that must be retained for a lawful purpose.

Optional Android diagnostics are off by default on a device without an opt-in and follow the device preference described in section 2.10. The voluntary feedback and beta survey flows are for authenticated adult accounts and exclude anonymous Child Mode.

6. Retention

We retain information only for as long as necessary for the purpose collected, safety and dispute handling, service security, legal obligations, and establishment or defence of claims. Different records require different periods.

Retention is limited by the purpose, applicable law, safety/dispute needs and whether information is needed to establish or defend a claim. This applies to account and beta-acknowledgment data, family/child information, location and trip records, safety and missing-item cases, feedback/screenshots, survey answers/invitation state, shuttle enquiries/consent, device records, verification, security logs, mail copies and backups. Detailed location data should be limited to the shortest period reasonably necessary for the applicable trip, safety, dispute or legal purpose.

Where a record must be retained after account deletion, access should be restricted and direct identifiers deleted or pseudonymised where lawful and feasible.

Firebase states that Crashlytics retains crash traces and associated identifiers for 90 days before beginning removal from live and backup systems. This is separate provider storage. Deleting a Tabi account does not automatically delete those reports, and Tabi does not attach an account ID that would allow account-based diagnostic lookup. Requests relating to diagnostic information may require a separately verified support/provider process.

7. Account deletion and user choices

Signed-in adult account holders can use Profile > Delete Account and choose immediate deletion or a 30-day recovery period. The user must type DELETE. A scheduled request can be cancelled during the recovery period through the pending-deletion flow. Family access is removed when the backend accepts the request.

Users may request deletion assistance without using the app through https://tabifamilyrides.co.za/delete-account or support@tabifamilyrides.co.za. Sending an email does not itself complete account deletion.

Account deletion requires backend processing and confirmation. The intended beta cleanup is designed to remove the Firebase Auth account, primary user document (including general area and beta acknowledgment), the private nearby-area centre, specified user subcollections, specified photo/document storage prefixes, public driver profile, local hosted-verification/control/status records, and the supported child-device record. Open ride requests/offers and active trips are cancelled rather than erased; family membership may be marked deleted, and shared/historical/safety records can remain. Some storage and subcollection cleanup is best effort. Do not assume that every associated record has been erased when a deletion request is submitted.

Additional beta cleanup is designed to remove the deleting user's feedback records, embedded screenshots and submission controls; survey responses and invitation timing/choice state; and shuttle enquiries and submission controls. These updates require activation and successful completion before their deletion can be confirmed. Contact support about the status of a specific request.

Delivered support emails, information already forwarded to an independent shuttle company, Bitventure-held information, diagnostic reports, logs and backup copies require their own applicable retention or provider process. Account deletion does not automatically erase those copies. Local hosted-verification deletion does not establish Bitventure-side deletion.

The current in-app data export covers supported account/family information and does not include the private feedback and survey collections. Users can request access or correction to their feedback or survey information through support@tabifamilyrides.co.za.

Users may also:

• withdraw device permissions in Android settings;
• stop driver live tracking in the app;
• revoke a linked child device where the app permits;
• update supported profile/family information;
• request access, correction, objection or restriction, portability, or deletion where applicable through support@tabifamilyrides.co.za, addressed to the Information Officer of ANCODE (PTY) LTD.

We may verify identity and authority before fulfilling a request and will respond within the period required by applicable law.

8. Security

Tabi uses authenticated access, Firebase security rules, HTTPS/TLS transport, restricted cloud functions and device/ride access controls intended to protect information. App Check is integrated, although this does not mean every backend request is currently subject to enforced attestation. The Android manifest disables cleartext traffic and Android backup for the app.

No security measure is perfect. Tabi does not claim independent security certification or guaranteed security. We will handle security incidents and notifications as required by applicable law.

9. International processing

Firebase resources are configured in the africa-south1 region where supported, but Google, mapping, authentication, messaging, and hosting providers may process information in other countries. Where information is transferred across borders, we and our providers will use safeguards required by applicable law.

10. Third-party services

The app may link to Google Maps/navigation and public Tabi web pages. Third-party services have their own privacy practices. Key service providers include:

• Google Firebase (Authentication, Firestore, Cloud Functions, Cloud Storage, Cloud Messaging, Crashlytics, Installations, Sessions, and App Check/Play Integrity);
• Google Maps Platform (Maps SDK, geocoding/directions/routes, and navigation handoff);
• the hosting and email providers used to deliver support and safety communications; and
• Bitventure for restricted hosted identity/face/liveness test access, and suitable independent shuttle companies for explicitly consented enquiries;
• any other service provider identified in the current app or backend and described in this policy.

11. Changes to this policy

We may update this policy when Tabi's features, providers, legal obligations, or data practices change. We will update this policy and provide additional notice where required.

12. Contact and complaints

For privacy questions, information-access requests, correction or deletion assistance, email support@tabifamilyrides.co.za and address the request to the Information Officer of ANCODE (PTY) LTD.

Company address: ANCODE (PTY) LTD, registration number 2021/315476/07, 2nd Floor Edward IV, 120 Edward Street, Bo-Oakdale, Bellville, Western Cape, 7530, South Africa.

South African users may have the right to complain to the Information Regulator (South Africa) at https://inforegulator.org.za/. Users in other countries may have the right to complain to the relevant data-protection authority.