Running a two-sided mobility marketplace means personal data never sits still. Riders hand over credit cards. Hosts upload government IDs. Every booking adds pickup signatures, and every smart lock streams live GPS coordinates back to your servers. Under the EU General Data Protection Regulation (Regulation (EU) 2016/679), that traffic makes your platform heavily accountable, and the fines scale with the damage. Severe infringements run up to 20 million euros or 4% of global annual turnover. Smaller procedural slips still cost up to 10 million euros or 2% of turnover under Article 83(4).
You can keep every dispatch feature live, though. The real work is legal bases, vendor contracts, and honest data boundaries between you, your riders, and the hosts who supply the fleet.
Who Controls What? Marketplace Roles Under GDPR
Founders make the same mistake constantly. They label the platform a simple processor and claim the local bike shop is the sole controller.
Regulators reject that argument.
The EDPB guidance on controller and processor concepts defines a controller as whoever determines the purposes and means of processing. Now look at what your marketplace actually does. It sets user verification rules, manages rider accounts, and runs the billing. That's controller work, which makes you an independent controller in your own right.
Thing is, the bike shop renting out the cargo bike is a controller too. They need the rider's name, phone number, and rental duration to hand over the physical hardware and verify liability.
Two controllers, one shared pool of personal data. That's joint controllership under Article 26.
Article 26 demands a transparent written agreement between you and the host. The document settles who handles data subject access requests, who updates the privacy notice, and who responds when a breach hits. It also has to name the primary contact for riders. Leaving customer privacy to the host's discretion is not a defensible arrangement.
Lawful Basis for Every Mobility Touchpoint
Article 6 is blunt about this: no collection without a valid legal ground. Broad consent checkboxes won't carry daily marketplace operations either, because a rider can't freely refuse consent when the rental depends on it.
Here's how the recurring touchpoints break down:
| Marketplace Activity | Data Categories | Lawful Basis (Article 6) | Practical Requirement |
|---|---|---|---|
| Account creation and booking | Name, email, phone number, payment token | Contract (Article 6(1)(b)) | Necessary to execute the rental agreement. |
| Identity and license verification | ID photo, selfie, birth date | Legal obligation or Legitimate interest | Prevent vehicle theft and confirm minimum rider age. |
| Real-time GPS and anti-theft tracking | Live coordinates, lock status, route history | Legitimate interest or Consent | Requires balancing test; disclose tracking prominently. |
| Marketing promotions and newsletters | Email, browsing behavior, promo code usage | Consent (Article 6(1)(a)) | Freely given opt-in; no pre-ticked boxes allowed. |
| Host payout and tax reporting | Bank account details, tax ID, business address | Legal obligation (Article 6(1)(c)) | Retained for statutory bookkeeping periods. |
| Crash investigation and claims | Incident telemetry, damage photos, police reports | Legitimate interest or Legal claims | Restricted access; stored until statute of limitations expires. |
Watch the rows resting on legitimate interest. Both identity checks and GPS tracking only survive that basis if you run a documented balancing test before launch.
Telematics, GPS, and the Article 35 DPIA Trigger
Live location data punishes careless handling.
Operators get this wrong in a predictable way. They treat a GPS ping from an electric cargo bike as machinery telemetry, something that belongs to the vehicle instead of the person riding it.
That's backwards. The Dutch DPA vehicle tracking insights make the point directly: coordinates from connected vehicles link straight back to the specific rider. One route reveals where that customer lives, where they work, and which medical clinics or religious centers they visit. The moment a location log ties to a rider booking, the telemetry is personal data.
Turns out, Article 35 already anticipates this exact risk. Processing that poses a high risk to individual rights mandates a Data Protection Impact Assessment (DPIA), and the ICO guidance on DPIA requirements counts systematic monitoring of publicly accessible areas and combined data sets among the triggers. Continuous route tracking across a rental fleet clears that bar without much debate.
So if your software records continuous rider routes rather than just start-and-end geofence points, run the formal DPIA before deployment. Put three things in writing:
- Why continuous tracking is strictly necessary for vehicle recovery.
- How long raw coordinates stay in active databases.
- The point where raw telemetry converts into aggregated statistics.
The Data Processing Chain and Vendor Contracts
Your marketplace leans on outside software to function. Payment gateways, SMS dispatch alerts, cloud databases, customer support desks, IoT device bridges: every one of these third parties is a data processor.
Under Article 28, each one needs a Data Processing Agreement (DPA) before customer data moves. The contract binds the processor to follow your instructions, maintain strict technical security, assist with user rights requests, and notify you of data breaches without undue delay. No DPA means no data. It's a hard line, and it should be.
The duty travels down the chain too. The EDPB guidelines on data processing chains put audit responsibility for every sub-processor back on you, so when a telematics provider hosts on a cloud outside Europe, that link is yours to verify.
Cross-border transfers need their own mechanism. When EU rider data reaches analytics services or customer support platforms outside the European Economic Area, marketplaces commonly rely on the European Commission guidance on Standard Contractual Clauses (SCCs), the standard route since the Schrems II ruling. Signing alone isn't enough. The clauses require a Transfer Impact Assessment (TIA) confirming that surveillance laws in the receiving country can't override your safeguards, and if a vendor can't guarantee protection against bulk government data requests, supplementary technical measures come into play. Client-side encryption where only you hold the keys is the usual fix.
Rider Rights Versus Fleet Protection
To be honest, erasure requests are where rental operations hit real friction.
Run the scenario. A user downloads the app, rents an e-bike for an afternoon, returns it, and immediately submits a deletion request. Article 17 gives them that right to erasure, the right to be forgotten, and the request is valid.
The instinct is to wipe the whole profile. Don't.
Article 17(3) lists explicit exemptions. Data still necessary to comply with a legal obligation, or to establish, exercise, or defend legal claims, can stay right where it is.
And think about what actually surfaces after a rental closes: an accident report, or frame damage nobody noticed until routine maintenance three days later, or a traffic violation ticket that arrives from city authorities four weeks down the line, and by then the rider record is already gone if somebody pressed delete on day one, which leaves your platform absorbing the full financial hit for missing hardware and municipal penalties.
The practical fix separates active marketing profiles from retained legal archives. When an erasure request lands, delete marketing profiles, saved search histories, and app usage metrics on the spot. Move identity records, signed rental terms, and timestamped booking receipts into a restricted archive with strict access controls. Tie that archive to an automated deletion schedule built on local statutory limitation periods, such as three years for commercial contract disputes or six to ten years for tax invoices. Then tell the rider, plainly, why certain records sit in cold storage.
Implementation Checklist for Marketplace Operators
None of this is a one-time legal review. It's steady engineering routine, and it works best as a sequence:
- Maintain an Article 30 Record of Processing Activities (ROPA). Document every data flow: what you collect from riders, what you collect from fleet hosts, where data is stored, and who receives it.
- Draft clear Article 26 joint controller terms. Add a specific data-sharing schedule to your host onboarding contract and define whether the platform or the host handles physical identity checks and customer disputes.
- Audit third-party SDKs and plugins. Inspect the mobile app and website for hidden trackers, and remove any marketing pixel transmitting rider location or IP addresses before consent is granted.
- Configure minimum data retention rules. Telematics logs should drop precision once a ride finishes: strip exact street coordinates down to broad trip zones for analytics and purge raw second-by-second telemetry within 30 days unless an active insurance claim exists.
- Establish a 72-hour breach response runbook. Article 33 gives you 72 hours from the moment you become aware of a breach to notify supervisory authorities, so run a dry test with your engineering lead and decide in advance who isolates the database and drafts the initial notification.
- Train operations staff and host support agents. An email from a rider asking what data you hold is a Subject Access Request (SAR) that starts the 30-day statutory clock under Article 12, and your customer-facing team needs to recognize one on sight.
Next Steps for Your Rental Platform
Take thirty minutes this week and map your actual data intake. Pull up the rider registration screen on a phone and read every required form field. If onboarding demands a home address before a user has even reserved a bike, cut the field out. The easiest data to protect under GDPR is the data you never collect in the first place.