Privacy Policy

Last updated: 2 October 2026

1. Who we are

Upstart Forge Limited, trading as FairTaxi (registered business name RBN 786959), a private company limited by shares incorporated in Ireland on 28 May 2026 (company number 817002), registered office at 22 Drumnigh Wood, Portmarnock, Co Dublin, D13 P652, VAT number IE 4744030VH, holder of National Transport Authority (NTA) dispatch operator licence DH12674 (“FairTaxi”, “we”, “us”, “our”). Contact: complaints@fairtaxi.ie (general/complaints), privacy@fairtaxi.ie (privacy enquiries), support@fairtaxi.ie (support), +353 89 965 3357.

We operate a ride‑hailing platform connecting Riders and independent Drivers. We are the data controller for the personal data described in this policy.

We are not required to appoint, and have not appointed, a statutory data protection officer under Article 37 GDPR. For any privacy enquiry or to exercise your rights, contact our privacy contact at privacy@fairtaxi.ie.

2. What data we collect

We collect personal data from Riders and Drivers as follows.

2.1 Rider data

Identity and contact: mobile phone number (verified by OTP), first name (optional), email address (optional, for receipts).
Payment data: we do not store full card numbers. We access the last 4 digits and card brand via Stripe for display in the App.
Ride data: pickup and destination addresses, route, trip times, fare amount, payment method.
Location: while using the App for a ride or when location services are active, we collect precise GPS location.
Dispute materials: photos and messages you submit through the dispute feature.
Card dispute records: if a card payment for one of your rides is disputed with your bank or card issuer (a chargeback), we record the dispute as Stripe reports it to us: Stripe’s identifiers for the dispute, the charge and the payment, the amount, the reason given, the stage and result, the dates it was raised and resolved, which ride and payment record it relates to, which kind of payer paid (you, a sponsor, or an organisation), whether the charge sat on the Driver’s account or ours, and the notification message Stripe sent us. Where the same payer disputes card payments to us more than once, we may also open an internal review entry so that our team can look at the pattern. Section 6.4 sets out in full what that is, why we do it, what it contains, who sees it, how long we keep it, and what you can do about it.
Diagnostic logs: if you choose “Send diagnostic logs to support”, we receive logs that may contain technical device information.
Crash reports. These are automatic and they are not the diagnostic logs above. From the first time you open the App, and without you switching anything on, it reports crashes to Firebase Crashlytics. A report carries the stack trace of the failure, the model of your device and its operating-system version, the version of the App, and a Firebase installation identifier that identifies the App on that device. Your account identifier is attached only where you have consented to usage analytics, and where that consent is absent or withdrawn the identifier is cleared; the driver App for iPhone attaches no account identifier at all. Section 6 names Google as the processor and Section 3 gives the lawful basis.
Safety data: if you use the emergency button or share trip, we process the associated signals and contact information.

2.2 Driver data

In addition to the above categories (where applicable to Drivers), we also collect:

Full name, email address, mobile phone number (verified by OTP).
SPSV driver’s licence number, and copies of:
- PSV driver licence document,
- Vehicle PSV licence,
- Motor insurance certificate,
- photo identification (for example a passport or a driving licence), which we require where we verify your identity ourselves rather than through Stripe.
A profile photograph (signup selfie). You provide a photograph of your face during registration. It is shown in the App as your Driver profile picture, and an automated check confirms it is a usable portrait before we accept it. Section 6.5 sets out that check, and explains how we verify identity where Stripe does not do it for us.
Subscription payment details: we process subscription payments via Stripe; we do not store full card numbers.
Subscription card disputes. If you dispute a subscription payment with your bank or card issuer, we record the dispute against your account, and more than one such dispute within the period described in Section 6.4 may open the internal review set out there.
Safety reports about you. If a guest books you through your Driver Page and then reports a safety concern about that trip, we record the report and it names you. Section 6.3 sets out in full what is recorded, why we may hold it, who reads it, how long we keep it, and what you can do about it.
Android driver location. When you go online, FairTaxi Driver for Android collects your precise location and sends it to FairTaxi to offer you nearby rides and show the matched rider your car. Collection continues in the background and while your screen is locked for as long as you are online or finishing a trip. It stops after you go offline and any trip in progress has ended.

3. How we use your data, and our lawful bases

We process personal data only where we have a lawful basis under GDPR:

Purpose	Lawful basis
Providing the platform (matching Riders and Drivers, enabling ride booking, facilitating ride payments via Stripe Connect direct charges)	Performance of a contract (Rider Terms / Driver Terms)
Checking that a Driver holds a current SPSV driver licence and that the vehicle holds a current SPSV licence, monitoring their expiry, and keeping the driver and vehicle list our licence requires	Legal obligation, Article 6(1)(c) GDPR: Regulation 63(1) and 63(2) of S.I. No. 33/2015 require a dispatch operator to dispatch only to a licensed Driver in a licensed vehicle and to keep that list available to the National Transport Authority
Checking the motor insurance certificate and motor tax we ask for alongside those licences	Legitimate interest in platform safety and in not dispatching an uninsured vehicle (Article 6(1)(f)); the insurance duty itself sits on the vehicle licence holder, not on us
Collecting photo identification from a Driver whose identity we verify ourselves rather than through Stripe, and a member of our team comparing the portrait printed on it with the Driver’s profile photograph (Section 6.5)	Legitimate interests, Article 6(1)(f) GDPR: preventing fraud, and confirming that the person driving is the person the licence and the identity document belong to. We do not claim a legal obligation for this. Regulation 63 of S.I. No. 33/2015 requires the licences and the list; it does not require a photo ID or a comparison of photographs
Checking that a Driver’s profile photograph is a usable portrait before it becomes the photograph Riders see (Section 6.5)	Legitimate interest, Article 6(1)(f) GDPR, in a Rider being able to recognise the Driver who arrives
Collecting Driver subscription fees	Performance of a contract
Safety features (emergency button, trip sharing)	Legitimate interest in protecting users and providing safety tools
Customer support and dispute resolution	Legitimate interest in platform integrity and user satisfaction
Recording whether a No-Show Fee under clause 5.3 of the Rider Terms is unpaid, restricting a Rider’s ability to request rides under clause 5.5 of those Terms, and counting refusals to pay and cases where a Driver is left unpaid	Legitimate interest in platform integrity and in Drivers being paid for work they have done
Counting repeated card disputes (chargebacks) by the same payer and putting the pattern in front of an authorised member of our team to decide on, so that abusive use of card payments can be identified and Drivers do not lose fares they have earned (Section 6.4)	Legitimate interest in preventing and detecting payment fraud and abuse (Article 6(1)(f), which Recital 47 recognises for fraud prevention) and in Drivers being paid for work they have done
Sending service-related messages (booking confirmations, receipts, account notices)	Performance of a contract
Analytics and app improvement (Firebase Analytics)	Consent (where required)
Automatic crash reporting (Firebase Crashlytics), which runs from first launch without being switched on, so that the Apps can be kept from failing	Legitimate interest, Article 6(1)(f) GDPR, in a stable and usable App. Linking a crash report to your account identifier is a further step and is done only with your analytics consent, so withdrawing that consent removes the linkage without turning crash reporting itself off
Marketing communications	Consent (where required); you may opt out at any time
Compliance with legal obligations (tax, law enforcement requests)	Legal obligation
Defending legal claims	Legitimate interest in protecting our rights

Where we rely on legitimate interests, the interests we actually rely on are: maintaining platform safety and integrity, preventing and detecting fraud and abuse, ensuring Drivers are paid for work they have done, establishing, exercising or defending legal claims, and improving our service. We balance these interests against your rights and only rely on them where they are not overridden by those rights.

4. Whether you must provide data

Providing your identity, phone number and (where you pay by card) payment data is a contractual requirement: it is necessary to create an account and use the service, and without it we cannot provide the platform to you. For Drivers, providing the SPSV driver licence and the SPSV vehicle licence is both a contractual requirement and a regulatory one: Regulation 63(1) and 63(2) of S.I. No. 33/2015 forbid us to dispatch to an unlicensed Driver or an unlicensed vehicle and require us to keep the list, so without them we cannot verify your eligibility or grant dispatch access. Photo identification is different, and we will not dress it up as a statutory requirement: no regulation obliges us to collect it. We ask for it, from Drivers whose identity we verify ourselves rather than through Stripe, as a condition of the contract we offer, on the fraud-prevention grounds in Section 6.5; if you do not provide it we cannot complete that verification and cannot grant dispatch access.

5. How long we keep data

Several of the periods below are 7 years, and we should be straight about where that number comes from, because it is mostly ours rather than the law’s. Irish tax law requires business records to be kept for 6 years, and the Statute of Limitations 1957 gives a party 6 years to bring a contract claim, so a record we may need in order to answer a claim or a Revenue query has to outlive both. We chose 7 years so that a claim brought on the last day of the sixth year still finds the evidence, and we apply the same figure across ride, payment and verification records rather than running a different clock for each. Where a genuine statutory retention period does exist we say so and name it. Where the period is our own choice, as it mostly is, we say that instead of implying a regulator set it.

Ride history: stored for as long as your account remains active. Upon account closure, ride history is anonymised or deleted after 7 years from the last ride. Regulation 63(5) of S.I. No. 33/2015 requires us to keep records of bookings and of complaints and to produce them to the National Transport Authority promptly on request, which is why the records exist at all (Article 6(1)(c) GDPR); it fixes no period, so the 7 years is the chosen period explained above, resting on our legitimate interest in establishing, exercising or defending legal claims and on our tax record-keeping obligations.
Terms acceptance evidence: the account identifier, document name, version, published URL, document hash, acceptance wording and server-recorded timestamp are retained with the account and thereafter for up to 7 years after closure. We use this record to administer the contract and establish, exercise or defend legal claims.
Driver documents: the licensing, vehicle and identity documents you upload (PSV driver licence, SPSV vehicle licence, motor insurance certificate, motor tax, and photo identification where we ask for it) are kept while the Driver’s account is active and for 7 years after the driver relationship ends. That 7 years is our own period, not one a regulator set, and we keep the documents on our legitimate interest in establishing, exercising and defending legal claims (Article 6(1)(f) GDPR, and Article 17(3)(e) where you ask us to erase them). The reason is the one given above this list: a Rider, a Driver or an insurer who says we dispatched someone we should not have dispatched can bring a civil claim up to 6 years afterwards under the Statute of Limitations 1957, a regulator can open an inquiry on its own statutory timelines, and the documents are how we show what we checked and when. This applies with particular force to the photo identification: Regulation 63 of S.I. No. 33/2015 neither requires us to hold a photo ID nor sets any period for one, so we do not claim a legal obligation for keeping it. On account closure the licence-holder names and other identity fields are anonymised and access to the files is restricted, and a Data Deletion Certificate is issued. They are permanently deleted at the end of the period.
A separate tax record, on a genuine legal obligation. Two retentions in this policy do rest on a statute rather than on our choice, and we keep them apart from the rest so the distinction is visible. If your account is closed after you completed trips in the current or previous calendar year, a minimal identification record (legal name, address, date of birth where held, PPS number where available, and the closure date) is kept for 7 years so that we can file the platform-operator report the EU DAC7 rules require us to make to the Revenue Commissioners. That is a legal obligation (Article 6(1)(c) GDPR, and Article 17(3)(b) where you ask us to erase it). Our tax records more generally are kept on the same footing, subject to the 6-year statutory floor and the margin described above.
Driver profile photographs: a profile photograph is an identity image rather than a licensing record, and it is on a shorter clock than the documents above. Every copy we hold of it, including the resized and thumbnail versions, is deleted when the account is closed. Profile photographs are not kept for the 7-year document period.
Automated document-check records: when a document is uploaded we hold two kinds of record about the checks run on it. The working analysis of that upload is deleted when the account is closed. The verification verdict, which records what the checks concluded, the fields read off the document, a fingerprint of the file and our internal references to it, belongs to the document’s verification history and is kept with the document for the 7-year period above. The record of a face comparison against a photo ID (Section 6.5) is treated differently from both: it is deleted when the account is closed, and it is never carried into the 7-year period.
Diagnostic logs: kept while your account is active and deleted when you close or erase your account.
Audit logs (system events): 7 years.
Payment metadata (last 4 digits): for 7 years after the associated transaction. The statutory floor for a financial record is 6 years; the seventh is the margin explained above.
Payment notifications from Stripe: when a payment, refund, dispute, payout, card, subscription or Stripe account changes, Stripe sends us a notification describing it, and we store the notification as received. Depending on what changed, it can contain names, email and postal addresses, phone numbers, a Driver’s date of birth and other details submitted to Stripe for identity checks, and card details such as the brand, last 4 digits and expiry date (never the full card number). We keep the full notification for 90 days, so that we can process it, investigate a failed or repeated delivery, and check our records against Stripe’s. After 90 days we delete its contents. We keep only Stripe’s identifier for the notification, its type, when we received and processed it, and, where the notification carried them, Stripe’s customer reference and the amount paid, so that our payment and subscription records can still be reconciled with Stripe’s. The payment, refund and dispute records described elsewhere in this section are separate records and keep their own periods.
Location data: a Driver’s precise location history is held as a separate record while their account is active and is deleted when the account is closed or erased. Each ride’s route is stored with that ride’s record and kept for the same period as ride history (7 years). The live position used for dispatch is held only briefly in an in-memory store and is removed when the Driver goes offline.
Dispute photos: kept with the associated ride and payment record and retained for 7 years, in line with the retention of ride and payment records, to address any subsequent complaint or claim.
No-Show Fee decisions and restriction records: No-Show Fee decisions, payment/dispute/restriction status and refusal records are kept with the associated ride and dispute record for the same retention period; aggregate metrics are retained only in de-identified form.
Card dispute records and repeat-dispute reviews: a card dispute (chargeback) is kept with the ride and payment record it relates to and for the same period as those records. A repeat-dispute review entry (Section 6.4) has no purge schedule of its own. It is an internal administrative record, and the criterion we apply is that we keep it for as long as we keep the account records it belongs to; it is deleted if that account record, or the dispute that triggered it, is deleted. If you close your account or ask us to erase your data, we anonymise the account record rather than removing it, so that the trip and payment records we have to keep stay complete. The review then points at a record with no name, email address or phone number on it, but it remains linked to that record, so we go on treating it as personal data and it stays covered by this policy. We review this period from time to time. Where a member of our team then takes an action, the record of that action is held in our audit logs for 7 years as above.

We use carefully selected service providers and other recipients. Most act as our processors, contractually bound to process data only on our instructions; where one acts as a controller in its own right, its entry below says so:

Stripe - payment processing. Ride fare payments are processed as direct charges on the Driver’s Stripe Connect account (the Driver is the merchant of record). Driver subscription payments are processed on FairTaxi’s Stripe account (FairTaxi is the merchant of record). Stripe acts as a data processor for our purposes; for ride transactions they also act as a controller for their own compliance. Data is stored in the EU and, where Stripe transfers data outside the EEA, they rely on Standard Contractual Clauses (SCCs).
Firebase / Google - phone-number verification by SMS one-time code at sign-in, authentication, analytics, crash reporting, and push notifications (FCM). Crash reporting is the one among these that starts on its own: Firebase Crashlytics is active from the first launch of the App, so Google receives a crash trace, your device model, its operating-system version, the App version and a Firebase installation identifier whenever the App fails, whether or not you have opted into analytics and whether or not you have ever used the “Send diagnostic logs to support” option. Analytics is separate and consent-gated, and your account identifier is attached to a crash report only while that consent is in place. Data is processed in the EU and under Google’s SCCs where applicable.
Apple - two things, both on Apple devices. (a) Map rendering: the iPhone Apps, Driver and Rider alike, draw their maps with Apple’s own MapKit, so Apple receives the map area being looked at, which for a Driver at work follows where they are and where the ride is going. This happens during ordinary use of the map, not only when a Driver taps “Navigate”, and it is not routed through our servers. (b) Push notifications: iPhone push, including the incoming-call notification for an in-app voice call, is delivered by the Apple Push Notification service. Apple receives the device’s push token, the separate token its call notifications use, and the content of the notification we send. Apple is an independent controller for its own operation of these services and its handling is governed by Apple’s privacy policy; Apple’s network is global, and Section 7 covers that.
Hetzner (Germany) - the server we operate ourselves in Germany, inside the EEA. Two parts of the service run on it. (a) Route calculation: we run our own routing software (Valhalla) on that server, and it receives the coordinates it needs to compute a route or a travel time, which are the Driver’s position, the pickup point and the destination. No name, phone number or account detail goes with them. It runs during ordinary operation, not only as a fallback; fare estimates and turn-by-turn directions use HERE, described below. (b) The SMS gateway described in Section 6.2. Hetzner Online GmbH is the hosting provider and acts as our processor; the data stays in Germany and there is no transfer outside the EEA. Section 7 is written to reflect this: our own systems are in Ireland and in Germany, not in Ireland alone.
Cloudflare - our network provider, and the host of several parts of the service. We do not give a count of purposes, because a count reads as a promise that the list is closed; what follows is every Cloudflare purpose that is live today. (a) DNS, CDN, WAF and cookieless web analytics: traffic to our website and to our API passes through Cloudflare’s network before it reaches our servers, so Cloudflare processes connection data (including your IP address) for security and performance, and the website analytics use no cookies and collect no personal data. (b) Cloudflare Workers AI, reading uploaded documents: when a Driver uploads a licensing, vehicle or identity document (PSV driver licence, SPSV vehicle licence, motor insurance certificate, motor tax, and photo identification such as a passport or a driving licence), we send the document image to Cloudflare Workers AI to read and extract the printed fields (such as name, licence / registration / policy numbers and expiry dates) so our team can verify them. Cloudflare runs open-weight models on its own infrastructure, so the model developers do not receive your data, and Cloudflare’s published terms for Workers AI state that it does not use these inputs to train models. We do not tell you that nothing is retained: some of our calls to Cloudflare’s AI are routed through its AI Gateway, which logs the request and the response so that we can monitor the service. This extraction only pre-fills what a human reviewer sees; the decision to approve a document is made by a person (see Section 8). (c) Cloudflare RealtimeKit, in-app voice calls: calls between Riders and Drivers run over Cloudflare RealtimeKit (WebRTC) with masked numbers, so no phone numbers are exchanged. To set a call up we ask Cloudflare to create a meeting for that ride, so Cloudflare receives the ride reference in the meeting title, the display name of each participant, and our own internal Driver and Rider identifiers as the participant identifiers. Against the ride we store the meeting and participant identifiers, the short-lived participant tokens and when they expire, who started the call, the join and leave times, the duration and the outcome, and we keep those with the ride under the ride-history period in Section 5. We do not configure any recording of the call and we receive none. Cloudflare offers no setting that keeps the live audio inside the EU, so the audio may pass through Cloudflare points of presence outside the EEA for as long as the call lasts, and Section 7 covers that. What Cloudflare itself processes or logs while carrying the audio is governed by its own terms and its Data Processing Addendum, and we do not make a claim about it here. (d) Cloudflare Workers AI, Driver Page username check: if you are a Driver and you publish a FairTaxi-hosted Driver Page, the username you choose becomes part of that page’s public web address, so before it goes live we send that username, and nothing else about you, to Cloudflare Workers AI to check whether it is offensive. A username the check calls offensive is refused and you are asked to choose another. If the check is unclear or cannot be reached, the username is held back unpublished, and the check runs again the next time you submit or re-enable that username; it goes live if a later run comes back clean. There is no separate human review queue for a held username, so a username that keeps coming back unclear stays unpublished until a later run clears it or you choose a different one. No document, photograph, ride detail or contact detail is sent with it. (e) Cloudflare Workers AI, in-app support: when you write to us through in-app support, your message and the recent messages in that conversation are sent to Cloudflare Workers AI, together with the subject of the ticket and a short non-identifying summary of your account state (for example whether your documents are complete, whether a subscription is active, how long ago you signed up, and whether the account is under restriction), so that a first reply can be drafted or the ticket classified and passed to a person. Your name, phone number, email address and home address are not sent. (f) Cloudflare Workers AI, drafting a reply to a payment dispute: when a member of our team drafts our response to a disputed payment, the claim text and the ride details it concerns are sent to Cloudflare Workers AI to produce a draft, which a person then edits and sends. (g) The share-trip live map: when you share your trip, the link opens a page served from Cloudflare, and the live view is driven by a Cloudflare Worker and Durable Object that we operate. While the trip is running we forward to it the Driver’s current position, the estimated time of arrival, the Driver’s first name and the vehicle registration, keyed to a short-lived link code, and it passes those to whoever holds the link. Whoever holds the link is also shown the vehicle’s SPSV licence number, which the page fetches from our own API rather than from that Worker, so a link holder sees the Driver’s first name, the vehicle registration and the SPSV licence number alongside the live position and the arrival time. The positions are relayed rather than filed: the only thing that Worker keeps after the trip is a marker that the trip has ended, which is what makes the link stop working. (h) Rendering evidence packs: when our team prepares the evidence pack for a disputed ride, the assembled document, which contains the ride details and its route, is sent to a Cloudflare Worker we operate to be turned into a PDF. The PDF is stored in our own file storage in Ireland. (i) Cloudflare Turnstile: the web forms anyone can reach without an account (a guest booking request on a Driver Page, and business-portal sign-up and sign-in) show a security check to keep automated abuse out, and Cloudflare receives your IP address and the challenge result in order to verify it. Cloudflare acts as our data processor under its Data Processing Addendum; where it processes data outside the EEA this is covered by the EU Standard Contractual Clauses and Cloudflare’s EU-US Data Privacy Framework certification. Cloudflare’s network is global, so none of the purposes above are confined to Ireland, and Section 7 sets out how we treat that.
HERE - route, travel-time and fare-estimate computation. The pickup, drop-off and any intermediate coordinates of a ride are sent to HERE (router.hereapi.com) to calculate the route and duration. HERE acts as our processor and, where it processes data outside the EEA, relies on the EU Standard Contractual Clauses.
MapTiler - map tiles for the in-app map, and part of address search. Map-tile requests, which include the map area being viewed, are served to the apps through our server-side proxy from MapTiler. Address searches are split between two providers by the shape of what you type: eircode-shaped and house-number-led queries go to AWS, and everything else goes to MapTiler, which therefore receives the address text you type. MapTiler is established in Switzerland, a country the European Commission has recognised as offering an adequate level of data protection; it acts as our processor and relies on the EU Standard Contractual Clauses where it processes data outside the EEA.
TomTom - live traffic conditions used to adjust the travel times we quote. Only coordinates are sent, never identity or ride details. TomTom acts as our processor.
Amazon Web Services (AWS) - hosting, databases, file storage, transactional email, push-notification fan-out (Amazon SNS delivers our push notifications to Apple and Google), and Irish address search and reverse geocoding through Amazon Location Service, which receives the address text you type and a coordinate. Our database, our file storage and the application infrastructure that runs the platform are in AWS eu-west-1 (Ireland). AWS Rekognition, called from that same Ireland region, carries out two automated checks on what a Driver uploads: it screens uploaded document images for inappropriate content, and it checks that a Driver profile photograph is a usable portrait showing a single clearly visible face. Neither check identifies anyone. We no longer run automated face comparison against a photo ID, and Section 6.5 explains what happens instead. Content submitted to AWS AI services is covered by an organization-level opt-out that withdraws AWS’s permission to use it for service improvement and to store it outside the selected region.
Meta Platforms Ireland Limited (Meta Pixel) - marketing measurement on our website, only after you choose “Accept all” on the cookie consent bar. The pixel tells Meta that your browser opened a page on fairtaxi.ie and reports certain actions there (a contact-form or beta-programme message, a view of the rider, driver or business page, a tap on an app-store link), together with the page address, the time, your IP address, browser information and the _fbp and _fbc cookie identifiers. It sends no name, email address or phone number, and Meta’s Automatic Advanced Matching is turned off. For the collection of that data on our site and its transmission to Meta, FairTaxi and Meta are joint controllers (Court of Justice of the European Union, Case C-40/17, Fashion ID); Meta is sole controller for what it does with the data afterwards. Section 12 has the detail and Section 7 covers the transfer to the United States.

We may also share data when required by law or to enforce our Terms, including with the NTA, An Garda Síochána, or other regulators.

When a Driver uses the App’s in-App “Navigate” feature, the pickup or destination of the current ride is passed to the third-party navigation app the Driver chooses (for example Google Maps or Waze, or the app the device selects). Those apps are independent controllers, not our processors: their handling of that location is governed by their own privacy policies, and we pass them only the coordinates needed to route the trip, never Rider identity.

6.1 Driver referral programme

If you are a Driver, you can invite other Drivers with a personal referral code, and you can join using another Driver’s code. When you take part, we process data as follows.

What your inviter can see about you. If you sign up using another Driver’s referral code, that inviting Driver sees a short entry for you on their referrals screen: your first name, the date you joined, and your progress toward your first 10 rides. That progress counter is capped at 10 and stops there. Once you have completed 10 rides, the counter is replaced for good by an “Activated” badge and freezes: your inviter never sees the actual number after that, and within the referral programme your inviter never sees anything beyond this. Your inviter does not see your phone number, your photograph, your surname, your earnings, or any of your ride details, at any stage.
You are told this before you confirm. The screen where you enter a referral code shows you your inviter’s first name and tells you, before you accept, that your inviter will see that you joined with their code and your progress to your first 10 rides, and never anything after that, and that you can hide this from them at any time in Settings. Using a referral code is your choice.
You can hide your progress. You can switch on “Hide my progress from my inviter” at any time. Your entry on your inviter’s screen then collapses to a generic “a driver joined” line, shown without your name or your progress. Your activation still counts toward your inviter’s reward, so hiding your progress never reduces your inviter’s rewards, and your own rewards are unaffected by hiding. Because we share this information on the basis of our legitimate interest in running a transparent referral programme, this toggle is also how you exercise your right to object under Article 21 (see section 11); you may also object by emailing privacy@fairtaxi.ie.
Counting rides for rewards. The referral programme rewards completed rides, so we count them. When a Driver you invited completes 10 rides that referral becomes “activated”, earning the inviting Driver a €10 cash reward. Every three activated referrals also adds 30 days of subscription credit to your account, with no upper limit on either reward. Only qualifying paid rides count; cancellation fees, no-show fees, test rides and self-referrals do not qualify. Separately, when you as an invited Driver reach your 30th ride you receive a one-time addition of 30 days of subscription credit. We process these ride counts on the basis of our legitimate interest (Article 6(1)(f)) in operating the referral programme you chose to join; there is no separate contract you sign up to for this.
Paying referral cash rewards. If you nominate a bank account, we collect the account holder name and IBAN separately from Stripe fare-payment setup. We encrypt the IBAN, show a masked account in ordinary screens, and restrict full bank instructions to authorised payment staff. Those staff use the details to make manual bank transfers and reconcile payments, including failures and returns. Cash rewards work with or without a Stripe account. We process the payment details to administer the referral benefit you requested under our Driver Terms (Article 6(1)(b)). Reward and payment records follow our financial-record retention policy, including after closure; closing an account does not forfeit an unpaid reward. Your bank details are never disclosed to referred Drivers or your inviter.
A minimal record kept after account deletion (fraud prevention). Some benefits can be claimed only once: the one-time 30 days of credit you receive on your 30th ride, being counted as an activation for the Driver who invited you, and the founding-members free period. To stop the same person deleting their account and registering again to claim a one-time benefit again, when a Driver deletes their account we keep a single minimal record: a salted, one-way hash of the SPSV driver licence number (not the licence number itself), a few yes/no flags recording which one-time benefits were already used, and the deletion date. We keep nothing else from the deleted account for this purpose, no name and no contact details; the record is designed so that it does not reveal the licence number and is used only to check whether a licence number presented later matches. We rely on our legitimate interest in preventing fraud (Article 6(1)(f)). We keep this record for 7 years, in line with our financial record-keeping retention, and then delete it, and we review the period periodically.

6.2 Guest Driver Page bookings (no account)

A verified, subscribed Driver may publish a FairTaxi-hosted Driver Page and switch on guest bookings. A member of the public can then ask that Driver for a pre-booked ride without a FairTaxi account. This section explains how we handle a guest’s data. We, FairTaxi, are the controller for collecting and verifying the guest’s details and for sending the request to the Driver; the Driver is a separate, independent controller for the ride once they accept it.

What we collect from a guest. First name; the journey (pickup and drop-off, requested time); party and vehicle needs (passenger count, luggage, and the wheelchair-accessible-vehicle option, which a guest turns on with a separate consent, see below); an optional note; and the mobile number the guest verifies over WhatsApp or by SMS. To operate the request and guard against abuse we also process the guest’s IP address and basic device or connection information, on the basis of our legitimate interests (Article 6(1)(f)). We ask the guest not to include health or medical detail in the note. We do not collect a guest’s email, date of birth, or payment card. Verification is inbound only: the guest sends a message to us from their own device, and we attach the verified number only then, so we never send anything to an unverified number and never hold an unverified number.

Why we use it, and our lawful basis.

Purpose	Lawful basis
Taking the steps the guest asked for before a booking is made: verifying the number, and putting the request to the chosen Driver so they can accept, decline or ignore it	Steps taken at the data subject’s request before entering a contract (Article 6(1)(b))
Sending the guest transactional messages about that request (received, accepted, declined, expired, cancelled) and a tracking link	Article 6(1)(b)
Anti-abuse and anti-fraud checks (bot challenge, rate limits)	Legitimate interests in protecting the platform and users (Article 6(1)(f))

We do not use a guest’s number, note or journey details for marketing, and a Driver may not either. We do not rely on consent for the core booking data, because the processing is necessary to deliver what the guest asked for.

Special-category caution. A wheelchair-accessible-vehicle request, or a note, can reveal health or disability information (special-category data under Article 9). We minimise this and we do not leave any of it merely un-relied-on. The wheelchair-accessible-vehicle option is turned on by a SEPARATE consent control (“I agree you may use this to arrange a wheelchair-accessible vehicle”), unbundled from submitting the request. That control is your explicit consent under Article 9(2)(a) to us using that health-related detail only to arrange a suitable vehicle for the ride you asked for. You do not have to give it, and you can withdraw it at any time (Article 7(3); email privacy@fairtaxi.ie), which does not affect anything done before you withdrew. For the free-text note we ask you not to include health or medical detail, and if any is included we remove or mask it before the Driver sees it and do not retain it, so we do not process special-category data through the note. We limit what the Driver sees to what the ride needs.

Where a guest’s data comes from. We collect a guest’s details from the guest directly (the form, and the verified number from the guest’s own WhatsApp or SMS message). The Driver does not receive a guest’s data from the guest: the Driver receives it from us, which is why our Driver Terms place transparency and confidentiality duties on the Driver for it (Article 14).

Who we share a guest’s data with.

The Driver the guest chose sees the first name and the journey details needed to decide on and complete the ride BEFORE they accept it (seeing the offer is how they decide); the raw phone number is withheld by default. If the chosen Driver cannot take the trip after accepting, we may offer it to other licensed Drivers so the guest still gets their ride. Each Driver is an independent controller for the ride and is bound by our Driver Terms to use the guest’s data only for that ride, keep it confidential, not reuse it, and delete it afterwards.
Meta Platforms (WhatsApp), when the guest verifies over WhatsApp, processes the guest’s verification message and any status reply. WhatsApp acts as our processor for that message content (under the WhatsApp Business Terms of Service and Business Data Processing Terms, the business is the controller and WhatsApp is the processor). WhatsApp’s Cloud API retains message content for at most 30 days and deletes it within 30 days of the last delivery status.
The mobile carriers, when the guest verifies by SMS: the guest’s text to us and our texts back travel over the sending and receiving mobile networks. Carriers are independent telecommunications operators with their own legal obligations, not our processors. No third-party messaging provider is involved on the SMS channel (see “Verifying by SMS instead of WhatsApp” below).
Our hosting and dispatch providers (see Section 6), on the same processor terms as the rest of the platform.

Transfer outside the EEA. When a guest verifies over WhatsApp, the message content is processed by Meta in the United States. WhatsApp Ireland Limited relies on the EU-US Data Privacy Framework for that transfer to WhatsApp LLC in the US, and both WhatsApp LLC and Meta Platforms, Inc. are self-certified under the EU-US Data Privacy Framework. WhatsApp Ireland also reserves the Standard Contractual Clauses (processor-to-processor, Module 3 of Commission Decision 2021/914) as an alternative safeguard. See Section 7. You can ask us for a copy of the safeguard at privacy@fairtaxi.ie.

Verifying by SMS instead of WhatsApp. Where the booking page offers it, a guest can verify by ordinary text message (SMS) instead of WhatsApp: the guest texts the one-time code to a FairTaxi number from their own phone, and we then send the transactional messages for that request (the verification confirmation with the tracking link, and accepted, declined, expired or cancelled updates) by SMS to the verified number. These are short, fixed-wording notifications; they never contain the guest’s name, addresses or note. No third-party messaging provider is involved on this channel: texts are sent and received through FairTaxi’s own SMS gateway, software we operate ourselves on our own server in Germany (in the EEA, hosted with Hetzner) together with a FairTaxi-controlled handset, so SMS verification involves no transfer of message content outside the EEA by us. The texts travel over the sending and receiving mobile networks in the ordinary way; SMS is not an encrypted medium, and the carriers apply their own retention, which is outside our control. We do not store or log the content of texts a guest sends us. Our gateway server keeps an outbound message’s number and text for at most 24 hours, our delivery queue holds a message for at most 5 minutes, and our delivery logs keep a masked form of the number and no message text for 90 days. Everything else in this section (what we collect, why, retention, rights, anti-abuse digests) applies to an SMS guest exactly as it does to a WhatsApp guest. An opt-out applies to the phone number itself, so texting STOP stops FairTaxi guest-booking messages to that number on both SMS and WhatsApp.

How long we keep a guest’s data.

A request that is never accepted (unverified, expired, declined, or cancelled) is deleted within 30 days.
An accepted trip becomes a dispatch and ride record. We then remove the guest’s identifying details (name, number, tracking token) and keep the pseudonymised ride record under the 7-year ride-history rule in Section 5, for legal claims, audit and tax record-keeping.
Data attached to an open complaint, dispute or safety case is kept until the case closes; that is the only reason a never-accepted request is held past 30 days.
A safety report filed from the tracking link. If a guest reports a safety concern about a trip, we keep the report on two clocks. The written part (what the guest wrote, any callback number they chose to leave, and our own case notes about it) is deleted 12 months after the case is closed, or 12 months after the report was filed if it was never opened as a case; this is the same 12-month period we apply to other trip-linked free text in Section 5. What remains after that is a record with no written detail in it: the report category, the internal reference numbers, the driver the report was about, and the dates. That record is kept for 7 years from the same point, alongside the trip and dispute records it belongs to, and is then deleted. If a legal hold is in place because a complaint, dispute, insurance claim, Garda matter or National Transport Authority matter is still live, we keep the whole report until that ends, whatever its age.
We keep a pseudonymous record that a request was made and how it was handled, with your name and number removed, as our dispatch and accountability record; it does not identify you and is not the 30-day data above.
For abuse prevention we keep one-way keyed digests of a sender’s number, not the number itself, in our rate-limiting store for up to the lockout windows (hours, and at most 24 hours for a repeated-abuse lockout); these are pseudonymised anti-abuse data and are separate from the 30-day deletion above.
The verification token expires in 15 minutes; the WhatsApp message is deleted by WhatsApp within 30 days of the last delivery status; a text handled by our own SMS gateway is removed from it within 24 hours.

A guest’s rights, without an account. A guest has the same rights as any other person whose data we hold: access, rectification, erasure, restriction, objection, portability, and withdrawing a consent (see Section 11). Because a guest has no account, we act on a request using the number or link you already have (the verified number, on WhatsApp or by SMS, or the tracking link):

From the verified number (a WhatsApp message, or a text to the FairTaxi number you verified with): message DELETE to erase the guest’s details; we ask you to confirm before erasing. Message STOP at any time to stop receiving messages about your request, and START to receive them again. Texting STOP does not cancel a booking; to cancel, use the tracking link.
From the tracking link we sent for the request: use the “See or delete my details” action on that page.
Or email privacy@fairtaxi.ie. We may ask for a little more information only where we have a reasonable doubt about identity (Article 12(6)). We respond within one month, and can extend by up to two further months for complex or numerous requests, telling you if we do (Article 12(3)).

When a guest asks us to erase their details, we invalidate any live tracking link and verification token first, then delete or anonymise the record; where we must keep a ride record with your name and number removed, we tell the guest in plain language which details we keep and why.

Automated checks, and no significant automated decisions. We do not make a solely-automated decision about a guest that produces a legal or similarly significant effect. Our automated anti-abuse checks (a bot challenge and rate limits) may block or slow a submission that looks automated or abusive, but they do not decide your booking: whether to accept a request is the Driver’s decision. If an anti-abuse check stops you in error, contact us and a person will look at it (Section 8).

Age. This service is not for under-18s, consistent with Section 10 and our Rider Terms. A guest confirms they are at least 18 when they submit a request (see the booking-request terms).

Complaints. A guest can complain to us at complaints@fairtaxi.ie, and has the right to complain to the Data Protection Commission (www.dataprotection.ie) about how we handle their data. For the ride or the fare, a guest can also complain to the National Transport Authority.

6.3 Safety reports about a Driver

This section is written for Drivers. A guest who books a trip through your Driver Page can report a safety concern about that trip from the tracking link we sent them, and a report names the Driver the booking was assigned to. We publish this so that a Driver can read what we hold and what they can do about it, whether or not we have written to them about a particular report.

When a report can be filed, and what we record. A report can be filed only from the tracking link we sent for a particular booking request, and only about that booking. A report records: the category the guest chose (dangerous driving, harassment, vehicle condition, accident, or other); what the guest wrote, up to 2000 characters; a callback number if the guest chose to leave one; the Driver assigned to the booking at the time, which is how the report comes to name you; the internal reference numbers for the booking and for the guest; and the dates. We ask the guest for nothing else, and a report is never attached to a Driver who was not assigned to that booking.

Why we hold it, and our lawful basis. We are the dispatch operator (NTA licence DH12674). Regulation 63(4) and 63(5) of S.I. No. 33/2015 (the Taxi Regulation Act 2013 (Small Public Service Vehicle) Regulations 2015) require us to operate a consumer complaints procedure that effectively addresses complaints from users of our booking service, and to keep records of bookings and complaints and produce them to the National Transport Authority promptly on request. Recording a report, addressing it, and keeping the record producible is therefore a legal obligation (Article 6(1)(c) GDPR). Where a report describes danger to a person, we also act to protect vital interests (Article 6(1)(d)). Looking at reports about the same Driver together, and deciding whether to withdraw dispatch access or switch guest bookings off, rests on our legitimate interest in the safety of riders and of other Drivers (Article 6(1)(f)), which Section 12A.7 of the Driver Terms reserves.

Three of the five categories describe conduct that can amount to a criminal offence, so we treat a report as data relating to alleged offences under Article 10 GDPR. Our authorisation to process it is Section 55(1)(b)(v) of the Data Protection Act 2018, processing “otherwise authorised by the law of the State”, the authorising law being Regulation 63(4) and 63(5) above, which Regulation 64 makes a penal regulation. A report is an allegation by a member of the public. It is not a finding that you did anything, and we do not record it as one.

No automated decisions. Nothing happens to you automatically because a report was filed. Every step, including any decision to suspend dispatch to you, is taken by a person.

Who reads it, and who we may give it to. Each report is emailed to complaints@fairtaxi.ie and read by the holder of that mailbox, who is our triage owner. We may disclose a report to the National Transport Authority, on request under Regulation 63(5) or in an NTA complaint about the trip; to An Garda Síochána, where a report suggests a crime or danger to a person; and to an insurer, a legal adviser or a court, where a claim or proceedings arise from the trip. We do not publish reports, we do not show them to riders or to other Drivers, and nothing about them appears on your Driver Page.

How long we keep it. These are the same periods we publish to guests in Section 6.2.

The written part of a report (what the guest wrote, any callback number they left, and our own case notes about it, including anything you send us in answer) is deleted 12 months after the case is closed, or 12 months after the report was filed if it was never opened as a case.
What remains after that is a record with no written detail in it: the report category, the internal reference numbers, the fact that it named you, and the dates. That record is kept for 7 years from the same point, alongside the trip and dispute records it belongs to, and is then deleted.
If a legal hold is in place because a complaint, dispute, insurance claim, Garda matter or National Transport Authority matter is still live, we keep the whole report until that ends, whatever its age.

We tell you about a report by default. Where we hold a report that names you, we will normally write to you within one month of receiving it, at the email address on your Driver account. We tell you that a report exists and names you, its category, the date it was filed, that it came from a guest who booked you through your Driver Page, why we hold it, who may see it, how long we keep it, your rights, and how to reach us. We may withhold part of that, and in a narrow case all of it, where an exemption in the Data Protection Act 2018 applies to that particular report:

Section 60(3)(b), which covers an expression of opinion given to us in confidence. This is why we will not normally give you the guest’s identity or the words they wrote.
Section 60(3)(a), where telling you would prejudice the prevention, detection, investigation or prosecution of an offence, or a claim or legal proceedings.

We decide this report by report, never as a blanket policy, and we record the reason and the date whenever we withhold anything. A restriction lasts only as long as its reason does: if the case closes with no Garda referral and no claim, the reason falls away and the notice becomes due.

Asking us what we hold, correcting it, and adding your side. You can ask at any time what safety reports name you, by emailing privacy@fairtaxi.ie. We respond within one month, and can extend by up to two further months for complex or numerous requests, telling you inside the first month if we do.

Access. We give you the category, the dates, the purposes and lawful basis, the recipients, the retention periods and the legal-hold override, the source, your rights and the Data Protection Commission route, for every report that names you. We may withhold the guest’s identity and the narrative where Section 60(3)(b) applies, and where we withhold something we tell you that we have.
Correction. If something we recorded ourselves is factually wrong, for example the wrong Driver, the wrong booking, the wrong date or the wrong vehicle, we correct it and tell you what we changed.
Your side of it. We cannot rewrite what a guest told us, because the record is a record that the allegation was made. What you can do is answer it. Send us your account and we attach it to the case, and from then on it goes out with the report: any production to the National Transport Authority, An Garda Síochána, an insurer or a court includes it. Your answer is kept with the case for as long as the written part of the report is kept, and is deleted at the same time it is, so it survives exactly as long as the words it answers.
Disputed accuracy. If you tell us you dispute the accuracy of a report, we record that with the case while we check it. While it is recorded as disputed, we do not act on that report: on its own it does not contribute to a dispatch suspension, to switching your guest bookings off, or to a pattern count, and we do not cite it to anyone else without your answer attached. We continue to store it, and to produce it where the law requires. We tell you before we lift the marking.
Erasure and objection. Erasure does not reach a record we are required to keep under Regulation 63(5) or that we need to establish, exercise or defend a legal claim (Article 17(3)(b) and (e)); where that is the position we say so plainly. You may object to the parts we do on the legitimate-interest basis above, and we handle that on its merits.

Complaints. If you are unhappy with how we handle a report about you, contact privacy@fairtaxi.ie or complaints@fairtaxi.ie. You also have the right to complain to the Data Protection Commission (www.dataprotection.ie); the contact details are in Section 11.

6.4 Repeat card disputes (chargeback pattern review)

If the same payer disputes card payments to us more than once, we may open an internal review so that our team can look at the pattern and decide whether anything should be done about it. This section sets that processing out in full.

Why we do it. Ride fares are charged directly on the Driver’s own Stripe account, so when a card payment for a ride is disputed the money is taken back out of that Driver’s balance rather than ours, and returned only if the dispute is later resolved in the Driver’s favour. Repeated disputes by one payer are therefore a risk we look at, because the loss falls on Drivers. Driver subscription payments are charged on FairTaxi’s account, so a disputed subscription payment is our own loss. Both are counted, each against the payer who made the payment in question. To be clear about what a review is and is not: it records that a pattern of disputes exists and needs looking at. It is not a finding that you did anything wrong, and raising a card dispute is your right. Many disputes are entirely legitimate, and some are resolved in the payer’s favour.

What opens a review. Two or more card disputes that we can attribute to the same payer within the 180 days ending on the most recent of them. Two disputes further apart than that are treated as two separate events rather than a pattern. 180 days is the look-back period we chose because it comfortably covers the life of a card dispute: the months in which a cardholder can normally raise one, plus the time the dispute and any later stages of it then run. That period bounds a count and nothing else. It is not a retention period, and no data is kept or deleted on that schedule. If a review about the same payer is already open, we do not open a second one; the pattern is already in front of a person. The count is also best-effort: if the check cannot complete when a dispute arrives, no review is opened, and we do not retry it later.

What the review record contains. Which account it is about, the reason (recorded as a fixed code, “repeat card disputes”, not as free text about you), how many disputes were counted, the length of the counting period in days, which dispute triggered it, and the date and time. When the review is closed it also records which of our team closed it, when, the outcome they selected (no action, monitor, or action taken separately), and any note they write. We do not store a risk score, a rating, a probability or any other grading of you. The disputes themselves are read from the payment records at the time of the review instead of being copied into it, so a dispute whose result changes later is never shown out of date.

Is this profiling? In the GDPR’s sense, yes, in a limited way: software evaluates one aspect of your behaviour, how often payments you made were disputed, and selects you to be looked at. We say so plainly rather than hide behind the word. What it does not do is score you, rank you, predict anything about you, or decide anything about you. Article 22 GDPR is not engaged, for the reason in the next paragraph but one.

Who a review is about. The account that paid, and never the passenger who simply travelled:

If you paid for a ride with your own card, the review is about you.
If you paid for someone else’s ride as their sponsor, the review is about you as the paying account. It is not about the person you paid for, and a dispute you raise is never attributed to them.
If the ride was paid for by an organisation on a business account, the review is about that organisation, which is a company rather than a person, and not about the individual member who booked or travelled. The disputes it is drawn from still identify the rides they relate to, so a member’s ride can be visible to the reviewer through the underlying dispute record even though the review is not about that member.
If a Driver disputes a subscription payment, the review is about that Driver.
Guest bookings made through a Driver Page cannot appear here at all. They are settled in cash, so there is no card payment and there can be no card dispute.

If our records do not let us establish which account paid, that dispute is left out of the count altogether. We would rather count a pattern too low than attribute a dispute to the wrong person.

What a review does, and does not, do. Opening one does a single thing: it places an entry in a queue that our team read. By itself it does not suspend or restrict your account, block or limit your bookings, stop you paying by card, change your rating, or reveal anything to Drivers or to other users, and it changes nothing that you or anyone else can see in the App. If we go on to take any action, that decision is made by a person under the process that governs that action, for example our dispute process or suspension under the Terms, and it is that process, not this one, that records it and tells you about it.

Automated decision-making. A review is not a decision based solely on automated processing within the meaning of Article 22 GDPR, because the entry itself produces no legal effect and nothing else that significantly affects you: it only puts a pattern in front of a person. The requirement that a person decide anything that does follow is a further safeguard on top of that. See also Section 8.

Our lawful basis. Legitimate interests, Article 6(1)(f) GDPR: preventing and detecting fraudulent and abusive use of card payments on the platform, and protecting Drivers from losing fares they have already earned. Recital 47 GDPR recognises fraud prevention as a legitimate interest of a controller. We have assessed that interest against your interests and rights, and the processing is deliberately built to keep that balance: it holds a count and the inputs to it rather than a score or a judgement about you, it produces no consequence of its own, and a person must decide before anything at all happens.

Who sees it. Authorised members of our own team. A review is not shared with Drivers, with other Riders, with other members of an organisation, or with anyone outside FairTaxi, and we do not report it to a credit reference agency, a fraud-prevention database or any other third party. Like everything else in our systems it sits in the databases and storage our hosting providers run for us as our processors, which are named in Section 6 and act only on our instructions; no other processor receives it. The dispute notifications that feed the count reach us from Stripe as part of payment processing (Section 6); nothing about a review travels back the other way. Access to the review queue is recorded in our internal admin audit log.

How long we keep it. As set out in Section 5: a review has no purge schedule of its own, we keep it for as long as we keep the account records it belongs to, and it goes when that account record or the dispute that triggered it is deleted. Closing your account or asking us to erase your data anonymises the account record it points at rather than removing it, so the review no longer shows a name, email address or phone number, but it stays linked to that record and we go on treating it as personal data.

Your rights, and how we handle them here. Every right in Section 11 that can apply to this processing does apply. What each one means for a review, specifically:

Access. You can ask us at any time whether a review exists about you and what it records, by emailing privacy@fairtaxi.ie, and we answer within the timeframe in Section 11. In a narrow case we may withhold part of an answer, or exceptionally the fact that a review exists at all, where an exemption in the Data Protection Act 2018 applies to it, in particular section 60(3)(a), where telling you would prejudice the prevention, detection, investigation or prosecution of an offence or the defence of a legal claim. We do that only where it is necessary and proportionate for that purpose, case by case and never as a blanket policy, we record the reason and the date, and wherever we can do so without defeating the purpose we tell you that we have withheld something.
Rectification. If what we recorded is factually wrong, for example a dispute counted against the wrong payer, tell us and we will correct it.
Objection. Because this processing rests on our legitimate interests, you may object to it under Article 21 GDPR. We consider an objection on its merits and answer you. While your objection is outstanding we take no action on the basis of the review, and if we cannot show grounds that override yours we stop this processing in relation to you and close the review.
Restriction. While we are verifying an objection or a correction you can ask us to restrict the processing under Article 18 GDPR, and we handle that alongside the request itself: the record is kept, but we do not use it while your request is open.
Erasure. You can ask us to erase a review. We will do so unless we still need it for the fraud-prevention purpose set out above, or to establish, exercise or defend a legal claim, which are the grounds Articles 17(1)(c) and 17(3)(e) GDPR recognise. Where that is our position we say so plainly and tell you why. Section 5 explains what an erasure request does to the account record a review points at.
Portability. Article 20 GDPR covers data you gave us that we process on the basis of consent or of a contract. This processing rests on legitimate interests and the record is one we wrote ourselves, so portability does not apply to it, and nor does withdrawal of consent, since we do not rely on consent here. Your access right above still gives you a copy of what the review holds.
Complaint. You may complain to us, or to the Data Protection Commission, using the details in Section 11.

6.5 Face checks on a Driver’s photograph, and how we verify identity

This section is written for Drivers. It sets out the automated check we run on your profile photograph, what we do instead of automated face matching, and what is left on file from the matching we used to run. It is the section that Section 2.2, Section 3, Section 6 and Section 8 point to.

The profile photograph check. When you upload the photograph that becomes your Driver profile picture, we send the image to AWS Rekognition, which reports whether it holds exactly one clearly visible face and whether the image is bright and sharp enough for that face to be made out. A photograph with no face, with more than one face, with sunglasses, or too dark or too blurred to be usable is rejected automatically and you are asked to upload another. This check counts faces and measures picture quality. It does not identify you, it is not compared against any other image, and it is not biometric identification.

We do not run automated face matching. If you set your account up to be paid in person rather than through Stripe, we verify your identity ourselves, because Stripe is not carrying out its own identity and selfie check for you. That verification is done by a person: a member of our team compares the photograph printed on your photo ID with your profile photograph, and decides. We used to run an automated comparison of the two faces as part of that step, and we have stopped. The platform’s permission to use the face-comparison service has been withdrawn at the account level, so no comparison is performed, no similarity score is produced, and turning it back on would take a deliberate act rather than a routine software release. If we ever did decide to reintroduce it, we would set out the basis for it here first.

What is left from the comparisons that did run. Where the automated comparison ran on a Driver before we stopped it, a record of it stays against that document for as long as the account is open. It holds the outcome, the similarity score the comparison returned, our internal Driver and document references, the type of document and a fingerprint of the file that was compared. It holds no face image, no face template and no reusable measurement of anyone’s face. It is deleted when the account is closed, and it is not carried into the 7-year document retention period in Section 5. A record with the same shape is still written when an in-person Driver uploads a photo ID today, but because no comparison runs it records only that no comparison was available, with no score.

No face database. We do not enrol you, or any Driver, in a face database. We hold no searchable collection of faces, we do not use your photograph to look for you in any other image, and neither the check we run today nor the comparison we ran before was ever used to recognise anyone outside the verification of their own documents.

Our lawful basis, and the part of it we are not claiming. Our licence obligation and our identity check are two different things, and an earlier version of this policy ran them together. Regulation 63 of S.I. No. 33/2015 requires us to dispatch only to a Driver who holds a current SPSV driver licence driving a vehicle that holds a current SPSV licence, and to keep the driver and vehicle list for the National Transport Authority. That is a legal obligation, Article 6(1)(c) GDPR, and it is what we rely on for collecting and checking those licences. It is also the whole of what Regulation 63 requires for this identity and licensing check; the regulation’s other duties, on complaint and booking records, are covered in Section 5. It does not require us to collect a photo ID, it does not require anyone to compare one photograph with another, and it sets no retention period for either. So we do not put the identity check on Article 6(1)(c).

The identity check rests on our legitimate interests, Article 6(1)(f) GDPR: preventing fraud, and confirming that the person who will be driving is the person the licence and the identity document belong to. A Rider is entitled to expect that the licensed Driver who arrives is that person, and the substitution of one person for another is precisely the fraud an identity check exists to catch. Recital 47 GDPR recognises fraud prevention as a legitimate interest of a controller. We have weighed that against your interests: the check happens once, at registration, and only for a Driver whose identity Stripe is not verifying; it is carried out by a person looking at two photographs rather than by software scoring your face; and it produces a decision by a person that you can contest. The profile-photograph quality check in the first paragraph above rests on the same Article 6(1)(f) basis, in its case our interest in a Rider being able to recognise the Driver who arrives. Section 5 explains, separately and on the same Article 6(1)(f) footing, why we keep a photo ID for 7 years and why that period is our choice rather than a statutory one. Because we carry out no face comparison for the purpose of identifying a person, we do not process biometric data within the meaning of Article 9 GDPR in this part of the service.

Your rights here. The rights in Section 11 apply to this processing wherever the conditions attached to each of them are met. You can ask us what we hold about you and ask us to correct it, at privacy@fairtaxi.ie, and you can ask a person to look again at an upload that an automated check rejected.

7. International transfers

Our own systems are in the EEA, in two places rather than one. The database, the file storage and the application infrastructure that hold your personal data run in AWS eu-west-1 (Ireland), and that is where the platform’s records live. Alongside them we run one server of our own in Germany, which computes routes and travel times and carries the SMS gateway; Germany is in the EEA, so nothing about it is a transfer out. Personal data does nevertheless reach processors that are established outside the EEA, or that operate on global networks, and the honest way to describe that is to name them rather than to count them.

Stripe. Payments and payouts. Stripe Payments Europe is established in Ireland; where the Stripe group transfers personal data outside the EEA it relies on the EU Standard Contractual Clauses.
Google (Firebase). Sign-in by SMS one-time code, authentication, crash reporting, analytics where you have opted in, and push delivery to Android devices. Google transfers personal data to the United States under the EU Standard Contractual Clauses.
Cloudflare. Cloudflare’s network is global by design, and every Cloudflare purpose named in Section 6 runs on it: ordinary web and API traffic is served from the point of presence nearest you, the live audio of an in-app voice call may pass through points of presence outside the EEA for the length of the call, and the Workers AI calls and the Workers we operate are handled on that same network. Cloudflare acts under its Data Processing Addendum, the EU Standard Contractual Clauses and its EU-US Data Privacy Framework certification.
Meta (WhatsApp). Where a guest verifies a booking request over WhatsApp, the message content is processed by Meta in the United States, on the safeguards set out in Section 6.2.
Meta (Meta Pixel). Where you have consented to the Meta Pixel on our website, the data it collects is transmitted to Meta Platforms Ireland Limited and processed by Meta Platforms, Inc. in the United States. Meta Platforms, Inc. is certified under the EU-US Data Privacy Framework, and Meta Platforms Ireland Limited relies on that certification for the transfer, with the EU Standard Contractual Clauses as a fallback safeguard. See Section 12.
AWS artificial-intelligence services. The document and photograph images we send to AWS Rekognition go to the service in the Ireland region. Content submitted to AWS AI services is covered by an organization-level opt-out that withdraws AWS’s permission to use it for service improvement and to store it outside the selected region. Everything else we hold in AWS, the documents and photographs in our own file storage included, is in eu-west-1.
Apple. Map rendering in the iPhone Apps and push delivery to iPhones, including the incoming-call notification for an in-app voice call. Apple receives the map area being viewed, the device’s push tokens and the content of the notifications we send. Apple’s infrastructure is global and Apple Distribution International Limited is established in Ireland; Apple’s transfers of personal data outside the EEA are governed by Apple’s own privacy policy and its published safeguards, which include the EU Standard Contractual Clauses.
Hetzner (Germany). The server we run ourselves for route computation and the SMS gateway. Hetzner Online GmbH is established in Germany and the data stays there, so this is processing inside the EEA and not a transfer out of it. We list it here because Section 6 names it as a recipient of pickup and destination coordinates and it would be misleading to leave a reader with the impression that everything we operate is in Ireland.
HERE. Route and travel-time computation, from coordinates only. HERE Global B.V. is established in the Netherlands; where it processes data outside the EEA it relies on the EU Standard Contractual Clauses.
MapTiler. Map tiles and part of address search. MapTiler is established in Switzerland, which the European Commission has recognised as offering an adequate level of protection, so transfers to it there need no further mechanism; where it processes data elsewhere outside the EEA it relies on the EU Standard Contractual Clauses.

Where any other processor named in Section 6 transfers personal data outside the EEA, we rely on the EU Standard Contractual Clauses or another mechanism permitted by Chapter V of the GDPR. If you want to know which mechanism covers a particular transfer, ask us at privacy@fairtaxi.ie and we will tell you.

8. Automated decision-making and profiling

We do not make solely-automated decisions about you, about your account or about your application that produce legal effects concerning you or similarly significantly affect you. Ride-matching and our fraud and mock-location detection are automated signals, but any adverse outcome (for example reversing a fee or suspending an account) involves human review under our dispute process before it takes effect. Counting a payer’s repeated card disputes and placing that pattern in front of an authorised member of our team (Section 6.4) is automated in the same limited sense, and is the one place where we do a limited form of profiling: the count carries no consequence of its own, and a person decides whether anything follows from it. We do not profile you for marketing purposes.

Some of the automated checks described in this policy can reject a single upload on their own, and we say so rather than leave it implied. If an uploaded document cannot be read, if an uploaded image contains inappropriate content, or if a profile photograph shows no face or more than one face or is too poor in quality to use, that upload is rejected automatically, you are told the reason, and you are asked to provide another. We will not pretend that costs you nothing: until you upload something the checks accept, that part of your application cannot move on. What it is not is a decision about you. No account is approved, refused, suspended or restricted automatically, no application is decided automatically, and every decision on a Driver application, on dispatch access, and on restricting or suspending an account is made by a person. Approving a document is likewise a person’s decision. If you think an automated check has rejected something in error, email privacy@fairtaxi.ie or support@fairtaxi.ie: a person will look at it, you can tell us your point of view, and you can contest the outcome.

9. Security of your data

We apply technical and organisational measures appropriate to the risk, including encryption of data in transit and at rest, access controls on a least-privilege basis, and hosting of our own systems in AWS eu-west-1 (Ireland) and, for the routing and SMS server described in Sections 6 and 7, on our own machine in Germany. Section 7 sets out where processing reaches beyond those places. If a personal data breach occurs that is likely to result in a risk to your rights and freedoms, we will notify the Data Protection Commission, and affected users where required, in line with our legal obligations.

10. Children

The service is not directed at, and is not intended for, anyone under 18. We do not knowingly collect personal data from children. Riders must be at least 18, consistent with our Rider Terms. If we become aware that we have collected a child’s data, we will delete it.

11. Your rights

Under the GDPR and the Irish Data Protection Act 2018, you have the following rights. Each of them applies where the conditions attached to it are met, and several depend on the lawful basis we rely on for the processing in question: portability, for instance, covers data we process on the basis of your consent or of a contract with you, and consent can only be withdrawn where consent is what we relied on.

Access - obtain a copy of your personal data.
Rectification - have inaccurate data corrected.
Erasure - request deletion of your data, subject to legal retention requirements.
Restriction - limit processing in certain circumstances.
Portability - receive your data in a structured, machine‑readable format.
Objection - object to processing based on legitimate interests.
Withdraw consent - where processing is based on consent, you can withdraw it at any time.
Complaint - lodge a complaint with the Data Protection Commission (www.dataprotection.ie).

How to exercise your rights

To exercise any of these rights, email our privacy contact at privacy@fairtaxi.ie. We will respond within one month. If a request is unusually complex we may extend this, and we will tell you if we do. We may need to verify your identity before acting on a request. If you are not satisfied with how we handle your data, you may lodge a complaint with the Data Protection Commission:

Email: info@dataprotection.ie
Phone: +353 0761 104 800
Address: 21 Fitzwilliam Square South, Dublin 2, D02 RD28
Website: dataprotection.ie

12. Cookies, marketing analytics and the Meta Pixel

Our marketing website uses cookieless Cloudflare Web Analytics, which does not track individual visitors and sets no cookies. Our Cookie Statement lists every cookie and similar technology the website uses and explains how to control them.

12.1 Meta Pixel

With your consent, our marketing website loads the Meta Pixel, provided by Meta Platforms Ireland Limited, Merrion Road, Dublin 4, Ireland (“Meta”). It does not load until you choose “Accept all” on the consent bar, and it does not load if you choose “Reject all”. You can change your choice at any time through the “Cookie settings” link in the footer of our marketing pages.

What is collected. When the pixel runs it sends Meta the address of the page you opened, the time, your IP address, information about your browser and device, and the identifiers in the _fbp and _fbc cookies it sets on our domain. It also reports certain actions: sending a message through our contact form, contacting our beta programme, signing up to hear when the rider app launches, viewing our rider, driver or business pages, and tapping a link to an app store. It sends no name, email address or phone number. We have turned off Meta’s Automatic Advanced Matching, so the pixel does not read the fields of our forms.

Purposes. Measuring our advertising (whether people who saw a FairTaxi advertisement on Meta’s services later visited our site or took one of those actions) and building audiences (showing advertisements on Meta’s services to people who have visited our site, and to people Meta considers similar to them).

Lawful basis. Your consent, Article 6(1)(a) GDPR. The cookies themselves are set and read only with your consent under S.I. No. 336 of 2011. Refusing has no effect on your use of the website, and you can withdraw consent at any time; withdrawal does not affect processing that took place before it.

Joint control. For the collection of pixel data on our website and its transmission to Meta, FairTaxi and Meta are joint controllers, following the judgment of the Court of Justice of the European Union in Case C-40/17 (Fashion ID). Meta’s Controller Addendum, which forms part of Meta’s Business Tools Terms, sets out each party’s responsibilities for that stage. Meta alone decides what it does with the data after it has been transmitted, and is the sole controller for that later processing under its own privacy policy at www.facebook.com/privacy/policy. You can exercise your rights against either of us for the joint stage; contact us at privacy@fairtaxi.ie and we will pass on any request that falls to Meta.

Transfer to the United States. Meta Platforms Ireland Limited transmits the data to Meta Platforms, Inc. in the United States. Meta Platforms, Inc. is certified under the EU-US Data Privacy Framework, and Meta relies on that certification for the transfer, with the EU Standard Contractual Clauses as a fallback safeguard. Section 7 lists this transfer with the others.

Retention. We do not receive or store the raw pixel data; it is held by Meta under Meta’s own retention periods, which Meta describes in its privacy policy. The _fbp and _fbc cookies expire 90 days after they were last refreshed, and we instruct your browser to delete them when you withdraw consent.

Your rights. Your rights under Section 11 are unchanged by any of this. You can withdraw consent at any time using the “Cookie settings” link in the footer of our marketing pages, and you can manage how Meta uses information from websites in your Meta account settings.

12.2 Rider app launch list

If you sign up on our website to hear when the FairTaxi rider app launches, we keep your email address, the time you gave consent, the page you signed up on, any advertising campaign tags in that page’s address (UTM parameters and Meta’s click identifier, fbclid), and the type of browser you used (for example Safari on iPhone, or the Instagram in-app browser). We do not store your IP address: it is used for a moment only to limit repeated sign-ups from one connection, and Cloudflare Turnstile checks that the sign-up comes from a person.

Purpose and lawful basis. To email you when the rider app is available. Your consent, Article 6(1)(a) GDPR, given by ticking the box on the form. We look at the campaign tags and browser types only in aggregate, to see which advertisements bring sign-ups.

Where it is held and for how long. In a Cloudflare D1 database located in the European Union, with Cloudflare as our processor. We keep it until six months after the rider app launches and then delete it, or sooner if you unsubscribe.

Unsubscribing. Every email we send you carries an unsubscribe link, and using it deletes your email address from the list at once. You can also withdraw consent at any time by writing to privacy@fairtaxi.ie.

13. Changes to this policy

We may update this Privacy Policy. Material changes will be notified via the App or email.