Privacy Policy — directtransfer.ch

0About this document

This is the Privacy Policy of the institutional website directtransfer.ch and of the DirectTransfer applications (passenger and driver), operated by the platform, including the Cargo B2B module. It describes what personal data we process, for what purpose, on what legal ground, with whom we share it, for how long we retain it, and what your rights are under the Swiss Federal Act on Data Protection (FADP).

Translation note: the articles of the Swiss Federal Act on Data Protection ("Federal Act on Data Protection", FADP; in German *Datenschutzgesetz*, DSG/nDSG; in French *Loi sur la protection des données*, LPD) cited below are based on the consolidated courtesy English translation dated 2025-07-07, published by the Confederation on Fedlex (SR 235.1). The Confederation itself notes that this translation "is provided for information purposes only and has no legal force" — the legally binding version is always the German, French or Italian one.

1Who we are and what this document covers

DirectTransfer is operated by the platform ("we", "the platform", "DirectTransfer"), acting as controller of personal data within the meaning of Art. 5 al. j FADP for the purposes described in this policy.

Identity: DirectTransfer, a Switzerland-based ride platform. Implementation status, precisely stated: legal entity name, registered office and commercial registration number (UID) are not published in this policy pending official, verifiable registration in the Swiss commercial register (Zefix/UID) — no attribution to an unconfirmed legal entity is made anywhere in this document.
Contact for privacy matters: privacidade@directtransfer.ch.
Competent supervisory authority: Federal Data Protection and Information Commissioner (FDPIC), per Art. 4 FADP.

This policy applies to the directtransfer.ch website, the passenger application, the driver application and the Cargo B2B module, whenever we process personal data of a data subject within the meaning of Art. 5 al. b FADP.

1.1What DirectTransfer is, and what it is not — mandatory restatement

This clause is restated because it directly conditions how we handle your data: DirectTransfer is software as a service (SaaS). the platform never employs the driver — there is no employment relationship; the driver is responsible for their own vehicle, insurance and schedule. The platform never sets the fare — the driver sets the price within a range that is merely suggested, under an auction/bilateral-negotiation mechanism. The platform never financially intermediates the ride — payment for the ride is one hundred percent peer-to-peer (P2P) between passenger and driver, via TWINT, SumUp, cash or the driver's own card; no ride payment data is processed or stored by DirectTransfer. This is distinct and separate from the driver's monthly subscription payment to the platform (section 4.9), which is a different data flow. This distinction determines, among other things, which payment data exists in our system and which will never exist.

2Relevant definitions (Art. 5 FADP)

We use the terms of the Act as defined in its Art. 5:

Personal data: any information relating to an identified or identifiable natural person (Art. 5 al. a).
Data subject: the natural person to whom the personal data relates (Art. 5 al. b).
Sensitive personal data: includes, among others, biometric data that uniquely identifies a natural person, and data on administrative or criminal proceedings and sanctions (Art. 5 al. c, items 4 and 5). Note applied to our specific case: the identity document and driving licence submitted by the driver at registration, and the biometric data extracted from them by the third-party identity verification provider (KYC/IDV), constitute sensitive personal data within this meaning under item 4 — they are not treated as ordinary personal data, see section 7. The driver's criminal record extract, required in some cantons, constitutes sensitive personal data under item 5 (data on administrative or criminal proceedings and sanctions) — see sections 4.2 and 6.
Processing: any operation on personal data — collection, storage, use, modification, disclosure, archiving, deletion or destruction (Art. 5 al. d).
Personal data breach: unauthorised, accidental or unlawful loss, deletion, destruction, modification, or access to or disclosure of personal data (Art. 5 al. h).
Controller: whoever determines, alone or jointly, the purpose and means of the processing — the platform, for the purposes described here (Art. 5 al. j).
Processor: whoever processes personal data on behalf of the controller — for example, the image-storage infrastructure provider, or the document-verification provider (Art. 5 al. k).

3Principles we apply (Art. 6 FADP)

All processing described in this policy follows the principles of Art. 6 FADP: lawfulness (§1); good faith and proportionality (§2); collection only for a specific purpose that is recognisable to the data subject, with no further processing incompatible with that purpose (§3); destruction or anonymisation of the data as soon as it is no longer necessary for the purpose of the processing (§4); accuracy of the data, with correction or deletion of what is incorrect or incomplete (§5). Where we require your consent, that consent is valid only if given voluntarily, for one or more specific processing operations, on the basis of adequate information (§6); and it is explicitly required for the processing of sensitive personal data (§7 al. a).

Methodological note on citing legal grounds in this policy: the FADP does not have an enumerated list of "legal bases" in the style of Art. 6(1) GDPR. The Swiss regime is: processing is lawful if it complies with the principles of this Art. 6 (lawfulness, proportionality, purpose) and does not infringe the data subject's personality rights (Art. 30); where there is a potential infringement of personality rights, the processing requires its own grounds for justification under Art. 31, typically "conclusion or performance of a contract" under Art. 31 §2 al. a (see direct application in section 13). For this reason, each subsection of section 4 below anchors general lawfulness in Art. 6 and only invokes Art. 31 §2 al. a where there is an actual justification of a potential effect on personality rights arising from contract performance; from this section onward, each subsection invoking this ground does so by short reference ("grounds for justification: Art. 31 §2 al. a, per the criterion already established in this section 3"), without repeating the full explanatory paragraph. Art. 16-17 FADP relate exclusively to international data transfer (disclosure of personal data abroad) and are cited only in section 8, never as a general legal basis for domestic processing.

Translation note on "grounds for justification": the Portuguese source text uses "fundamento de justificação" — a concept specific to the Swiss FADP regime under Art. 31 that has no direct equivalent in GDPR vocabulary. It is deliberately not rendered here as "legal basis", since that term carries a different connotation under the GDPR than under the FADP regime explained in this section. "Grounds for justification" is used instead, precisely to preserve that distinction, per explicit instruction for this translation.

Source-verification note, regarding "Art. 31 §2 al. a": the existence of the grounds for justification for contract performance in Art. 31 §2 is confirmed by the primary source consulted (the internal FADP source register maintained for this policy, Part A, "Art. 30-31"), but that source summarises/paraphrases the content of the article — unlike Art. 5, 6, 8, 19 and 25, which are literal (verbatim) copies extracted via pdftotext from the official Fedlex PDF — without citing the full, numbered text of the letters of Art. 31 §2. The reference to the exact letter "al. a" in this policy is therefore the most likely reading, consistent with the typical structure of this type of norm, not a verbatim-confirmed citation of the letter. The substance of the ground (performance of contract as grounds for justification of a potential effect on personality rights) is used in this policy with high confidence; the exact wording of the letter remains at medium confidence, subject to direct confirmation against the full text of Art. 31 or the opinion of a licensed Swiss lawyer — the same precautionary standard already applied to Art. 9 (see the detailed internal legal record kept for this purpose).

4What data we collect and why

4.1Account registration

Name, contact details (phone, e-mail) of passenger and driver, at account creation. Purpose: to provide the technological intermediation service between passenger and driver. Legal ground: lawfulness, proportionality and recognisable purpose of the processing (Art. 6 §1-3) — the data is collected for the specific purpose, recognisable to the data subject, of creating and operating the account; grounds for justification: Art. 31 §2 al. a, per the criterion already established in section 3.

4.2Driver document verification — sensitive data

At driver registration, we collect an identity document, driving licence and, depending on the canton and category, other authorisations (e.g. carte de taxi, carte de limousine). Where required by the canton — for example Zurich and Basel, per internal cantonal regulatory research already available to the project — we also collect the driver's criminal record extract, valid for less than 3 months at the time of submission. These documents are submitted by photo, per the flow described in the Driver Registration module, and processed in two layers:

Layer 1 — third-party provider (KYC/IDV): confirms the authenticity of the document and extracts the legible fields (name, number, dates, document type), including, where applicable, biometric verification. This processing involves sensitive personal data within the meaning of Art. 5 al. c item 4 (identity document, driving licence, biometric data) and, where applicable to the criminal record extract, item 5 (data on administrative or criminal proceedings and sanctions) — requiring your explicit consent (Art. 6 §7 al. a) at the time of document submission, and a data processing agreement with the provider. This obligation arises from the processing of personal data by a processor on behalf of the controller — Art. 5 al. k FADP defines processor in these terms — and is framed within the general principles of lawfulness and proportionality of Art. 6 and the security duty of Art. 8. This policy does not cite here a specific FADP article number for sub-processing beyond the definition in Art. 5 al. k, as this has not been confirmed against the full text of the law.
Layer 2 — internal rules engine, without artificial intelligence: checks whether the extracted fields meet the documentary requirement of the declared canton and category. It does not use an AI/ML model; it is deterministic comparison against a configuration table.

An uncertain verdict at either layer is never auto-approved nor auto-rejected — it always goes to human review by an administrator. Driver documents, including the criminal record extract, are accessible only by the driver themselves and by administrators, never by the passenger, with the same reinforced treatment (explicit consent, restricted RBAC) described in section 6.

Renewal and ongoing verification: the minimum requirement applied is validity of less than 3 months for the criminal record extract at the time of each submission; the initial submission should not be read as coverage for the driver's entire lifecycle. The required renewal frequency and the ongoing background-check verification mechanism, where applicable per canton, are communicated directly to the driver via the app's contact channel, and will be published in this section as soon as the corresponding operational policy is finalised.

Third-party provider (KYC/IDV): the commercial name of the provider will be published in this section as soon as the selection is finalised, per the ongoing quotation process; available in the meantime upon request via the contact channel in section 15. The data processing agreement with that provider, referred to above, and the international transfer assessment (section 8), should the provider not operate within Swiss or EU/EEA territory, will be concluded and published together with that identification, before any document submission is processed by that provider in production.

4.3Real-time location during the ride

The approximate location of available vehicles is shared with the passenger before accepting a ride; after acceptance, the driver's position is shared with the passenger until pick-up. Purpose: direct performance of the transport contract agreed between passenger and driver. Legal ground: proportionality and purpose recognisable to the data subject at the time of the request (Art. 6 §2-3), as it may affect the data subject's personality rights through the exposure of geographic position to a third party; grounds for justification: Art. 31 §2 al. a, per the criterion already established in section 3.

4.4Pick-up location photo — automatic deletion within 24 hours

During ride communication, a photo of the pick-up location may be shared between passenger and driver, stored on Cloudflare R2.

The project's already-frozen lifecycle design provides for automatic deletion of this photo 24 hours after upload, and no retention beyond that period for any secondary purpose — per the project's internal data schema design, which fixes this 24h window as derived at query time (created_at + interval '24 hours') for messages of type photo. Implementation status, precisely stated: the platform's backend service exists and is operational for driver registration, but the ride/chat module that would execute this window — an application-level purge job and/or a Cloudflare R2 bucket lifecycle rule — has not yet been built; and, as regards the database layer, final ratification of the corresponding database-level security policy by the platform's internal security review is still pending. Until that module is built and that ratification is complete, the 24 hours described here are the project's binding design, not yet an operationally verifiable fact in production.

Purpose: to facilitate the physical meeting between the parties. Legal ground: contract performance and proportionality (Art. 6 §2-3); the automatic deletion within 24 hours designed above is the concrete application of the duty of destruction under Art. 6 §4 as soon as the data is no longer necessary for the purpose — the meeting has already taken place; grounds for justification: Art. 31 §2 al. a, per the criterion already established in section 3.

4.5Ride chat messages (`ride_messages`)

During an active ride, passenger and driver may exchange pre-defined messages, limited free text (up to 100 characters) or a photo, through the ride chat. Purpose: direct communication between the parties during the active ride — for example, pick-up instructions, adjusting the meeting point — while the ride is in progress.

Retention: the designed lifecycle rule is effective deletion (hard delete) of the chat content when the ride is closed — an already-closed design decision of the project as to the criterion, not a gap. Per the platform's internal security and compliance review, this is the direct application of the commandment "Zero chat after ride completion", and this rule is explicitly recorded in the project's internal data schema design. Implementation status, precisely stated: that schema design expressly assigns the purge job to the platform's backend service; the backend service now exists and is operational for driver registration, but the ride/chat module that would execute this specific purge job has not yet been built; the corresponding database-level security policy remains recorded only as an internal draft, explicitly marked "STUB, NOT RATIFIED", pending final ratification by the platform's internal security review. Until that module is built and that ratification is complete, effective removal (hard delete, not soft-delete, with no "deleted" flag) is the project's binding design, not yet an operationally verifiable fact in production.

Legal ground: performance of the transport contract between the parties and security of the coordination of the ongoing ride (Art. 6 §2-3); the automatic deletion when the ride is closed, designed above, is the concrete application of the duty of destruction under Art. 6 §4 as soon as the data is no longer necessary for the purpose — the ride has already ended; grounds for justification: Art. 31 §2 al. a, per the criterion already established in section 3.

No chat message is read, moderated or retained by DirectTransfer beyond what is necessary for the real-time technical operation of the ride itself; any one-off reading by an administrator investigating a formal complaint follows the same audited privileged-access pattern described in section 12.

Abuse-report metadata — under evaluation, not implemented: a minimal abuse-report metadata log (not the message content) is under evaluation, pending legal citation before any implementation, per the platform's internal security and compliance review; if implemented, this section will be updated.

4.6Phone call communication — native GSM call, no VoIP

The platform provides a call button that uses the native GSM call function of each user's mobile phone. There is no VoIP system, WebRTC, or call intermediation by DirectTransfer whatsoever — the call runs entirely over each party's mobile network operator, outside our infrastructure.

Disclosure relevant to your informed consent: by using this button, each party's phone number may become visible to the other party at the moment of the call, because the native GSM network delivers the actual origin/destination number to both parties by the very nature of the protocol — this exposure cannot be avoided while keeping the native call button, per the technical assessment recorded by the platform's internal security and compliance review.

What does not exist: no proxy number on the network replaces your real number during the call — there is no true phone proxy/relay; among other reasons, a relay of this type would collide with the "Zero VoIP" veto already fixed for this product.

What does exist: the app never displays your number, nor the other party's, as text on any screen of the passenger or driver apps — the number appears exclusively as an action button; and the app requests explicit confirmation before triggering the native dialer (a warning that the number will become visible to the other party upon continuing). These two mitigations are default behaviour in the apps.

Note on caller ID suppression (CLIR): where available, suppression of the origin number via a native network code (e.g. prefix #31#/*31#) depends entirely on each user's telephone operator — the platform does not verify, enforce or guarantee this suppression before triggering the native dialer. This is not a mitigation guaranteed by the product; it is recorded as a per-operator feasibility investigation item, not yet concluded, per the platform's internal security and compliance review.

Secondary note: the screen masking described above does not cover the admin back office, which already has plain-text read access to the phone number via RBAC on the users table (sections 6 and 12), for support purposes — this privileged access mandatorily generates an audit log (who, when, why); it is not a silent exception to the screen mitigation.

We do not record, store, or have access to any content of that call, because it never passes through our infrastructure.

Legal ground: the duty of information and transparency under Art. 19 §2 al. c FADP, which requires informing the data subject, at the time of data collection, about "the recipients or categories of recipients to whom personal data is disclosed" (verbatim text, per the primary legal-source register maintained internally for this policy) — this is the correct specific fit for this scenario, identified by the platform's internal security and compliance review: the other party to the ride is the recipient to whom the phone number becomes visible at the moment of the call, which is precisely a disclosure to a recipient, not the generic extension of §1 of the same article (informing about data not collected from the data subject themselves) used in a previous version of this text; this exposure is disclosed in advance by this clause — and proportionality of the processing (Art. 6 §2), for the purpose of enabling the physical meeting and communication during the ride. Grounds for justification of the disclosure itself: Art. 31 §2 al. a, per the criterion already established in section 3 — this ground is not affected by the re-anchoring above, which concerns only the information/transparency-duty component. This information duty is fulfilled through the explicit disclosure above and the mandatory confirmation dialogue before triggering the native dialer. This is the legal ground presented by this policy for this clause — see the confirmation status in the following paragraph.

Implementation status, with the same precision discipline used throughout this policy: the behaviour described above (screen masking, confirmation dialogue) is the project's already-frozen binding design for the passenger and driver apps. The activation block on this flow in production, per the platform's internal security and compliance review, does not depend on the platform's backend service (this flow, unlike those in sections 4.4, 4.5, 4.7, 6 and 12, never passes through our infrastructure, as described above) — it depends on confirmation of legal sufficiency by the platform's internal security and compliance review as to whether the Art. 19 §2 al. c + Art. 6 §2 framing above adequately covers, in terms of proportionality, this specific scenario. The re-anchoring of the citation to Art. 19 §2 al. c, applied above, corrects the fit previously described as uncertain in this policy: the exposure of one party's phone number to the other party during the call is a disclosure to a recipient at the moment of the call, and it is exactly this scenario — the duty to inform about "the recipients... to whom personal data is disclosed" — that Art. 19 §2 al. c covers in its verbatim text, no longer the generic extension of §1 (informing about data not collected from the data subject themselves) used in a previous version of this text. This policy presents Art. 19 §2 al. c + Art. 6 §2 as the ground for the disclosure already made above; the sufficiency of that framing against the proportionality test of Art. 6 §2 in this specific scenario — for example, whether the absence of an opt-out for the feature or a guarantee of CLIR affects that sufficiency — remains a technical-legal confirmation for the platform's internal security and compliance review, not a fact already closed by the internal legal team alone. Cross-document coordination note: this position is that of this Privacy Policy specifically; the parallel clause on the same topic in the Terms of Use follows its own update cycle and remains marked in that document as pending citation — the two documents do not yet converge, and this note avoids the appearance that they already do.

4.7Ride history and anonymised identifier (two-phase model)

Per ride, we record: origin and destination (coordinates and text address), start and end timestamp, vehicle category, value declared by the driver, final ride status, and a passenger and driver identifier. No other data is recorded by default.

This identifier operates in two distinct phases, not a single phase:

1. During the active ride: the identifier is resolvable (a direct reference to the user record), necessary for real-time functionality — row-level access control (RLS), the real-time connection (Socket.io) and the ongoing ride chat (section 4.5).

2. On transition to history, when the ride ends, the identifier is converted into an irreversible, salted cryptographic hash (e.g. SHA-256), with no foreign key that allows tracing back to the user's identity from the historical record.

The default rule as designed, per Commandment 5 (Row Level Security) and per the RLS requirements already specified by the platform's internal security and compliance review, is reciprocal nominal non-identification between the parties: neither should the passenger see the driver's name, nor the driver see the passenger's name, on any screen, including the history. Implementation status, precisely stated: this rule is designed and reflected in the two-phase model described above (resolvable identifier during the ride, irreversible hash on transition to history), but the executable enforcement mechanism — concrete database-level security policies and the column-masking layer that prevents identity leakage even when the row is visible — depends on final technical ratification by the platform's internal security review. Correction, 2026-08-23: the platform's backend service now covers both driver registration and ride/auction request flows (the flows where this identifier is used while a ride is active), not driver registration only; what remains outstanding is specifically the RLS ratification above, not the backend's existence. The corresponding database-level security policy remains marked "STUB, NOT RATIFIED" in the internal draft. This section does not state nominal non-identification as an operational fact already active in production, only as an already-frozen design rule, pending ratified technical enforcement.

Identification for security reasons — under evaluation, not decided: it is still under evaluation whether, for security reasons, occasional identification between driver and passenger (or vice versa) might become necessary, which would create tension with the general rule of nominal non-identification already frozen above — per the project's internal product documentation for ride history. This policy does not state, in this version, either identification or its total absence as a security exception — it states only the general rule of reciprocal non-identification already frozen, applicable while this evaluation is not concluded. Any future resolution of this point is recorded in this section and confirmed by the platform's internal security review as compatible, or not, with the already-frozen RLS, without informal reopening.

Legal ground for the anonymisation: the transition to history is the direct application of the duty under Art. 6 §4 — the data is anonymised as soon as it is no longer necessary, in identifiable form, for the purpose of operating the ongoing ride.

4.8Platform rating (0 to 5 stars)

At the end of each ride, the passenger may rate the platform, not the individual driver. This rating is linked to the passenger's anonymised identifier and the ride event, for the company's product-metric purposes. It is never aggregated, displayed or queryable by driver identifier, never appears on any screen or API accessible to the driver, and is never used to allocate a ride. Legal ground: legitimate, proportionate interest in measuring satisfaction with the service provided by the platform (Art. 6 §2), with no purpose of managing or evaluating the driver's individual performance — this distinction of purpose is precisely why this rating does not circulate to the driver.

4.9Payments — ride (P2P) and subscription (Stripe), separate flows

Per the reference in section 1.1: payment for the ride is one hundred percent peer-to-peer, outside our infrastructure, and we do not process or store any ride payment data. The only payment flow we process is the driver's monthly subscription to the platform, through the payment processor Stripe (Stripe Billing), which handles the driver's billing and card data directly, under Stripe's own terms and privacy policy. Legal ground: proportionality and purpose of the processing (Art. 6 §2-3), performance of the subscription contract between the driver and the platform; grounds for justification: Art. 31 §2 al. a, per the criterion already established in section 3.

4.10Cargo B2B module and potentially cross-border flows

The Cargo B2B module may involve customers and carriers located in the European Union. See section 10 on the legal regime applicable to this case.

4.11Institutional website, cookies and analytics

The final inventory of cookies and tracking technologies of the institutional website directtransfer.ch will be published in this section, with reference to a dedicated cookie policy should complexity justify it, before activation of any cookie that is not strictly necessary for the technical functioning of the site. Until that publication, the institutional website does not activate any third-party analytics or marketing cookie without that inventory first being described here and, where applicable, without the prior consent required by Art. 6 §6-7 FADP.

4.12Security, fraud prevention and legal compliance

We may process personal data to detect and prevent fraud, and to comply with a legal obligation or respond to a legitimate request from a competent authority. Legal ground: lawfulness and proportionality of the processing (Art. 6 §1-2), framed within compliance with a legal obligation to which the platform is subject. Where this processing constitutes a potential effect on the data subject's personality rights, the applicable grounds for justification arise from Art. 31 §2, in its letters relating to compliance with a legal obligation or safeguarding a predominant interest — general categories of the norm, distinct from al. a (contract performance) used in other subsections of this policy; the exact letter applicable to each specific situation is identified case-by-case at the time of processing.

5Legal ground, in summary

We process your personal data on the basis of, as applicable: your explicit consent, required in particular for sensitive data (Art. 6 §6-7 al. a); performance of the contract for use of the platform or the transport contract between you and the other party to the ride, grounds for justification under Art. 31 §2 al. a where there is a potential effect on personality rights; compliance with a legal obligation to which the platform is subject; and legitimate interest, always subject to the proportionality test of Art. 6 §2. Where a specific purpose requires additional explicit consent (e.g. sensitive driver document data, section 4.2), we request that consent separately, with an audit record per section 16.

6Sensitive personal data — reinforced treatment

Reiterating section 4.2: the driver's identity document, driving licence and associated biometric data are sensitive personal data (Art. 5 al. c item 4). The driver's criminal record extract, required in some cantons — for example Zurich and Basel, per internal cantonal regulatory research already available to the project — is equally sensitive personal data, falling under item 5 of the same article (data on administrative or criminal proceedings and sanctions), and receives the same reinforced treatment below. We apply, to both categories, per the project's already-frozen design: (i) explicit consent at the time of submission (Art. 6 §7 al. a); (ii) restricted access via role-based access control (RBAC) — only the driver themselves and administrators, never the passenger, including the criminal record extract, per the RBAC matrix already specified by the platform's internal security and compliance review — the RBAC control itself is built, tested and operational in the platform's backend service for driver document access; database-level row security (RLS) on the underlying data, as a second, complementary enforcement layer described in section 4.7 above, remains pending final ratification by the platform's internal security review and is still marked "STUB, NOT RATIFIED" in the internal draft; (iii) delegation of document authenticity and extraction to an established third-party provider, under a data processing agreement — an obligation arising from the processing of personal data by a processor on behalf of the controller (Art. 5 al. k FADP), framed within the general principles of Art. 6 and 8, without citing here a sub-processing article number beyond that definition, as this has not been confirmed against the full text of the law; (iv) no biometric facial-recognition engine built in-house by the platform.

7Who we share data with

We share personal data, to the extent necessary for each purpose described in section 4, with:

Third-party identity and document verification provider (KYC/IDV), for driver document verification, including the criminal record extract where applicable (section 4.2). Commercial name to be published in this section as soon as the selection is finalised; available in the meantime upon request via the contact channel in section 15.
Stripe, for processing the driver's monthly subscription (section 4.9) — never for ride payment.
Cloudflare, as the storage infrastructure provider (R2) for the pick-up location photo (section 4.4).
The competent cantonal authority, when required to validate the driver's transport authorisation, or by legal obligation.
The supervisory authority (FDPIC) or other competent authority, when required by law.

We do not sell personal data to third parties. We do not share identifiable ride data for third-party advertising purposes.

8International data transfer (Art. 16-17 FADP)

Any processor located outside Switzerland that produces an effect on a user in Switzerland is subject to the FADP by virtue of its territorial scope (Art. 3 §1). Where one of our providers (for example the KYC/IDV provider, or Stripe, depending on the processing jurisdiction) is established outside Switzerland and without an adequacy decision of the Federal Council (Art. 16 §1), the transfer relies on one of the bases under Art. 16 §2: standard contractual clauses approved by the FDPIC (al. d), data-protection contractual clauses notified in advance to the same authority (al. b), or another equivalent basis under the norm; alternatively, on the exceptions under Art. 17 §1, namely explicit consent (al. a) or direct connection to a contract (al. b).

Source-verification note, on the letters cited from Art. 16 §2 and Art. 17 §1 above: as already noted in section 3 regarding Art. 31 §2 al. a, the primary legal-source register compiled internally for this policy (Part A, "Art. 16-17") presents these letters by summary/paraphrase of the compiler — "verbatim, summarised to the operative letters", in the source's own text — and not by literal, numbered transcription of the full text of the two articles, unlike Art. 5, 6, 8, 19 and 25, cited in this policy from literal copy extracted via pdftotext from the official Fedlex PDF. The existence of the four mechanisms cited above (standard contractual clauses approved by the FDPIC, contractual clauses notified in advance to the same authority, explicit consent, direct connection to a contract) is used in this policy with high confidence; the exact wording of each letter (al. b and al. d of Art. 16 §2; al. a and al. b of Art. 17 §1) remains at medium confidence, subject to direct confirmation against the full text of Art. 16 and Art. 17 on Fedlex or the opinion of a licensed Swiss lawyer — the same precautionary standard already applied to Art. 31 §2 al. a (section 3) and to Art. 9 (see the detailed internal legal record kept for this purpose).

The specific Art. 16/17 basis applicable to each specific provider — KYC/IDV, Stripe, depending on the effective processing jurisdiction — is determined and published in this section, per provider, before any transfer of personal data begins to that provider. No international transfer of personal data occurs without the applicable basis under Art. 16 §2 or the exception under Art. 17 §1 being identified and recorded here.

9Data retention — criterion, per Art. 25 §2 al. d FADP

Per Art. 6 §4 FADP, we destroy or anonymise personal data as soon as it is no longer necessary for the purpose of the processing. Art. 25 §2 al. d FADP requires that we inform the data subject of "the retention period... or, if that is not possible, the criteria for determining that period" — the law expressly accepts the criterion as a valid alternative to a fixed number, and this is the position of this policy.

Criterion applied, by data category:

Identifiable ride data: necessary during the operational lifecycle of the ride (section 4.7, phase 1); on completion of the ride, the data transitions to an anonymised history via irreversible hash (section 4.7, phase 2) — from that moment, it no longer exists in identifiable form.
Pick-up location photo: design of automatic deletion 24 hours after upload (section 4.4) — executable mechanism pending construction of the ride/chat module and RLS ratification, per the note in that section.
Ride chat messages: effective deletion (hard delete) when the ride is closed — criterion already decided, executable mechanism pending per the note in section 4.5.
Driver document: retained while the transport authorisation remains active — this component is the already-frozen design, applicable from now. Implementation status, precisely stated: this policy additionally proposes a post-deactivation retention period derived from a cantonal legal obligation applicable to the driver's canton of registration; that specific cantonal obligation has not yet been identified by any primary source of the project — section 4.2 itself already acknowledges this gap regarding the frequency of renewal and ongoing background-check verification. Unlike the three preceding criteria (ride, photo, chat), which are already-frozen architecture design verifiable in the schema, this fourth criterion remains partially open: "retained while the authorisation remains active" applies from now; the additional period due to a cantonal legal obligation can only be applied from the moment that obligation is identified and cited by a primary source or legal opinion.

This is the position of this policy on retention: a criterion, per Art. 25 §2 al. d, applied to each data category described in this policy, with no single numeric period for all categories — because none of them requires the same period, and the law expressly allows this form of response. Three of the four categories above (ride, photo, chat) have a fully closed criterion, anchored in already-frozen architecture design. The fourth (driver document) has its main component — retention while the authorisation remains active — equally closed, with the additional cantonal-period component still open, per the specific note on that item above; this policy will be updated as soon as that cantonal obligation is identified by a primary source.

10FADP and GDPR — dual disclosure

This policy applies, as a rule, under the Swiss Federal Act on Data Protection (FADP/LPD/nDSG), which applies to any circumstance with an effect in Switzerland, even if initiated abroad (Art. 3 §1).

The Cargo B2B module (section 4.10) may involve customers or carriers located in the European Union. This policy's final operational position: where the customer or carrier of the Cargo module is established in the European Union/European Economic Area, or where the processing is aimed at offering a service to, or monitoring the behaviour of, a data subject in the EU, DirectTransfer cumulatively applies, to those specific flows, the more protective standard between the FADP and the General Data Protection Regulation (GDPR) — as a preventive compliance policy, not as a definitive legal recognition of the strict applicability of the GDPR to DirectTransfer. This includes, at a minimum, making available to the EU data subject the access, portability and deletion mechanisms already described in section 13, even where the FADP alone would require less. A formal legal opinion on the exact scope of strict applicability of the GDPR to these flows will be obtained before the commercial cross-border launch of the Cargo module; this policy will be updated with the specific GDPR legal basis per purpose, including, if necessary, appointment of an EU representative, as soon as that opinion is available.

A necessary distinction, not yet assessed: any obligation to appoint a representative in the European Union (Art. 27 GDPR), if applicable, is a structural obligation distinct from "applying the more protective standard of rights" described above — the former requires a formal point of contact established in the EU, not merely replicating access, portability and deletion mechanisms. This policy does not assess, in this version, whether that structural obligation applies; that assessment depends on the same formal legal opinion already referred to above.

11Applicable cantonal legislation

In addition to the federal FADP, driver registration and operation are subject to cantonal transport legislation (for example, LTVTC in Geneva, regulation 740.25 in Vaud, LMob Art. 197 in Fribourg), with a requirement for its own "diffuseur de course" authorisation (a Geneva-specific ride-dispatch/broker licence category under cantonal transport law) in certain cantons, regardless of the driver's employment status. This policy deals only with the processing of personal data; the transport regulatory basis is described in the project's internal compliance documents, not duplicated here.

Effective geographic scope of this policy: the personal-data retention and processing regime described in this policy applies to the platform's effectively active operations — today, to the cantons whose operation is actually connected, namely Zurich. The requirement is non-negotiable and real: activation of Geneva, Vaud or Fribourg requires a prior formal cantonal legal opinion from a licensed Swiss lawyer (per the platform's internal security and compliance review), and DirectTransfer does not operate or process ride personal data in those three cantons while that opinion does not exist. Implementation status, precisely stated — the technical safeguard and the legal decision to reactivate are not the same thing: the concrete technical mechanism that enforces this block — a fail-closed, per-canton activation gate applied at every entry point that creates or reactivates a cantonal driver authorisation — is already implemented in the platform's backend service and covered by automated tests confirming it correctly blocks Geneva, Vaud and Fribourg while allowing other cantons; this is not merely a technical proposal, the safeguard already exists and is verified today, independently of environment. What remains pending is not this technical mechanism, but the substantive legal opinion from a licensed Swiss lawyer that will determine whether and when Geneva, Vaud or Fribourg may be reactivated; until that opinion exists, the fail-closed gate continues to reject any attempt to create or reactivate a driver authorisation in those three cantons. This policy will be updated with the specific cantonal regime at the time any new canton is activated.

12Information security (Art. 8 FADP)

We apply technical and organisational measures appropriate to the risk to ensure an adequate level of data security and to prevent personal data breaches (Art. 8 §1-2). The already-frozen security design includes role-based access control (RBAC) and row-level security (RLS) on the ride, document and personal data tables, per the RBAC matrix and RLS requirements already specified by the platform's internal security and compliance review.

Implementation status, precisely stated: role-based access control (RBAC) is built, tested and operational in the platform's backend service for the flows already built to date (driver registration, including document access, per section 6); flows not yet built (ride, chat, ride history) have no active enforcement yet, because the underlying module does not exist yet. The concrete database-level row security (RLS) policies remain recorded only as an internal draft, explicitly marked "STUB, NOT RATIFIED" — this draft fixes the functional intent at SQL level to accelerate the internal security team's work, but it is not the final policy; ratification by the internal security team is a precondition before RLS can be asserted as a security measure already active in production, including for the flows already built. This section therefore describes the already-frozen security design and target architecture; RBAC enforcement is operationally verified for the flows built to date, RLS enforcement is not, pending that ratification.

If a personal data breach occurs that is likely to result in a high risk to your personality rights or fundamental rights, we notify the FDPIC as soon as possible (Art. 24 §1) and inform you directly, if necessary for your protection or if the authority so requires (Art. 24 §4).

13Your rights

Under the FADP, you have the right to:

Information (Art. 25): confirm whether we process personal data about you and obtain, among other things, the identity and contact details of the controller, the data itself being processed, the purpose, the retention period or the criterion for determining it (section 9), the origin of the data where not collected directly from you, and the recipients (section 7). We respond, as a rule, within 30 days (Art. 25 §7), free of charge (Art. 25 §6). This right cannot be waived in advance (Art. 25 §5).
Correction (Art. 32): request correction of incorrect personal data.
Portability (Art. 28-29): request the export, in a current electronic format, of data that has been processed with your consent or in direct connection to a contract with you.
Objection to improper disclosure (Art. 30-31): disclosure of your sensitive data to third parties requires its own grounds for justification (for example, contract performance, Art. 31 §2 al. a); you may contest disclosure without such grounds.
Complaint to the supervisory authority: you may lodge a complaint with the FDPIC (Art. 4).

13.1Right to be forgotten — current mechanism

The destruction or anonymisation of data as soon as it is no longer necessary is a legal obligation of the controller, not an option (Art. 6 §4), and Art. 32 allows requesting correction of incorrect data. Current mechanism, final while self-service is not implemented: any request for early deletion of your data is handled manually via the contact channel in section 15; we respond within the timeframe of Art. 25 §7 (30 days), applied here by analogy to the deletion request — a reasonable extension of the timeframe, not a guarantee identical to the literal scope of Art. 25 §7, which concerns the right to information, not the execution of a deletion request, and is therefore subject to review by a licensed Swiss lawyer before being treated as a definitive deadline; and we confirm in writing the execution of the request or, where applicable, the legal ground underlying any refusal (for example, a still-current cantonal legal obligation of document retention, section 4.2). A direct self-service mechanism for the data subject to execute this request without manual intervention may be made available in the future; this section will be updated when that occurs, without altering the right itself, already guaranteed by the manual mechanism described above.

14Data protection impact assessment (Art. 22)

We recognise that large-scale processing of sensitive personal data, such as driver document verification (sections 4.2, 6), may trigger the duty to carry out a data protection impact assessment before processing, under Art. 22 §1-2 al. a. This assessment is the joint responsibility of the internal security and compliance team and the internal legal team before launch, and its outcome may result in adjustments to this policy.

15Contact

To exercise any of the rights in section 13, or for any question about this document: privacidade@directtransfer.ch.

16Consent, clickwrap and audit record

Where this policy or any term of service requires your consent — for example, at account registration, at submission of the driver's sensitive document (section 6), or on acceptance of this policy itself — acceptance is given through explicit clickwrap, never through inaction or silent browsing. Each acceptance generates an audit record with, at minimum: the identifier of the user who accepted, the exact version of the document accepted, and the timestamp of acceptance. This record makes it possible to prove, at any time, what was accepted, by whom and when — a condition of validity for the voluntary and specific consent required by Art. 6 §6 FADP.

The exact technical structure of this audit record (table schema, retention of the consent log itself) is the responsibility of the responsible data architecture team, per this project's internal engineering-governance rule on exclusive ownership of shared technical contracts — this policy defines the legal requirement, not the technical schema.

17Changes to this policy

We may update this policy to reflect a change in data processing, applicable law, or the platform. Material change is communicated prominently before it takes effect, and each version is identified by number and date, per the same version-record mechanism as section 16.

Version history:

Version 1.0 — 2026-08-22: first final version of this document, replacing the previous working draft. Incorporates corrections already applied in prior rounds of internal security and compliance cross-checking and internal adversarial critical review debate, and closes the final position on retention (section 9), active cantonal scope (section 11), dual FADP/GDPR disclosure for the Cargo module (section 10), and the right-to-be-forgotten mechanism (section 13.1). Regarding the disclosure of the native GSM call (section 4.6), it closes the disclosure text and presents the closest available legal framing (Art. 19 §2 al. c + Art. 6 §2), but does not, on its own, close confirmation of the legal sufficiency of that framing for the specific scenario — that confirmation remains with the platform's internal security and compliance review, per the note in section 4.6 itself. Punctual correction on 2026-08-23 (section 11): the previous text described the cantonal-blocking fail-closed gate as still "a technical proposal, not a decision" — outdated. Direct technical verification of the code confirmed the mechanism is already implemented and covered by automated tests; only the substantive legal opinion from a licensed Swiss lawyer on reactivating those cantons remains pending. Fribourg was also added explicitly alongside Geneva and Vaud, as it is equally blocked in the code.