Datenschutzerklärung — directtransfer.ch

0Über dieses Dokument

Dies ist die Datenschutzerklärung der institutionellen Website directtransfer.ch sowie der DirectTransfer-Applikationen (Fahrgast und Fahrer), betrieben von der Plattform, einschliesslich des Cargo-B2B-Moduls. Sie beschreibt, welche Personendaten wir bearbeiten, zu welchem Zweck, auf welcher Rechtsgrundlage, mit wem wir sie teilen, wie lange wir sie aufbewahren, und welche Rechte Ihnen nach dem schweizerischen Bundesgesetz über den Datenschutz (DSG/nDSG) zustehen.

Übersetzungshinweis: die nachfolgend zitierten Artikel des schweizerischen Bundesgesetzes über den Datenschutz (Datenschutzgesetz, DSG/nDSG; englisch *Federal Act on Data Protection*, FADP; französisch *Loi sur la protection des données*, LPD) beruhen auf der konsolidierten Fassung, veröffentlicht durch den Bund auf Fedlex (SR 235.1), Stand 2025-07-07. Massgeblich für den deutschsprachigen Raum ist stets der amtliche deutsche Gesetzestext (DSG/nDSG); wo diese Politik zusätzlich die englische Kurzbezeichnung "FADP" verwendet, geschieht dies ausschliesslich zur Konsistenz mit dem portugiesischen Ausgangsdokument dieser Politik.

1Wer wir sind und was dieses Dokument abdeckt

DirectTransfer wird von der Plattform ("wir", "die Plattform", "DirectTransfer") betrieben, welche als Verantwortliche im Sinne von Art. 5 al. j FADP für die in dieser Erklärung beschriebenen Zwecke Personendaten bearbeitet.

Identität: DirectTransfer, eine in der Schweiz aufgebaute Fahrplattform. Umsetzungsstand, präzise: Firmenname, eingetragener Sitz und Handelsregisternummer (UID) werden in dieser Erklärung nicht veröffentlicht, solange keine offizielle, überprüfbare Eintragung im Schweizer Handelsregister (Zefix/UID) vorliegt — keine Zuordnung zu einer unbestätigten juristischen Person erfolgt an keiner Stelle dieses Dokuments.
Kontakt für Datenschutzfragen: privacidade@directtransfer.ch.
Zuständige Aufsichtsbehörde: Eidgenössischer Datenschutz- und Öffentlichkeitsbeauftragter (EDÖB), gemäss Art. 4 FADP.

Diese Erklärung gilt für die Website directtransfer.ch, die Fahrgast-App, die Fahrer-App und das Cargo-B2B-Modul, jeweils wenn wir Personendaten einer betroffenen Person im Sinne von Art. 5 al. b FADP bearbeiten.

1.1Was DirectTransfer ist, und was nicht — verbindliche Klarstellung

Diese Klausel wird hier wiederholt, weil sie unmittelbar bestimmt, wie wir Ihre Daten behandeln: DirectTransfer ist Software als Dienstleistung (SaaS). Die Plattform beschäftigt den Fahrer niemals — es besteht kein Arbeitsverhältnis; der Fahrer ist selbst für Fahrzeug, Versicherung und Zeitplan verantwortlich. Die Plattform legt den Fahrpreis niemals fest — der Fahrer bestimmt den Betrag innerhalb einer lediglich vorgeschlagenen Spanne, im Rahmen eines Auktions-/bilateralen Verhandlungsmechanismus. Die Plattform vermittelt die Fahrt niemals finanziell — die Bezahlung der Fahrt erfolgt zu hundert Prozent Peer-to-Peer (P2P) zwischen Fahrgast und Fahrer, per TWINT, SumUp, Bargeld oder eigener Karte des Fahrers; DirectTransfer bearbeitet oder speichert keinerlei Zahlungsdaten der Fahrt. Dies ist getrennt und unterschieden von der monatlichen Abonnementzahlung des Fahrers an die Plattform (Abschnitt 4.9), welche einen anderen Datenfluss darstellt. Diese Unterscheidung bestimmt unter anderem, welche Zahlungsdaten in unserem System existieren und welche niemals existieren werden.

2Relevante Begriffe (Art. 5 FADP)

Wir verwenden die Begriffe des Gesetzes gemäss dessen Art. 5:

Personendaten: alle Angaben, die sich auf eine bestimmte oder bestimmbare natürliche Person beziehen (Art. 5 al. a).
Betroffene Person: die natürliche Person, über die Personendaten bearbeitet werden (Art. 5 al. b).
Besonders schützenswerte Personendaten: umfassen unter anderem biometrische Daten, die eine natürliche Person eindeutig identifizieren, sowie Daten über verwaltungs- und strafrechtliche Verfolgungen und Sanktionen (Art. 5 al. c, Ziff. 4 und 5). Auf unseren konkreten Fall angewandter Hinweis: der bei der Registrierung vom Fahrer eingereichte Identitätsausweis und Führerausweis sowie die daraus vom externen Anbieter der Identitätsprüfung (KYC/IDV) extrahierten biometrischen Daten stellen besonders schützenswerte Personendaten in diesem Sinne nach Ziff. 4 dar — sie werden nicht als gewöhnliche Personendaten behandelt, siehe Abschnitt 7. Der in manchen Kantonen verlangte Strafregisterauszug des Fahrers stellt besonders schützenswerte Personendaten nach Ziff. 5 dar (Daten über verwaltungs- und strafrechtliche Verfolgungen und Sanktionen) — siehe Abschnitte 4.2 und 6.
Bearbeiten: jeder Umgang mit Personendaten — Beschaffung, Speicherung, Aufbewahrung, Verwendung, Bekanntgabe, Archivierung, Löschung oder Vernichtung (Art. 5 al. d).
Verletzung der Datensicherheit: unbefugter oder widerrechtlicher, unbeabsichtigter oder unrechtmässiger Verlust, Löschung, Vernichtung, Veränderung oder Zugang zu bzw. Offenlegung von Personendaten (Art. 5 al. h).
Verantwortlicher: wer allein oder zusammen mit anderen über den Zweck und die Mittel der Bearbeitung entscheidet — die Plattform, für die hier beschriebenen Zwecke (Art. 5 al. j).
Auftragsbearbeiter: wer im Auftrag des Verantwortlichen Personendaten bearbeitet — zum Beispiel der Anbieter der Infrastruktur zur Bildspeicherung, oder der Anbieter der Dokumentenprüfung (Art. 5 al. k).

3Von uns angewandte Grundsätze (Art. 6 FADP)

Jede in dieser Erklärung beschriebene Bearbeitung folgt den Grundsätzen von Art. 6 FADP: Rechtmässigkeit (§1); Bearbeitung nach Treu und Glauben und verhältnismässig (§2); Beschaffung nur für einen bestimmten, für die betroffene Person erkennbaren Zweck, ohne mit diesem Zweck unvereinbare Weiterbearbeitung (§3); Vernichtung oder Anonymisierung der Daten, sobald sie zum Zweck der Bearbeitung nicht mehr erforderlich sind (§4); Richtigkeit der Daten, mit Berichtigung oder Löschung des Unrichtigen oder Unvollständigen (§5). Wo wir Ihre Einwilligung benötigen, ist diese nur gültig, wenn sie nach angemessener Information freiwillig und für einen oder mehrere bestimmte Fälle erteilt wird (§6); und sie ist ausdrücklich erforderlich für die Bearbeitung besonders schützenswerter Personendaten (§7 al. a).

Methodischer Hinweis zur Zitierung der Rechtsgrundlage in dieser Erklärung: das FADP/DSG kennt keine abschliessende Liste von "Rechtsgrundlagen" nach Art des Art. 6 Abs. 1 DSGVO. Die schweizerische Regelung lautet: die Bearbeitung ist rechtmässig, wenn sie den Grundsätzen dieses Art. 6 (Rechtmässigkeit, Verhältnismässigkeit, Zweckbindung) entspricht und keine Persönlichkeitsrechte der betroffenen Person verletzt (Art. 30); besteht eine mögliche Persönlichkeitsverletzung, so bedarf die Bearbeitung eines eigenen Rechtfertigungsgrundes nach Art. 31, typischerweise "Abschluss oder Abwicklung eines Vertrags" nach Art. 31 §2 al. a (siehe unmittelbare Anwendung in Abschnitt 13). Aus diesem Grund verankert jeder Unterabschnitt von Abschnitt 4 unten die allgemeine Rechtmässigkeit in Art. 6 und beruft sich nur dann auf Art. 31 §2 al. a, wenn tatsächlich eine Rechtfertigung einer möglichen Persönlichkeitsbeeinträchtigung durch Vertragserfüllung vorliegt; ab diesem Abschnitt verweist jeder Unterabschnitt, der diesen Grund anführt, nur kurz darauf ("Rechtfertigungsgrund: Art. 31 §2 al. a, gemäss dem bereits in diesem Abschnitt 3 festgelegten Kriterium"), ohne den vollständigen erläuternden Absatz zu wiederholen. Art. 16-17 FADP betreffen ausschliesslich die internationale Datenübermittlung (Bekanntgabe von Personendaten ins Ausland) und werden nur in Abschnitt 8 zitiert, nie als allgemeine Rechtsgrundlage für die inländische Bearbeitung.

Übersetzungshinweis zu "Rechtfertigungsgrund": das portugiesische Ausgangsdokument verwendet den Begriff "fundamento de justificação" — ein Konzept, das spezifisch zur FADP/DSG-Regelung nach Art. 31 gehört und keine direkte Entsprechung im Vokabular der DSGVO hat. Der Begriff "Rechtfertigungsgrund" (Art. 31) wird hier bewusst als der gesetzliche Fachbegriff der deutschsprachigen DSG-Fassung verwendet und nicht mit dem DSGVO-Begriff "Rechtsgrundlage" gleichgesetzt, da dieser eine andere Konnotation trägt, wie in diesem Abschnitt erläutert.

Quellprüfungshinweis zu "Art. 31 §2 al. a": das Bestehen des Rechtfertigungsgrundes der Vertragserfüllung in Art. 31 §2 wird durch die konsultierte Primärquelle bestätigt (das intern für diese Erklärung geführte Register der FADP-Primärquellen, Teil A, "Art. 30-31"), doch fasst diese Quelle den Inhalt des Artikels zusammen/paraphrasiert ihn — im Unterschied zu Art. 5, 6, 8, 19 und 25, welche wörtliche (verbatim) Kopien sind, per pdftotext aus dem offiziellen Fedlex-PDF extrahiert — ohne den vollständigen, nummerierten Text der Buchstaben von Art. 31 §2 zu zitieren. Der Verweis auf den genauen Buchstaben "al. a" in dieser Erklärung ist daher die wahrscheinlichste, mit dem typischen Aufbau dieser Art von Norm übereinstimmende Lesart, keine wörtlich bestätigte Zitierung des Buchstabens. Die Substanz des Grundes (Vertragserfüllung als Rechtfertigungsgrund einer möglichen Persönlichkeitsbeeinträchtigung) wird in dieser Erklärung mit hoher Zuverlässigkeit verwendet; der genaue Wortlaut des Buchstabens bleibt mit mittlerer Zuverlässigkeit versehen, vorbehaltlich direkter Bestätigung anhand des vollständigen Textes von Art. 31 oder eines Gutachtens eines zugelassenen Schweizer Anwalts — derselbe Vorsichtsmassstab, der bereits auf Art. 9 angewendet wird (siehe das zu diesem Zweck geführte interne Rechtsregister).

4Welche Daten wir erheben und wozu

4.1Kontoregistrierung

Name, Kontaktdaten (Telefon, E-Mail) von Fahrgast und Fahrer, bei Kontoerstellung. Zweck: Erbringung der technologischen Vermittlungsdienstleistung zwischen Fahrgast und Fahrer. Rechtsgrundlage: Rechtmässigkeit, Verhältnismässigkeit und erkennbarer Zweck der Bearbeitung (Art. 6 §1-3) — die Daten werden für den spezifischen, für die betroffene Person erkennbaren Zweck der Erstellung und des Betriebs des Kontos erhoben; Rechtfertigungsgrund: Art. 31 §2 al. a, gemäss dem bereits in Abschnitt 3 festgelegten Kriterium.

4.2Dokumentenprüfung des Fahrers — besonders schützenswerte Daten

Bei der Fahrerregistrierung erheben wir Identitätsausweis, Führerausweis und, je nach Kanton und Kategorie, weitere Bewilligungen (z. B. carte de taxi, carte de limousine). Wo vom Kanton verlangt — zum Beispiel Zürich und Basel, gemäss bereits vorhandener interner kantonaler Regulierungsrecherche des Projekts — erheben wir zudem den Strafregisterauszug des Fahrers, mit einer Gültigkeit von weniger als 3 Monaten zum Zeitpunkt der Einreichung. Diese Dokumente werden per Foto eingereicht, gemäss dem im Modul zur Fahrerregistrierung beschriebenen Ablauf, und in zwei Schichten verarbeitet:

Schicht 1 — externer Anbieter (KYC/IDV): bestätigt die Echtheit des Dokuments und extrahiert die lesbaren Felder (Name, Nummer, Daten, Dokumenttyp), einschliesslich, soweit anwendbar, biometrischer Verifikation. Diese Bearbeitung betrifft besonders schützenswerte Personendaten im Sinne von Art. 5 al. c Ziff. 4 (Identitätsausweis, Führerausweis, biometrische Daten) und, soweit auf den Strafregisterauszug anwendbar, Ziff. 5 (Daten über verwaltungs- und strafrechtliche Verfolgungen und Sanktionen) — was Ihre ausdrückliche Einwilligung erfordert (Art. 6 §7 al. a) zum Zeitpunkt der Dokumenteinreichung, sowie einen Auftragsbearbeitungsvertrag mit dem Anbieter. Diese Pflicht ergibt sich aus der Bearbeitung von Personendaten durch einen Auftragsbearbeiter im Auftrag des Verantwortlichen — Art. 5 al. k FADP definiert den Auftragsbearbeiter in diesen Worten — und ist in die allgemeinen Grundsätze der Rechtmässigkeit und Verhältnismässigkeit von Art. 6 sowie in die Sicherheitspflicht von Art. 8 eingebettet. Diese Erklärung nennt hier keine spezifische Artikelnummer des FADP zur Auftragsbearbeitung über die Definition in Art. 5 al. k hinaus, da dies nicht gegen den vollständigen Gesetzestext bestätigt wurde.
Schicht 2 — internes Regelwerk, ohne künstliche Intelligenz: prüft, ob die extrahierten Felder die dokumentarische Anforderung des erklärten Kantons und der erklärten Kategorie erfüllen. Es wird kein KI/ML-Modell verwendet; es handelt sich um einen deterministischen Abgleich mit einer Konfigurationstabelle.

Ein unsicheres Ergebnis auf einer der beiden Schichten wird niemals automatisch genehmigt oder automatisch abgelehnt — es geht stets an die menschliche Prüfung durch einen Administrator. Dokumente des Fahrers, einschliesslich des Strafregisterauszugs, sind ausschliesslich für den Fahrer selbst und für Administratoren zugänglich, niemals für den Fahrgast, mit derselben verstärkten Behandlung (ausdrückliche Einwilligung, eingeschränktes RBAC), wie in Abschnitt 6 beschrieben.

Erneuerung und laufende Überprüfung: die angewendete Mindestanforderung ist eine Gültigkeit von weniger als 3 Monaten für den Strafregisterauszug zum Zeitpunkt jeder Einreichung; die Ersteinreichung ist nicht als Abdeckung für den gesamten Lebenszyklus des Fahrers zu verstehen. Die erforderliche Erneuerungshäufigkeit und der Mechanismus zur laufenden Überprüfung des Leumunds, soweit je nach Kanton anwendbar, werden dem Fahrer direkt über den Kontaktkanal der App mitgeteilt und in diesem Abschnitt veröffentlicht, sobald die entsprechende operative Richtlinie finalisiert ist.

Externer Anbieter (KYC/IDV): der Handelsname des Anbieters wird in diesem Abschnitt veröffentlicht, sobald die Auswahl abgeschlossen ist, gemäss dem laufenden Offertverfahren; in der Zwischenzeit auf Anfrage über den Kontaktkanal in Abschnitt 15 erhältlich. Der oben erwähnte Auftragsbearbeitungsvertrag mit diesem Anbieter sowie die Bewertung der internationalen Übermittlung (Abschnitt 8), falls der Anbieter nicht auf schweizerischem oder EU/EWR-Gebiet tätig ist, werden zusammen mit dieser Identifikation abgeschlossen und veröffentlicht, bevor eine Dokumenteneinreichung durch diesen Anbieter im Produktivbetrieb verarbeitet wird.

4.3Echtzeit-Standort während der Fahrt

Der ungefähre Standort verfügbarer Fahrzeuge wird dem Fahrgast vor Annahme einer Fahrt mitgeteilt; nach der Annahme wird die Position des Fahrers dem Fahrgast bis zum Einstieg mitgeteilt. Zweck: unmittelbare Erfüllung des zwischen Fahrgast und Fahrer vereinbarten Beförderungsvertrags. Rechtsgrundlage: Verhältnismässigkeit und für die betroffene Person zum Zeitpunkt der Anfrage erkennbarer Zweck (Art. 6 §2-3), da die geografische Positionsoffenlegung gegenüber einem Dritten die Persönlichkeitsrechte der betroffenen Person beeinträchtigen kann; Rechtfertigungsgrund: Art. 31 §2 al. a, gemäss dem bereits in Abschnitt 3 festgelegten Kriterium.

4.4Foto des Abholorts — automatische Löschung nach 24 Stunden

Während der Fahrtkommunikation kann zwischen Fahrgast und Fahrer ein Foto des Abholorts geteilt werden, gespeichert auf Cloudflare R2.

Das bereits eingefrorene Lifecycle-Design des Projekts sieht die automatische Löschung dieses Fotos 24 Stunden nach dem Hochladen vor, und keine Aufbewahrung über diese Frist hinaus für einen sekundären Zweck — gemäss dem internen Datenschema-Design des Projekts, das dieses 24-Stunden-Fenster als zur Abfragezeit abgeleitet festlegt (created_at + interval '24 hours') für Nachrichten vom Typ photo. Umsetzungsstand, präzise: der Backend-Dienst der Plattform besteht und ist für die Fahrerregistrierung in Betrieb, das Fahrt-/Chat-Modul, das dieses Zeitfenster durchsetzen würde — ein applikationsseitiger Bereinigungsjob und/oder eine Lifecycle-Regel des Cloudflare-R2-Buckets — wurde jedoch noch nicht gebaut; und, was die Datenbankschicht betrifft, steht die endgültige Ratifizierung der entsprechenden datenbankseitigen Sicherheitsrichtlinie durch die interne Sicherheitsprüfung der Plattform weiterhin aus. Bis dieses Modul gebaut und diese Ratifizierung abgeschlossen ist, sind die hier beschriebenen 24 Stunden das verbindliche Design des Projekts, noch keine im Produktivbetrieb überprüfbare operative Tatsache.

Zweck: das physische Treffen zwischen den Parteien zu erleichtern. Rechtsgrundlage: Vertragserfüllung und Verhältnismässigkeit (Art. 6 §2-3); die oben beschriebene automatische Löschung nach 24 Stunden ist die konkrete Anwendung der Vernichtungspflicht von Art. 6 §4, sobald die Daten für den Zweck nicht mehr erforderlich sind — das Treffen hat bereits stattgefunden; Rechtfertigungsgrund: Art. 31 §2 al. a, gemäss dem bereits in Abschnitt 3 festgelegten Kriterium.

4.5Chat-Nachrichten der Fahrt (`ride_messages`)

Während einer aktiven Fahrt können Fahrgast und Fahrer vordefinierte Nachrichten, begrenzten Freitext (bis zu 100 Zeichen) oder ein Foto über den Fahrt-Chat austauschen. Zweck: direkte Kommunikation zwischen den Parteien während der aktiven Fahrt — zum Beispiel Einstiegsanweisungen, Anpassung des Treffpunkts — während die Fahrt läuft.

Aufbewahrung: die entworfene Lifecycle-Regel ist die effektive Löschung (Hard Delete) des Chat-Inhalts beim Abschluss der Fahrt — eine bereits abgeschlossene Design-Entscheidung des Projekts hinsichtlich des Kriteriums, keine Lücke. Gemäss der internen Sicherheits- und Compliance-Prüfung der Plattform ist dies die direkte Anwendung des Gebots "Kein Chat nach Fahrtabschluss", und diese Regel ist ausdrücklich im internen Datenschema-Design des Projekts festgehalten. Umsetzungsstand, präzise: dieses Schema-Design weist den Bereinigungsjob ausdrücklich dem Backend-Dienst der Plattform zu; der Backend-Dienst besteht inzwischen und ist für die Fahrerregistrierung in Betrieb, das Fahrt-/Chat-Modul, das diesen konkreten Bereinigungsjob ausführen würde, wurde jedoch noch nicht gebaut; die entsprechende datenbankseitige Sicherheitsrichtlinie ist weiterhin nur als interner Entwurf erfasst, ausdrücklich als "STUB, NICHT RATIFIZIERT" gekennzeichnet, ausstehend der endgültigen Ratifizierung durch die interne Sicherheitsprüfung der Plattform. Bis dieses Modul gebaut und diese Ratifizierung abgeschlossen ist, ist die effektive Entfernung (Hard Delete, kein Soft-Delete, ohne "gelöscht"-Markierung) das verbindliche Design des Projekts, noch keine im Produktivbetrieb überprüfbare operative Tatsache.

Rechtsgrundlage: Erfüllung des Beförderungsvertrags zwischen den Parteien und Sicherheit der Koordination der laufenden Fahrt (Art. 6 §2-3); die oben entworfene automatische Löschung beim Abschluss der Fahrt ist die konkrete Anwendung der Vernichtungspflicht von Art. 6 §4, sobald die Daten für den Zweck nicht mehr erforderlich sind — die Fahrt ist bereits beendet; Rechtfertigungsgrund: Art. 31 §2 al. a, gemäss dem bereits in Abschnitt 3 festgelegten Kriterium.

Keine Chat-Nachricht wird von DirectTransfer über das für den technischen Echtzeitbetrieb der Fahrt selbst Erforderliche hinaus gelesen, moderiert oder aufbewahrt; jede punktuelle Einsichtnahme durch einen Administrator im Rahmen der Untersuchung einer formellen Beschwerde folgt demselben auditierten Muster des privilegierten Zugriffs, wie in Abschnitt 12 beschrieben.

Metadaten zu Missbrauchsmeldungen — in Prüfung, nicht implementiert: eine minimale Protokollierung von Metadaten zu Missbrauchsmeldungen (nicht der Nachrichteninhalt) wird geprüft, vorbehaltlich rechtlicher Zitierung vor jeder Implementierung, gemäss der internen Sicherheits- und Compliance-Prüfung der Plattform; im Falle einer Implementierung wird dieser Abschnitt aktualisiert.

4.6Telefonanruf-Kommunikation — natives GSM-Gespräch, kein VoIP

Die Plattform stellt eine Anruftaste zur Verfügung, welche die native GSM-Anruffunktion des Mobiltelefons jedes Nutzers verwendet. Es besteht kein VoIP-System, kein WebRTC und keine Anrufvermittlung durch DirectTransfer — das Gespräch läuft vollständig über das Mobilfunknetz jeder Partei, ausserhalb unserer Infrastruktur.

Für Ihre informierte Einwilligung relevante Offenlegung: durch die Nutzung dieser Taste kann die Telefonnummer jeder Partei zum Zeitpunkt des Anrufs für die andere Partei sichtbar werden, weil das native GSM-Netz aufgrund der Natur des Protokolls selbst beiden Parteien die tatsächliche Ursprungs-/Zielnummer übermittelt — diese Offenlegung lässt sich bei Beibehaltung der nativen Anruftaste nicht vermeiden, gemäss der von der internen Sicherheits- und Compliance-Prüfung der Plattform festgehaltenen technischen Beurteilung.

Was nicht existiert: keine Proxy-Nummer im Netz ersetzt Ihre echte Nummer während des Anrufs — es gibt kein echtes Telefon-Proxy/-Relay; unter anderem würde ein Relay dieser Art mit dem für dieses Produkt bereits festgelegten Verbot "Zero VoIP" kollidieren.

Was existiert: die App zeigt weder Ihre Nummer noch die der anderen Partei als Text auf irgendeinem Bildschirm der Apps passenger oder driver an — die Nummer erscheint ausschliesslich als Aktions-Taste; und die App verlangt eine ausdrückliche Bestätigung, bevor das native Wählprogramm ausgelöst wird (ein Hinweis, dass die Nummer beim Fortfahren für die andere Partei sichtbar wird). Diese beiden Massnahmen sind Standardverhalten in den Apps.

Hinweis zur Unterdrückung der Anrufer-ID (CLIR): wo verfügbar, hängt die Unterdrückung der Ursprungsnummer durch einen nativen Netzcode (z. B. Präfix #31#/*31#) vollständig vom Telefonanbieter jedes Nutzers ab — die Plattform überprüft, erzwingt oder garantiert diese Unterdrückung vor Auslösung des nativen Wählprogramms nicht. Dies ist keine vom Produkt garantierte Massnahme; sie ist als noch nicht abgeschlossenes Element einer Machbarkeitsprüfung pro Anbieter erfasst, gemäss der internen Sicherheits- und Compliance-Prüfung der Plattform.

Sekundärer Hinweis: die oben beschriebene Bildschirmmaskierung deckt das admin-Backoffice nicht ab, welches bereits über RBAC auf die Tabelle users (Abschnitte 6 und 12) Klartext-Lesezugriff auf die Telefonnummer hat, zu Supportzwecken — dieser privilegierte Zugriff erzeugt zwingend ein Audit-Protokoll (wer, wann, warum); es handelt sich nicht um eine stillschweigende Ausnahme von der Bildschirm-Massnahme.

Wir zeichnen den Inhalt dieses Anrufs weder auf noch speichern wir ihn oder haben Zugriff darauf, da er niemals über unsere Infrastruktur läuft.

Rechtsgrundlage: die Informations- und Transparenzpflicht nach Art. 19 §2 al. c FADP, welche verlangt, die betroffene Person zum Zeitpunkt der Datenerhebung über "die Empfänger oder Kategorien von Empfängern, denen Personendaten bekanntgegeben werden" zu informieren (wörtlicher Text, gemäss dem intern für diese Erklärung geführten Register der Primärquellen, Teil A) — dies ist die von der internen Sicherheits- und Compliance-Prüfung der Plattform identifizierte korrekte konkrete Einordnung für dieses Szenario: die andere Partei der Fahrt ist die Empfängerin, der die Telefonnummer zum Zeitpunkt des Anrufs sichtbar wird, was genau eine Bekanntgabe an einen Empfänger darstellt, nicht die generische Erweiterung von §1 desselben Artikels (Information über nicht bei der betroffenen Person selbst erhobene Daten), die in einer früheren Fassung dieses Textes verwendet wurde; diese Offenlegung wird durch diese Klausel vorab mitgeteilt — sowie die Verhältnismässigkeit der Bearbeitung (Art. 6 §2), zum Zweck, das physische Treffen und die Kommunikation während der Fahrt zu ermöglichen. Rechtfertigungsgrund der Bekanntgabe selbst: Art. 31 §2 al. a, gemäss dem bereits in Abschnitt 3 festgelegten Kriterium — dieser Grund wird durch die obige Neuverankerung nicht berührt, welche sich nur auf die Komponente der Informations-/Transparenzpflicht bezieht. Diese Informationspflicht wird durch die oben genannte ausdrückliche Offenlegung und den obligatorischen Bestätigungsdialog vor Auslösung des nativen Wählprogramms erfüllt. Dies ist die von dieser Erklärung für diese Klausel vorgelegte Rechtsgrundlage — siehe den Bestätigungsstand im folgenden Absatz.

Umsetzungsstand, mit derselben Präzisionsdisziplin, die in dieser gesamten Erklärung verwendet wird: das oben beschriebene Verhalten (Bildschirmmaskierung, Bestätigungsdialog) ist das bereits eingefrorene, verbindliche Design des Projekts für die Apps passenger und driver. Die Aktivierungssperre dieses Ablaufs im Produktivbetrieb hängt gemäss der internen Sicherheits- und Compliance-Prüfung der Plattform nicht vom Backend-Dienst der Plattform ab (dieser Ablauf läuft, anders als jene in den Abschnitten 4.4, 4.5, 4.7, 6 und 12, wie oben beschrieben nie über unsere Infrastruktur) — sie hängt von der Bestätigung der rechtlichen Hinlänglichkeit durch die interne Sicherheits- und Compliance-Prüfung der Plattform ab, ob die obige Einordnung nach Art. 19 §2 al. c + Art. 6 §2 dieses konkrete Szenario hinsichtlich Verhältnismässigkeit angemessen abdeckt. Die oben vorgenommene Neuverankerung der Zitierung auf Art. 19 §2 al. c korrigiert die zuvor in dieser Erklärung als unsicher beschriebene Einordnung: die Offenlegung der Telefonnummer einer Partei gegenüber der anderen Partei während des Anrufs ist eine Bekanntgabe an einen Empfänger zum Zeitpunkt des Anrufs, und genau dieses Szenario — die Pflicht, über "die Empfänger... denen Personendaten bekanntgegeben werden" zu informieren — deckt Art. 19 §2 al. c in seinem wörtlichen Text ab, nicht mehr die generische Erweiterung von §1 (Information über nicht bei der betroffenen Person selbst erhobene Daten), die in einer früheren Fassung dieses Textes verwendet wurde. Diese Erklärung legt Art. 19 §2 al. c + Art. 6 §2 als Grundlage für die oben bereits erfolgte Offenlegung vor; die Hinlänglichkeit dieser Einordnung gegenüber dem Verhältnismässigkeitstest von Art. 6 §2 in diesem konkreten Szenario — zum Beispiel, ob das Fehlen einer Opt-out-Möglichkeit für die Funktion oder einer CLIR-Garantie diese Hinlänglichkeit beeinträchtigt — bleibt eine technisch-rechtliche Bestätigung der internen Sicherheits- und Compliance-Prüfung der Plattform, keine bereits allein durch das interne Rechtsteam abgeschlossene Tatsache. Hinweis zur Abstimmung zwischen Dokumenten: diese Position ist jene dieser Datenschutzerklärung im Besonderen; die parallele Klausel zum selben Thema in den Nutzungsbedingungen folgt ihrem eigenen Aktualisierungszyklus und bleibt in jenem Dokument als ausstehende Zitierung gekennzeichnet — die beiden Dokumente konvergieren noch nicht, und dieser Hinweis vermeidet den Anschein, dass sie bereits konvergieren.

4.7Fahrtverlauf und anonymisierter Bezeichner (zweiphasiges Modell)

Pro Fahrt erfassen wir: Ursprung und Ziel (Koordinaten und Textadresse), Zeitstempel von Beginn und Ende, Fahrzeugkategorie, vom Fahrer erklärter Wert, Endstatus der Fahrt, sowie einen Bezeichner für Fahrgast und Fahrer. Standardmässig werden keine weiteren Daten erfasst.

Dieser Bezeichner funktioniert in zwei unterschiedlichen Phasen, nicht in einer einzigen Phase:

1. Während der aktiven Fahrt: der Bezeichner ist auflösbar (direkter Verweis auf den Nutzerdatensatz), erforderlich für Echtzeitfunktionen — zeilenbasierte Zugriffskontrolle (RLS), Echtzeitverbindung (Socket.io) und den Chat der laufenden Fahrt (Abschnitt 4.5).

2. Beim Übergang in den Verlauf, wenn die Fahrt endet, wird der Bezeichner in einen irreversiblen, gesalzenen kryptografischen Hash umgewandelt (z. B. SHA-256), ohne Fremdschlüssel, der eine Rückverfolgung zur Identität des Nutzers aus dem historischen Datensatz ermöglichen würde.

Die standardmässig entworfene Regel, gemäss Gebot 5 (Row Level Security) und den bereits von der internen Sicherheits- und Compliance-Prüfung der Plattform festgelegten RLS-Anforderungen, ist die gegenseitige namentliche Nicht-Identifizierung zwischen den Parteien: weder soll der Fahrgast den Namen des Fahrers sehen, noch der Fahrer den Namen des Fahrgasts, auf keinem Bildschirm, einschliesslich des Verlaufs. Umsetzungsstand, präzise: diese Regel ist entworfen und im oben beschriebenen zweiphasigen Modell abgebildet (auflösbarer Bezeichner während der Fahrt, irreversibler Hash beim Übergang in den Verlauf), doch der ausführbare Durchsetzungsmechanismus — konkrete datenbankseitige Sicherheitsrichtlinien und die Spaltenmaskierungsschicht, die ein Identitätsleck selbst dann verhindert, wenn die Zeile sichtbar ist — hängt von der endgültigen technischen Ratifizierung durch die interne Sicherheitsprüfung der Plattform und vom Fahrt-/Verlaufs-Modul des Backend-Dienstes der Plattform ab, welches noch nicht gebaut wurde (der Backend-Dienst deckt heute nur die Fahrerregistrierung ab); die entsprechende datenbankseitige Sicherheitsrichtlinie bleibt im internen Entwurf als "STUB, NICHT RATIFIZIERT" gekennzeichnet. Dieser Abschnitt erklärt die namentliche Nicht-Identifizierung nicht als bereits im Produktivbetrieb aktive operative Tatsache, sondern nur als bereits eingefrorene Design-Regel, ausstehend der ratifizierten technischen Durchsetzung.

Identifizierung aus Sicherheitsgründen — in Prüfung, nicht entschieden: es wird noch geprüft, ob aus Sicherheitsgründen eine punktuelle Identifizierung zwischen Fahrer und Fahrgast (oder umgekehrt) erforderlich werden könnte, was zu einer Spannung mit der oben bereits eingefrorenen allgemeinen Regel der namentlichen Nicht-Identifizierung führen würde — gemäss der internen Produktdokumentation des Projekts zum Fahrtverlauf. Diese Erklärung äussert sich in dieser Version weder zur Identifizierung noch zu deren vollständigem Fehlen als Sicherheitsausnahme — sie erklärt nur die bereits eingefrorene allgemeine Regel der gegenseitigen Nicht-Identifizierung, anwendbar solange diese Prüfung nicht abgeschlossen ist. Jede künftige Klärung dieses Punkts wird in diesem Abschnitt erfasst und von der internen Sicherheitsprüfung der Plattform als mit der bereits eingefrorenen RLS vereinbar oder nicht vereinbar bestätigt, ohne informelle Wiedereröffnung.

Rechtsgrundlage der Anonymisierung: der Übergang in den Verlauf ist die direkte Anwendung der Pflicht nach Art. 6 §4 — die Daten werden anonymisiert, sobald sie in identifizierbarer Form für den Zweck des Betriebs der laufenden Fahrt nicht mehr erforderlich sind.

4.8Bewertung der Plattform (0 bis 5 Sterne)

Am Ende jeder Fahrt kann der Fahrgast die Plattform bewerten, nicht den einzelnen Fahrer. Diese Bewertung wird mit dem anonymisierten Bezeichner des Fahrgasts und dem Fahrtereignis verknüpft, zu Zwecken der Produktkennzahlen des Unternehmens. Sie wird niemals nach Fahrerbezeichner aggregiert, angezeigt oder abgefragt, erscheint niemals auf einem Bildschirm oder einer für den Fahrer zugänglichen API und wird niemals zur Fahrtvermittlung verwendet. Rechtsgrundlage: berechtigtes, verhältnismässiges Interesse an der Messung der Zufriedenheit mit der von der Plattform erbrachten Dienstleistung (Art. 6 §2), ohne Zweck der Führung oder Bewertung der individuellen Leistung des Fahrers — diese Zweckunterscheidung ist genau der Grund, weshalb diese Bewertung dem Fahrer nicht zugänglich gemacht wird.

4.9Zahlungen — Fahrt (P2P) und Abonnement (Stripe), getrennte Abläufe

Gemäss Verweis in Abschnitt 1.1: die Bezahlung der Fahrt erfolgt zu hundert Prozent Peer-to-Peer, ausserhalb unserer Infrastruktur, und wir bearbeiten oder speichern keinerlei Zahlungsdaten der Fahrt. Der einzige von uns bearbeitete Zahlungsablauf ist das monatliche Abonnement des Fahrers an die Plattform, über den Zahlungsdienstleister Stripe (Stripe Billing), welcher die Rechnungs- und Kartendaten des Fahrers direkt bearbeitet, unter den eigenen Bedingungen und der Datenschutzerklärung von Stripe. Rechtsgrundlage: Verhältnismässigkeit und Zweck der Bearbeitung (Art. 6 §2-3), Erfüllung des Abonnementvertrags zwischen dem Fahrer und der Plattform; Rechtfertigungsgrund: Art. 31 §2 al. a, gemäss dem bereits in Abschnitt 3 festgelegten Kriterium.

4.10Cargo-B2B-Modul und potenziell grenzüberschreitende Abläufe

Das Cargo-B2B-Modul kann Kunden und Transporteure mit Sitz in der Europäischen Union betreffen. Siehe Abschnitt 10 zur auf diesen Fall anwendbaren Rechtsordnung.

4.11Institutionelle Website, Cookies und Analytics

Das endgültige Verzeichnis der Cookies und Tracking-Technologien der institutionellen Website directtransfer.ch wird in diesem Abschnitt veröffentlicht, mit Verweis auf eine eigene Cookie-Richtlinie, sofern die Komplexität dies rechtfertigt, vor Aktivierung jedes Cookies, das für die technische Funktion der Website nicht zwingend erforderlich ist. Bis zu dieser Veröffentlichung aktiviert die institutionelle Website kein Analytics- oder Marketing-Cookie Dritter, ohne dass dieses Verzeichnis hier zuerst beschrieben wird, und, wo anwendbar, ohne die nach Art. 6 §6-7 FADP erforderliche vorherige Einwilligung.

4.12Sicherheit, Betrugsprävention und Rechtskonformität

Wir können Personendaten bearbeiten, um Betrug zu erkennen und zu verhindern, sowie um einer rechtlichen Verpflichtung nachzukommen oder auf ein berechtigtes Ersuchen einer zuständigen Behörde zu reagieren. Rechtsgrundlage: Rechtmässigkeit und Verhältnismässigkeit der Bearbeitung (Art. 6 §1-2), eingebettet in die Erfüllung einer rechtlichen Verpflichtung, der die Plattform unterliegt. Soweit diese Bearbeitung eine mögliche Beeinträchtigung der Persönlichkeitsrechte der betroffenen Person darstellt, ergibt sich der anwendbare Rechtfertigungsgrund aus Art. 31 §2, in dessen Buchstaben betreffend die Erfüllung einer rechtlichen Verpflichtung oder die Wahrung eines überwiegenden Interesses — allgemeine Kategorien der Norm, unterschieden von al. a (Vertragserfüllung), welche in anderen Unterabschnitten dieser Erklärung verwendet wird; der auf jede konkrete Situation anwendbare genaue Buchstabe wird fallweise zum Zeitpunkt der Bearbeitung bestimmt.

5Rechtsgrundlage, zusammengefasst

Wir bearbeiten Ihre Personendaten je nach Fall auf Grundlage: Ihrer ausdrücklichen Einwilligung, insbesondere für besonders schützenswerte Daten erforderlich (Art. 6 §6-7 al. a); der Erfüllung des Nutzungsvertrags der Plattform oder des Beförderungsvertrags zwischen Ihnen und der anderen Partei der Fahrt, mit Rechtfertigungsgrund nach Art. 31 §2 al. a, wo eine mögliche Beeinträchtigung der Persönlichkeitsrechte besteht; der Erfüllung einer rechtlichen Verpflichtung, der die Plattform unterliegt; und des berechtigten Interesses, stets unter Vorbehalt des Verhältnismässigkeitstests von Art. 6 §2. Wo ein spezifischer Zweck zusätzliche ausdrückliche Einwilligung erfordert (z. B. besonders schützenswerte Dokumentdaten des Fahrers, Abschnitt 4.2), holen wir diese Einwilligung gesondert ein, mit Audit-Protokoll gemäss Abschnitt 16.

6Besonders schützenswerte Personendaten — verstärkte Behandlung

In Wiederholung von Abschnitt 4.2: der Identitätsausweis, der Führerausweis und die damit verbundenen biometrischen Daten des Fahrers sind besonders schützenswerte Personendaten (Art. 5 al. c Ziff. 4). Der in manchen Kantonen verlangte Strafregisterauszug des Fahrers — zum Beispiel Zürich und Basel, gemäss bereits vorhandener interner kantonaler Regulierungsrecherche des Projekts — ist ebenso besonders schützenswertes Personendatum, eingeordnet unter Ziff. 5 desselben Artikels (Daten über verwaltungs- und strafrechtliche Verfolgungen und Sanktionen), und erhält dieselbe verstärkte Behandlung unten. Wir wenden auf beide Kategorien, gemäss bereits eingefrorenem Design des Projekts, an: (i) ausdrückliche Einwilligung zum Zeitpunkt der Einreichung (Art. 6 §7 al. a); (ii) eingeschränkten Zugriff über rollenbasierte Zugriffskontrolle (RBAC) — nur der Fahrer selbst und Administratoren, niemals der Fahrgast, einschliesslich des Strafregisterauszugs, gemäss der bereits von der internen Sicherheits- und Compliance-Prüfung der Plattform festgelegten RBAC-Matrix — die RBAC-Kontrolle selbst ist im Backend-Dienst der Plattform für den Zugriff auf Fahrerdokumente gebaut, getestet und in Betrieb; die datenbankseitige Zeilensicherheit (RLS) der zugrundeliegenden Daten, als zweite, ergänzende Durchsetzungsschicht gemäss Abschnitt 4.7 oben, steht weiterhin zur endgültigen Ratifizierung durch die interne Sicherheitsprüfung der Plattform aus und ist im internen Entwurf weiterhin als "STUB, NICHT RATIFIZIERT" gekennzeichnet; (iii) Delegation der Echtheitsprüfung und Extraktion des Dokuments an einen etablierten externen Anbieter, unter einem Auftragsbearbeitungsvertrag — eine Pflicht, die sich aus der Bearbeitung von Personendaten durch einen Auftragsbearbeiter im Auftrag des Verantwortlichen ergibt (Art. 5 al. k FADP), eingebettet in die allgemeinen Grundsätze von Art. 6 und 8, ohne hier eine über diese Definition hinausgehende Artikelnummer zur Auftragsbearbeitung zu nennen, da dies nicht gegen den vollständigen Gesetzestext bestätigt wurde; (iv) keine intern von der Plattform entwickelte biometrische Gesichtserkennungs-Engine.

7Mit wem wir Daten teilen

Wir teilen Personendaten, im für jeden in Abschnitt 4 beschriebenen Zweck erforderlichen Ausmass, mit:

Externem Anbieter der Identitäts- und Dokumentenprüfung (KYC/IDV), zur Dokumentenprüfung des Fahrers, einschliesslich des Strafregisterauszugs, soweit anwendbar (Abschnitt 4.2). Handelsname wird in diesem Abschnitt veröffentlicht, sobald die Auswahl abgeschlossen ist; in der Zwischenzeit auf Anfrage über den Kontaktkanal in Abschnitt 15 erhältlich.
Stripe, zur Bearbeitung des monatlichen Abonnements des Fahrers (Abschnitt 4.9) — niemals für die Fahrtbezahlung.
Cloudflare, als Anbieter der Speicherinfrastruktur (R2) für das Foto des Abholorts (Abschnitt 4.4).
Der zuständigen kantonalen Behörde, wenn zur Validierung der Beförderungsbewilligung des Fahrers erforderlich, oder aufgrund einer rechtlichen Verpflichtung.
Der Aufsichtsbehörde (EDÖB) oder einer anderen zuständigen Behörde, wenn gesetzlich vorgeschrieben.

Wir verkaufen keine Personendaten an Dritte. Wir teilen keine identifizierbaren Fahrtdaten für Werbezwecke Dritter.

8Internationale Datenübermittlung (Art. 16-17 FADP)

Jeder Auftragsbearbeiter mit Sitz ausserhalb der Schweiz, der eine Wirkung auf einen Nutzer in der Schweiz erzeugt, unterliegt aufgrund seines räumlichen Geltungsbereichs dem FADP (Art. 3 §1). Ist einer unserer Anbieter (zum Beispiel der KYC/IDV-Anbieter oder Stripe, je nach Bearbeitungsgerichtsbarkeit) ausserhalb der Schweiz niedergelassen und liegt kein Angemessenheitsbeschluss des Bundesrates vor (Art. 16 §1), stützt sich die Übermittlung auf eine der Grundlagen nach Art. 16 §2: vom EDÖB genehmigte Standardvertragsklauseln (al. d), der gleichen Behörde vorab mitgeteilte vertragliche Datenschutzklauseln (al. b), oder eine andere gleichwertige Grundlage der Norm; alternativ auf die Ausnahmen nach Art. 17 §1, namentlich ausdrückliche Einwilligung (al. a) oder unmittelbarer Zusammenhang mit einem Vertrag (al. b).

Quellprüfungshinweis zu den oben zitierten Buchstaben von Art. 16 §2 und Art. 17 §1: wie bereits in Abschnitt 3 zu Art. 31 §2 al. a erwähnt, stellt das intern für diese Erklärung geführte Register der Primärquellen (Teil A, "Art. 16-17") diese Buchstaben durch Zusammenfassung/Paraphrase des Zusammenstellers dar — "wörtlich, auf die operativen Buchstaben zusammengefasst", im eigenen Text der Quelle — und nicht durch wörtliche, nummerierte Wiedergabe des vollständigen Textes der beiden Artikel, im Unterschied zu Art. 5, 6, 8, 19 und 25, die in dieser Erklärung aus wörtlicher, per pdftotext aus dem offiziellen Fedlex-PDF extrahierter Kopie zitiert werden. Das Bestehen der vier oben genannten Mechanismen (vom EDÖB genehmigte Standardvertragsklauseln, der gleichen Behörde vorab mitgeteilte Vertragsklauseln, ausdrückliche Einwilligung, unmittelbarer Zusammenhang mit einem Vertrag) wird in dieser Erklärung mit hoher Zuverlässigkeit verwendet; der genaue Wortlaut jedes Buchstabens (al. b und al. d von Art. 16 §2; al. a und al. b von Art. 17 §1) bleibt mit mittlerer Zuverlässigkeit versehen, vorbehaltlich direkter Bestätigung anhand des vollständigen Textes von Art. 16 und Art. 17 auf Fedlex oder eines Gutachtens eines zugelassenen Schweizer Anwalts — derselbe Vorsichtsmassstab, der bereits auf Art. 31 §2 al. a (Abschnitt 3) und Art. 9 angewendet wird (siehe das zu diesem Zweck geführte interne Rechtsregister).

Die konkrete, auf jeden einzelnen Anbieter anwendbare Grundlage nach Art. 16/17 — KYC/IDV, Stripe, je nach effektiver Bearbeitungsgerichtsbarkeit — wird pro Anbieter in diesem Abschnitt bestimmt und veröffentlicht, bevor eine Übermittlung von Personendaten an diesen Anbieter beginnt. Keine internationale Übermittlung von Personendaten erfolgt, ohne dass die anwendbare Grundlage nach Art. 16 §2 oder die Ausnahme nach Art. 17 §1 hier identifiziert und erfasst ist.

9Datenaufbewahrung — Kriterium, gemäss Art. 25 §2 al. d FADP

Gemäss Art. 6 §4 FADP vernichten oder anonymisieren wir Personendaten, sobald sie für den Zweck der Bearbeitung nicht mehr erforderlich sind. Art. 25 §2 al. d FADP verlangt, dass wir über "die Aufbewahrungsdauer... oder, falls dies nicht möglich ist, die Kriterien zur Festlegung dieser Dauer" informieren — das Gesetz akzeptiert das Kriterium ausdrücklich als gültige Alternative zu einer festen Zahl, und dies ist die Position dieser Erklärung.

Angewandtes Kriterium, nach Datenkategorie:

Identifizierbare Fahrtdaten: erforderlich während des operativen Lebenszyklus der Fahrt (Abschnitt 4.7, Phase 1); bei Abschluss der Fahrt gehen die Daten in einen anonymisierten Verlauf per irreversiblem Hash über (Abschnitt 4.7, Phase 2) — ab diesem Zeitpunkt existieren sie nicht mehr in identifizierbarer Form.
Foto des Abholorts: Design der automatischen Löschung 24 Stunden nach dem Hochladen (Abschnitt 4.4) — ausführbarer Mechanismus ausstehend, bis das Fahrt-/Chat-Modul gebaut und die RLS ratifiziert ist, gemäss dem Hinweis in jenem Abschnitt.
Chat-Nachrichten der Fahrt: effektive Löschung (Hard Delete) beim Abschluss der Fahrt — Kriterium bereits entschieden, ausführbarer Mechanismus ausstehend gemäss dem Hinweis in Abschnitt 4.5.
Dokument des Fahrers: aufbewahrt, solange die Beförderungsbewilligung aktiv ist — diese Komponente ist das bereits eingefrorene, ab sofort anwendbare Design. Umsetzungsstand, präzise: diese Erklärung schlägt zusätzlich eine Aufbewahrungsfrist nach Deaktivierung vor, abgeleitet aus einer kantonalen rechtlichen Verpflichtung, anwendbar auf den Registrierungskanton des Fahrers; diese spezifische kantonale Verpflichtung wurde noch durch keine Primärquelle des Projekts identifiziert — Abschnitt 4.2 selbst räumt diese Lücke bezüglich der Erneuerungshäufigkeit und der laufenden Überprüfung des Leumunds bereits ein. Anders als die drei vorangehenden Kriterien (Fahrt, Foto, Chat), welche bereits eingefrorenes, im Schema überprüfbares Architekturdesign sind, bleibt dieses vierte Kriterium teilweise offen: "aufbewahrt, solange die Bewilligung aktiv ist" gilt ab sofort; die zusätzliche Frist aufgrund einer kantonalen rechtlichen Verpflichtung kann erst angewendet werden, sobald diese Verpflichtung durch eine Primärquelle oder ein Rechtsgutachten identifiziert und zitiert ist.

Dies ist die Position dieser Erklärung zur Aufbewahrung: ein Kriterium, gemäss Art. 25 §2 al. d, angewendet auf jede in dieser Erklärung beschriebene Datenkategorie, ohne eine einzige numerische Frist für alle Kategorien — weil keine von ihnen dieselbe Frist erfordert, und das Gesetz diese Form der Antwort ausdrücklich zulässt. Drei der vier oben genannten Kategorien (Fahrt, Foto, Chat) haben ein vollständig abgeschlossenes Kriterium, verankert in bereits eingefrorenem Architekturdesign. Die vierte (Dokument des Fahrers) hat ihre Hauptkomponente — Aufbewahrung, solange die Bewilligung aktiv ist — ebenso abgeschlossen, mit der zusätzlichen kantonalen Fristkomponente noch offen, gemäss dem spezifischen Hinweis zu jenem Punkt oben; diese Erklärung wird aktualisiert, sobald diese kantonale Verpflichtung durch eine Primärquelle identifiziert ist.

10FADP und DSGVO — doppelte Offenlegung

Diese Erklärung gilt in der Regel nach dem schweizerischen Bundesgesetz über den Datenschutz (FADP/LPD/nDSG), welches auf jeden Sachverhalt mit Wirkung in der Schweiz anwendbar ist, selbst wenn er im Ausland veranlasst wurde (Art. 3 §1).

Das Cargo-B2B-Modul (Abschnitt 4.10) kann Kunden oder Transporteure mit Sitz in der Europäischen Union betreffen. Endgültige operative Position dieser Erklärung: wo der Kunde oder Transporteur des Cargo-Moduls in der Europäischen Union/im Europäischen Wirtschaftsraum niedergelassen ist, oder wo die Bearbeitung darauf abzielt, einer betroffenen Person in der EU eine Dienstleistung anzubieten oder deren Verhalten zu beobachten, wendet DirectTransfer auf diese spezifischen Abläufe kumulativ den schützenderen Standard zwischen dem FADP und der Datenschutz-Grundverordnung (DSGVO/GDPR) an — als präventive Compliance-Politik, nicht als endgültige rechtliche Anerkennung einer strikten Anwendbarkeit der DSGVO auf DirectTransfer. Dies umfasst mindestens, der betroffenen Person in der EU die bereits in Abschnitt 13 beschriebenen Mechanismen des Auskunfts-, Portabilitäts- und Löschungsrechts zur Verfügung zu stellen, selbst wo das FADP allein weniger verlangen würde. Ein formelles Rechtsgutachten zum genauen Umfang der strikten Anwendbarkeit der DSGVO auf diese Abläufe wird vor dem kommerziellen grenzüberschreitenden Start des Cargo-Moduls eingeholt; diese Erklärung wird mit der spezifischen DSGVO-Rechtsgrundlage pro Zweck aktualisiert, einschliesslich, falls erforderlich, der Benennung eines Vertreters in der EU, sobald dieses Gutachten vorliegt.

Notwendige, noch nicht bewertete Unterscheidung: eine allfällige Pflicht zur Benennung eines Vertreters in der Europäischen Union (Art. 27 DSGVO), falls anwendbar, ist eine strukturelle Pflicht, die sich von der oben beschriebenen "Anwendung des schützenderen Rechte-Standards" unterscheidet — erstere erfordert eine formelle, in der EU errichtete Kontaktstelle, nicht nur die Nachbildung der Mechanismen für Auskunft, Portabilität und Löschung. Diese Erklärung bewertet in dieser Version nicht, ob diese strukturelle Pflicht anwendbar ist; diese Bewertung hängt von demselben oben bereits erwähnten formellen Rechtsgutachten ab.

11Anwendbare kantonale Gesetzgebung

Neben dem eidgenössischen FADP unterliegen Registrierung und Betrieb des Fahrers der kantonalen Transportgesetzgebung (zum Beispiel LTVTC in Genf, Verordnung 740.25 im Kanton Waadt, LMob Art. 197 im Kanton Freiburg), mit dem Erfordernis einer eigenen Bewilligung als "diffuseur de course" (eine genferische, kantonalrechtliche Bewilligungskategorie für Fahrtvermittlungs-/Dispositionsdienste) in bestimmten Kantonen, unabhängig vom Beschäftigungsstatus des Fahrers. Diese Erklärung befasst sich ausschliesslich mit der Bearbeitung von Personendaten; die transportrechtliche Grundlage ist in den internen Compliance-Dokumenten des Projekts beschrieben, nicht hier dupliziert.

Effektiver geografischer Geltungsbereich dieser Erklärung: das in dieser Erklärung beschriebene Regime der Aufbewahrung und Bearbeitung von Personendaten gilt für die tatsächlich aktiven Betriebe der Plattform — heute für die Kantone, deren Betrieb tatsächlich verbunden ist, namentlich Zürich. Das Erfordernis ist nicht verhandelbar und real: die Aktivierung von Genf, Waadt oder Freiburg erfordert vorab ein formelles kantonales Rechtsgutachten eines zugelassenen Schweizer Anwalts (gemäss der internen Sicherheits- und Compliance-Prüfung der Plattform), und DirectTransfer betreibt oder bearbeitet keine Personendaten von Fahrten in diesen drei Kantonen, solange dieses Gutachten nicht vorliegt. Umsetzungsstand, präzise — der technische Schutzmechanismus und der rechtliche Entscheid zur Reaktivierung sind nicht dasselbe: der konkrete technische Mechanismus, der diese Sperre durchsetzt — ein Fail-Closed-Gate pro Kanton, angewendet an jedem Einstiegspunkt, der eine kantonale Fahrerbewilligung erstellt oder reaktiviert — ist bereits im Backend-Dienst der Plattform implementiert und durch automatisierte Tests abgedeckt, welche bestätigen, dass Genf, Waadt und Freiburg korrekt gesperrt werden, während andere Kantone zugelassen bleiben; dies ist nicht bloss ein technischer Vorschlag, der Schutzmechanismus besteht bereits und ist heute verifiziert, unabhängig von der Umgebung. Was weiterhin aussteht, ist nicht dieser technische Mechanismus, sondern das materielle Rechtsgutachten eines zugelassenen Schweizer Anwalts, das bestimmen wird, ob und wann Genf, Waadt oder Freiburg reaktiviert werden; solange dieses Gutachten nicht vorliegt, weist das Fail-Closed-Gate weiterhin jeden Versuch zurück, in diesen drei Kantonen eine Fahrerbewilligung zu erstellen oder zu reaktivieren. Diese Erklärung wird mit dem spezifischen kantonalen Regime zum Zeitpunkt der Aktivierung eines neuen Kantons aktualisiert.

12Informationssicherheit (Art. 8 FADP)

Wir wenden dem Risiko angemessene technische und organisatorische Massnahmen an, um ein geeignetes Datensicherheitsniveau zu gewährleisten und Verletzungen der Datensicherheit zu verhindern (Art. 8 §1-2). Das bereits eingefrorene Sicherheitsdesign umfasst rollenbasierte Zugriffskontrolle (RBAC) und zeilenbasierte Sicherheit (Row Level Security, RLS) auf den Tabellen für Fahrt, Dokument und Personendaten, gemäss der bereits von der internen Sicherheits- und Compliance-Prüfung der Plattform festgelegten RBAC-Matrix und den RLS-Anforderungen.

Umsetzungsstand, präzise: die rollenbasierte Zugriffskontrolle (RBAC) ist im Backend-Dienst der Plattform für die bisher gebauten Abläufe gebaut, getestet und in Betrieb (Fahrerregistrierung, einschliesslich Dokumentenzugriff, gemäss Abschnitt 6); für noch nicht gebaute Abläufe (Fahrt, Chat, Fahrtverlauf) besteht noch keine aktive Durchsetzung, weil das zugrundeliegende Modul noch nicht existiert. Die konkreten datenbankseitigen Zeilensicherheits-Policies (RLS) sind weiterhin nur als interner Entwurf erfasst, ausdrücklich als "STUB, NICHT RATIFIZIERT" gekennzeichnet — dieser Entwurf legt die funktionale Absicht auf SQL-Ebene fest, um die Arbeit des internen Sicherheitsteams zu beschleunigen, ist jedoch nicht die endgültige Richtlinie; die Ratifizierung durch das interne Sicherheitsteam ist Voraussetzung, bevor RLS als bereits im Produktivbetrieb aktive Sicherheitsmassnahme bezeichnet werden kann, auch für die bereits gebauten Abläufe. Dieser Abschnitt beschreibt daher das bereits eingefrorene Sicherheitsdesign und die Zielarchitektur; die RBAC-Durchsetzung ist für die bisher gebauten Abläufe operativ verifiziert, die RLS-Durchsetzung noch nicht, bis zu dieser Ratifizierung.

Kommt es zu einer Verletzung der Datensicherheit, die voraussichtlich ein hohes Risiko für Ihre Persönlichkeit oder Grundrechte zur Folge hat, melden wir dies dem EDÖB so rasch als möglich (Art. 24 §1) und informieren Sie direkt, sofern dies zu Ihrem Schutz erforderlich ist oder die Behörde dies verlangt (Art. 24 §4).

13Ihre Rechte

Nach dem FADP haben Sie das Recht auf:

Auskunft (Art. 25): zu erfahren, ob wir Personendaten über Sie bearbeiten, und unter anderem die Identität und Kontaktdaten des Verantwortlichen, die bearbeiteten Daten selbst, den Zweck, die Aufbewahrungsdauer oder das Kriterium zu deren Festlegung (Abschnitt 9), die Herkunft der Daten, sofern nicht direkt bei Ihnen erhoben, sowie die Empfänger (Abschnitt 7) zu erhalten. Wir antworten in der Regel innerhalb von 30 Tagen (Art. 25 §7), kostenlos (Art. 25 §6). Auf dieses Recht kann nicht im Voraus verzichtet werden (Art. 25 §5).
Berichtigung (Art. 32): die Berichtigung unrichtiger Personendaten zu verlangen.
Datenübertragbarkeit (Art. 28-29): die Herausgabe der Daten, die mit Ihrer Einwilligung oder in unmittelbarem Zusammenhang mit einem Vertrag mit Ihnen bearbeitet wurden, in einem gängigen elektronischen Format zu verlangen.
Widerspruch gegen unrechtmässige Bekanntgabe (Art. 30-31): die Bekanntgabe Ihrer besonders schützenswerten Daten an Dritte erfordert einen eigenen Rechtfertigungsgrund (zum Beispiel Vertragserfüllung, Art. 31 §2 al. a); Sie können eine Bekanntgabe ohne diesen Grund anfechten.
Beschwerde bei der Aufsichtsbehörde: Sie können eine Beschwerde beim EDÖB einreichen (Art. 4).

13.1Recht auf Vergessenwerden — aktueller Mechanismus

Die Vernichtung oder Anonymisierung von Daten, sobald sie nicht mehr erforderlich sind, ist eine gesetzliche Pflicht des Verantwortlichen, keine Option (Art. 6 §4), und Art. 32 erlaubt es, die Berichtigung unrichtiger Daten zu verlangen. Aktueller Mechanismus, endgültig solange kein Self-Service implementiert ist: jedes Gesuch um vorzeitige Löschung Ihrer Daten wird manuell über den Kontaktkanal in Abschnitt 15 bearbeitet; wir antworten innerhalb der Frist von Art. 25 §7 (30 Tage), hier analog auf das Löschungsgesuch angewendet — eine angemessene Ausdehnung der Frist, keine mit dem wörtlichen Anwendungsbereich von Art. 25 §7 identische Garantie, welcher das Auskunftsrecht betrifft, nicht die Ausführung eines Löschungsgesuchs, und daher der Überprüfung durch einen zugelassenen Schweizer Anwalt unterliegt, bevor sie als endgültige Frist behandelt wird; und wir bestätigen schriftlich die Ausführung des Gesuchs oder, soweit anwendbar, die Rechtsgrundlage, die einer allfälligen Ablehnung zugrunde liegt (zum Beispiel eine weiterhin geltende kantonale rechtliche Verpflichtung zur Dokumentenaufbewahrung, Abschnitt 4.2). Ein direkter Self-Service-Mechanismus, mit dem die betroffene Person dieses Gesuch ohne manuellen Eingriff ausführen kann, kann künftig zur Verfügung gestellt werden; dieser Abschnitt wird bei Eintritt dessen aktualisiert, ohne das Recht selbst zu ändern, welches bereits durch den oben beschriebenen manuellen Mechanismus gewährleistet ist.

14Datenschutz-Folgenabschätzung (Art. 22)

Wir erkennen an, dass die Bearbeitung besonders schützenswerter Personendaten in grossem Umfang, wie die Dokumentenprüfung des Fahrers (Abschnitte 4.2, 6), die Pflicht zur Durchführung einer Datenschutz-Folgenabschätzung vor der Bearbeitung nach Art. 22 §1-2 al. a auslösen kann. Diese Abschätzung liegt vor dem Start in der gemeinsamen Verantwortung des internen Sicherheits- und Compliance-Teams und des internen Rechtsteams, und ihr Ergebnis kann zu Anpassungen dieser Erklärung führen.

15Kontakt

Um eines der Rechte aus Abschnitt 13 auszuüben, oder für jede Frage zu diesem Dokument: privacidade@directtransfer.ch.

16Einwilligung, Clickwrap und Audit-Protokoll

Wo diese Erklärung oder eine Nutzungsbedingung Ihre Einwilligung erfordert — zum Beispiel bei der Kontoregistrierung, bei der Einreichung eines besonders schützenswerten Dokuments des Fahrers (Abschnitt 6), oder bei der Annahme dieser Erklärung selbst — erfolgt die Annahme durch ausdrückliches Clickwrap, niemals durch Untätigkeit oder stillschweigendes Navigieren. Jede Annahme erzeugt ein Audit-Protokoll mit mindestens: dem Bezeichner des Nutzers, der die Annahme erklärt hat, der genauen Version des angenommenen Dokuments, und dem Zeitstempel der Annahme. Dieses Protokoll erlaubt es, jederzeit nachzuweisen, was von wem und wann angenommen wurde — eine Gültigkeitsvoraussetzung für die freiwillige und spezifische Einwilligung, die von Art. 6 §6 FADP verlangt wird.

Die genaue technische Struktur dieses Audit-Protokolls (Tabellenschema, Aufbewahrung des Einwilligungsprotokolls selbst) liegt in der Verantwortung des zuständigen Datenarchitektur-Teams, gemäss der internen Ingenieur-Governance-Regel dieses Projekts zur ausschliesslichen Eigentümerschaft gemeinsam genutzter technischer Verträge — diese Erklärung definiert das rechtliche Erfordernis, nicht das technische Schema.

17Änderungen dieser Erklärung

Wir können diese Erklärung aktualisieren, um eine Änderung der Datenbearbeitung, des anwendbaren Rechts oder der Plattform widerzuspiegeln. Eine materielle Änderung wird vor ihrem Inkrafttreten deutlich mitgeteilt, und jede Version wird durch Nummer und Datum gekennzeichnet, gemäss demselben Versionsprotokoll-Mechanismus wie in Abschnitt 16.

Versionsverlauf:

Version 1.0 — 2026-08-22: erste endgültige Version dieses Dokuments, welche den vorangegangenen Arbeitsentwurf ersetzt. Enthält die bereits in früheren Runden interner Sicherheits- und Compliance-Gegenprüfung sowie interner adversarialer kritischer Überprüfungsdebatte angewendeten Korrekturen, und legt die endgültige Position fest bezüglich Aufbewahrung (Abschnitt 9), aktivem kantonalem Geltungsbereich (Abschnitt 11), doppelter FADP/DSGVO-Offenlegung für das Cargo-Modul (Abschnitt 10) und Mechanismus des Rechts auf Vergessenwerden (Abschnitt 13.1). Bezüglich der Offenlegung des nativen GSM-Anrufs (Abschnitt 4.6) schliesst sie den Offenlegungstext ab und legt die nächstliegende verfügbare rechtliche Einordnung vor (Art. 19 §2 al. c + Art. 6 §2), schliesst jedoch nicht von sich aus die Bestätigung der rechtlichen Hinlänglichkeit dieser Einordnung für das konkrete Szenario ab — diese Bestätigung verbleibt bei der internen Sicherheits- und Compliance-Prüfung der Plattform, gemäss dem Hinweis in Abschnitt 4.6 selbst. Punktuelle Korrektur vom 2026-08-23 (Abschnitt 11): der vorherige Text beschrieb das Fail-Closed-Gate zur kantonalen Sperre weiterhin als "einen technischen Vorschlag, keine Entscheidung" — veraltet. Die direkte technische Überprüfung des Codes bestätigte, dass der Mechanismus bereits implementiert und durch automatisierte Tests abgedeckt ist; ausstehend bleibt lediglich das materielle Rechtsgutachten eines zugelassenen Schweizer Anwalts zur Reaktivierung dieser Kantone. Freiburg wurde zudem ausdrücklich neben Genf und Waadt hinzugefügt, da es im Code gleichermassen gesperrt ist.