How SYIBE handles a request from police, a prosecutor, a court, a regulator or any other public authority for rider, ride, payment or vehicle data. The starting position is that data is not disclosed, and disclosure requires valid legal authority reviewed against applicable law.
Version 0.1-draft · v1 Working Draft — frozen
Version & effective date
No effective date while the status is working draft. On approval the version becomes 1.0, an effective date is set at least 14 days ahead for material rider-facing changes (immediate where a change is legally required or purely clarifying), and the previous version stays archived with its own effective window.
Jurisdiction & city applicability
Jurisdiction-specific by design. A city or country edition of this policy may only be published once the categories of authority competent to compel data, the instruments they must use, and the limits on disclosure under that jurisdiction's law have been confirmed by local counsel. [LEGAL REVIEW REQUIRED] [REGULATORY CONFIRMATION REQUIRED]
CMS integration
Draft clauses
Default position: a request, on its own, is not a reason to disclose anything. SYIBE does not disclose personal data merely because an authority, an official, a company or an individual asks for it, and no member of staff may release data outside this policy.
Single channel: all requests must be made in writing to legal@syibe.com or delivered to the registered address, and are routed to the designated legal-requests owner. Requests received by field staff, riders' support channels, social media or in person are not actioned; the requester is directed to the single channel and the attempt is logged.
Validity review, in order: (1) the identity and official capacity of the requester is verified; (2) the legal instrument relied on is identified — court order, prosecutorial or judicial authorisation, statutory power, or regulatory directive; (3) the instrument is checked for competence, scope, specificity and validity period; (4) applicable law is reviewed to confirm SYIBE is in fact permitted or compelled to disclose. A request that fails any step is refused or returned for correction.
Scope discipline: where disclosure is lawful, SYIBE releases the narrowest data that answers the request — the specific account, the specific ride, the specific time window — and refuses bulk, open-ended, exploratory or standing requests, requests for continuous access to systems, and requests for direct access to databases, dashboards or telemetry feeds.
Excluded by default: biometric templates and liveness artefacts, full payment credentials, and continuous historical location beyond the period specified in a valid instrument are not disclosed unless an instrument expressly and lawfully compels that specific category, reviewed individually. [LEGAL REVIEW REQUIRED]
Emergency requests are handled on a separate track and are not a shortcut around the validity review. An emergency request is one asserting an imminent risk of death or serious physical harm — for example a missing person, an unreported serious collision, or a credible threat to life. It may be actioned before a formal instrument arrives only where all of the following hold: the asserted risk is imminent and specific; the data requested is limited to what could reduce that risk, normally the last known location of a specific vehicle or the status of a specific ride; the release is approved by a named senior authoriser; and the requester undertakes to provide the formal instrument afterwards.
Emergency releases are minimised, time-boxed and reviewed. Each emergency release is limited to a single named subject and a defined time window, is recorded in full with the asserted risk and the approver, and is reviewed within five business days; if the formal instrument does not follow, the event is escalated internally and counted separately in the transparency figures.
Rider notification: SYIBE notifies the person concerned that their data was requested, unless notification is prohibited by the instrument or by law, or would defeat a lawful emergency purpose. Where notification is only delayed, it is given once the restriction ends.
Challenge: SYIBE may seek clarification, narrowing, or judicial review of a request that is overbroad, unlawful, or inconsistent with applicable data-protection duties, and will do so where it considers the request improper.
Register and transparency: every request — granted, narrowed, refused or withdrawn — is recorded in an internal register with the requester type, instrument, scope, decision, data released and approver. SYIBE intends to publish periodic aggregate figures with no identifying detail. [COMMERCIAL DECISION REQUIRED] on publication frequency.
Preservation without disclosure: on a valid preservation request SYIBE may preserve specified records beyond their normal retention period without disclosing them, for a defined period, pending a disclosure instrument.
Staff duties: field, support and operations staff are trained to refer every request upward and never to confirm or deny whether a person is a SYIBE customer; only the legal-requests owner may respond.
These documents are professional working drafts prepared for the SYIBE operating model. They are not legal advice and are not approved production legal language. Before public launch, every jurisdiction-sensitive document must be reviewed by qualified local legal counsel once the corporate entity, regulatory classification, municipal permissions, insurance structure, payment provider, KYC provider and hardware structure are finalised.