Deliverable 10 · Legal & Trust Center
Legal & Trust Center
34 bilingual working-draft documents, each classified by what it depends on, with a privacy data matrix, a consent matrix, benchmark gaps, CMS versioning architecture and a legal review checklist.
Read this first
Status of these documents
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.
Can be drafted now and finalised internally.
11 documents
Needs final payment, KYC, maps, telecom or IoT provider details.
4 documents
Needs Syrian/local legal review or country-specific adaptation.
13 documents
Needs final pricing, insurance, refund rules or operating decisions.
6 documents
Policy inventory
All documents
Open any document to read the full bilingual draft, its clauses and the open questions marked for review.
Core agreements
Terms of Service
The master agreement between SYIBE and any person using the application, website or vehicles. It defines the service, account rules, acceptable use, charges, liability boundaries, suspension and termination.
Rider Agreement
The rider's personal undertakings: lawful and careful riding, helmet and equipment expectations, assumption of ordinary riding risk, responsibility for the vehicle while in use, and cooperation with incident procedures.
Vehicle Rental / Ride Terms
The per-ride contract: how a ride starts and ends, what is charged, how time and pauses are measured, what happens at maximum duration, and the conditions for a valid end of ride.
Privacy & data
Privacy Policy
What SYIBE collects, why, on what basis, who processes it, how long it is kept, and the rights available to the person it concerns. Written against the actual platform architecture, not a generic template.
KYC / Identity Verification Notice
Explains why identity verification is required before the first ride, what documents are processed, who performs the check, what SYIBE keeps, and what happens if verification fails.
Facial Verification / Liveness Notice
Covers the selfie and liveness step used to confirm that the person opening the account is the person on the identity document, and that the capture is live rather than a photograph or recording.
Biometric Data Notice
A separate, explicit notice for any processing that may qualify as biometric, kept distinct from general privacy terms so consent is specific and withdrawable.
Location / GPS Data Notice
Explains why precise location is required for a shared mobility service, when it is collected, and how it differs between an active ride and idle app use.
Cookie Policy
Covers cookies and similar storage on the SYIBE website: strictly necessary, preference, analytics and — if ever used — marketing categories.
Data Retention & Deletion Policy
Defines how long each data category is kept, what is deleted, what is anonymised and what must be retained for accounting, safety or legal reasons.
Account Deletion Policy
How a person requests deletion, what happens immediately, what is retained by law, and how remaining balances or open matters are handled.
Marketing Communications Consent
A separate optional consent for promotional messages, kept fully independent from service messages required to deliver a ride.
Push Notification Consent
Separates operational notifications from promotional ones and explains device-level permission.
Law-Enforcement & Government Data Request Policy
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.
City & Municipality Data Reporting Framework
What operational data SYIBE shares with a city or municipality, and the privacy rules that constrain it. The framework is aggregated and anonymised by default; rider-level reporting is not created as a routine feature of city cooperation.
Money
Payment & Wallet Terms
Governs the SYIBE wallet, top-ups, authorisation holds, charges, failed payments and balance handling. Written provider-neutral so a payment provider can be added without rewriting the terms.
Cancellation Policy
Covers cancelling a reservation or aborting a ride before it effectively starts, and what is charged in each case.
Refund Policy
When SYIBE refunds a charge, in what form, within what timeframe, and how partial refunds are calculated.
Dispute / Chargeback Policy
How a rider challenges a charge, what evidence SYIBE reviews, decision timelines, and how external chargebacks are handled.
Promotions, Credits & Referral Terms
The standing rules for promotional codes, ride credit, referral rewards and campaign participation: how credit behaves in the wallet, what invalidates a reward, and where campaign-specific values live. All amounts, thresholds and limits are configuration, not fixed terms.
Riding rules
Safety Rules
The riding rules every rider accepts: eligibility, equipment, pre-ride checks, where riding is allowed, speed and behaviour.
Parking Policy
Where a ride may be ended, how parking is confirmed, and what happens when a vehicle is parked incorrectly.
Prohibited Use Policy
Uses that are never permitted and lead to immediate suspension, charges or legal action.
Community / Rider Code of Conduct
The behaviour SYIBE expects towards pedestrians, other road users, field staff and the city itself, and the consequences of breaching it.
Minimum Age / Eligibility Policy
Who may hold an account and ride: age threshold, verification requirement, licence position and the treatment of accounts found to be underage.
Incidents & vehicles
Accident & Incident Procedure
What a rider must do after an accident or injury, what SYIBE does, and how the incident is recorded and escalated.
Damaged Vehicle Policy
How damage is assessed, when a rider is responsible, how charges are calculated, and how a rider can contest an assessment.
Lost / Stolen Vehicle Procedure
The response ladder when a vehicle is unaccounted for, moved without authorisation or reported stolen.
Insurance & Liability Framework
The structure of what is and is not covered, how liability is allocated, and the notice a rider receives. This document must not state cover that does not exist.
Third-Party Claims Procedure
How a person who is not a SYIBE rider — a pedestrian, another road user, a property owner or a business — reports injury, damage or obstruction involving a SYIBE vehicle, and how that claim is received, investigated and answered.
Access & trust
Accessibility Statement
SYIBE's commitment to an accessible product and to public space that remains usable for everyone.
Service Availability, Interruption & Suspension Notice
What riders can expect about availability: that the service is not guaranteed to be continuous, the grounds on which SYIBE may reduce, pause or suspend service, how notice is given, and how an interruption affects an ongoing ride, a reservation, a wallet balance and a subscription.
Supplier & Partner Code of Conduct
The standards SYIBE requires of the companies that manufacture, ship, maintain, host, process and service its operation — labour and human rights, health and safety, environment, ethics, data protection and subcontracting — and how compliance is verified.
Vulnerability Disclosure & Security Reporting Policy
How to report a suspected security vulnerability in SYIBE's application, website or vehicles, what SYIBE undertakes in return, and the limits of testing. The policy deliberately describes the reporting route only and publishes no detail of SYIBE's internal security architecture.
Privacy architecture
Data use matrix
Every category the platform actually collects, mapped to purpose, basis, retention and the minimisation rule applied.
| Data | Purpose | Basis | Source | Retention | Minimisation |
|---|---|---|---|---|---|
| Phone number & account data | Account identity, OTP verification, service messages | Contract | Rider | Life of account + closure period | Number and locale only; no contact list access |
| Identity document | Age and eligibility, fraud and theft prevention | Contract + legitimate safety interest | Rider via verification provider | Verification cycle; reference retained, images at provider | SYIBE stores status, reference and expiry — not unnecessary document copies |
| KYC decision & risk score | Trust tier, ride authorisation | Contract | Verification provider | Life of account | Result and code only, no underlying provider payload |
| Face / liveness capture | Confirm the account holder is the document holder | Explicit separate consent | Rider via verification provider | Provider-held; SYIBE keeps score and reference | No biometric template stored by SYIBE, no reuse for other purposes |
| Device information | Security, fraud signals, push delivery, crash diagnostics | Legitimate interest | App | Rolling security window | Fingerprint and platform, no advertising identifiers |
| Precise location | Vehicle discovery, ride validation, zone enforcement | Contract + permission | Device & vehicle | Ride records; aggregated thereafter | Background precision during an active ride only |
| Ride route & history | Billing, safety, disputes, parking verification | Contract | Platform | Accounting & dispute period, then anonymised | Sampled telemetry, not continuous high-frequency tracking after the ride |
| Payment & wallet data | Authorisation, charging, refunds, ledger integrity | Contract + legal accounting duty | Rider via payment provider | Statutory accounting period | Tokens and references only; no full card data stored by SYIBE |
| Parking photographs | Confirm valid parking, resolve fee disputes | Contract | Rider | Short review window unless disputed | Vehicle and surroundings only; faces and plates blurred where feasible |
| Incident photographs & reports | Safety investigation, damage assessment, claims | Legitimate interest + legal claims | Rider & field operations | Until the case and any claim period closes | Case-linked access only, restricted to trust & safety roles |
| Support communications | Resolve tickets, disputes and complaints | Contract | Rider & agents | Case period + quality review window | No sensitive data requested in free-text channels |
| Fraud & security signals | Prevent theft, account takeover and payment abuse | Legitimate interest | Platform | Defined security period | Signals and scores, with human review before restriction |
| Vehicle telemetry | Availability, battery health, geofencing, theft response | Legitimate interest (asset operation) | IoT device | Operational window, then aggregated | Vehicle-centric; linked to a rider only during an active ride |
| Product analytics | Improve conversion, reliability and safety of flows | Legitimate interest / consent on web | App & website | Aggregated retention | Typed event taxonomy with a PII flag; no free-text payloads |
| Marketing preferences | Send only what the rider asked for | Consent | Rider | Until withdrawal + proof-of-consent period | Channel-level granularity, withdrawal recorded with version |
Consent architecture
Consent matrix
Where each consent is captured, whether it is required, whether it can be withdrawn, and whether the version is recorded in the consent ledger.
| Consent point | Documents | Status | Revocable | Versioned | Recording rule |
|---|---|---|---|---|---|
| Sign-up | Required | — | ✓ | Single affirmative action, with each document linked and version recorded. No pre-ticked boxes. | |
| Identity verification | Required | — | ✓ | Shown before the document capture step, not bundled into sign-up. | |
| Face / liveness check | Required | ✓ | ✓ | Separate explicit consent immediately before capture; withdrawal stops riding and deletes references. | |
| Location permission | Contextual | ✓ | ✓ | Explained in-app before the OS permission dialog; withdrawal blocks ride start, not account access. | |
| Payment / wallet setup | Required | — | ✓ | Accepted at wallet or payment-method setup, before the first authorisation hold. | |
| Ride start | Required | — | ✓ | Re-affirmed on first ride and after any material version change, with fare and rules on screen. | |
| Marketing preferences | Optional | ✓ | ✓ | Never required. Off by default, per channel, withdrawable in one step. | |
| Push notifications | Optional | ✓ | — | Device permission plus in-app category preferences; operational alerts remain in-app. | |
| Website cookie banner | Optional | ✓ | ✓ | Website only. Analytics and marketing categories blocked until accepted. | |
| Account deletion | Contextual | — | ✓ | Confirmation step states what is deleted, what is retained by law and how the balance is handled. | |
| Promotion / referral entry | Contextual | — | ✓ | Entering a code or referral records acceptance of the standing promotion terms plus the campaign's configured parameters shown on screen. Does not enrol the rider in marketing. |
Benchmarking
Structure benchmark and missing clauses
Established operators were used for structure only — no wording was copied. Items marked as recommended are industry-standard documents SYIBE does not have yet.
Layered agreements (platform terms + per-ride terms)
CoveredMature operators separate the master service terms from a per-ride rental contract so vehicle-specific liability is explicit.
Separate biometric notice
CoveredJurisdictions with biometric statutes require standalone, withdrawable consent rather than a clause inside privacy terms.
Parking evidence and review workflow
CoveredPhoto-based parking confirmation with an appeal route is now standard in permitted markets.
Suspension and appeal ladder
CoveredPublished consequence ladders reduce disputes and are expected by municipalities.
Third-party claims & bystander injury procedure
Recommended additionOperators publish a route for non-riders (pedestrians, drivers, property owners) to report damage or injury caused by a vehicle.
Law-enforcement & data-request policy
Recommended additionA published policy on how authority requests for rider or ride data are validated and logged.
Promotions, credits & referral terms
Recommended additionSeparate terms for promo codes, ride credit expiry and referral abuse are standard to prevent disputes.
Service availability & suspension of operations notice
Recommended additionOperators reserve the right to pause service for weather, public events or municipal instruction, and say so in advance.
Fleet & city data reporting commitment
Recommended additionPermitted operators commit to a defined data feed for regulators, with privacy safeguards on rider data.
Modern-slavery / supplier conduct statement
Recommended additionCorporate supplier-conduct statements are common for hardware-dependent operators.
Security vulnerability disclosure policy
Recommended additionA safe-harbour reporting policy is expected of platforms holding identity and payment data.
Dependency register
What must be resolved outside the product
| Dependency | Class | Blocks | Owner |
|---|---|---|---|
| Corporate entity, commercial registration and registered address | C · Jurisdiction-dependent | Terms, Privacy, contracts, invoicing | Founder / corporate counsel |
| Regulatory classification of the vehicle class | C · Jurisdiction-dependent | Eligibility, helmet rules, insurance, road use | Local counsel + municipality |
| Municipal operating permission and parking policy | C · Jurisdiction-dependent | Parking Policy, zones, service area, launch | City partnerships |
| Insurance programme | C · Jurisdiction-dependent | Insurance & Liability, incident and damage policies | Founder / broker |
| Data-protection obligations in Syria | C · Jurisdiction-dependent | Privacy Policy, retention, biometric notice, rights process | Local counsel |
| KYC / liveness provider selection | B · Provider-dependent | KYC and liveness notices, processor list, retention claims | Platform |
| Payment provider and settlement model | B · Provider-dependent | Payment & Wallet Terms, refunds, chargebacks | Platform / finance |
| SMS / OTP provider | B · Provider-dependent | Service messaging terms, delivery guarantees, sender identity | Platform |
| IoT hardware and telemetry contract | B · Provider-dependent | Telemetry disclosure, immobilisation, theft procedure | Platform / supplier |
| Maps and geocoding provider | B · Provider-dependent | Location notice, attribution and provider terms | Platform |
| Final pricing, caps and penalty schedule | D · Commercial-dependent | Ride Terms, Parking Policy, Cancellation, Damage | Commercial |
| Refund and dispute service levels | D · Commercial-dependent | Refund and Dispute policies | Support / finance |
| Wallet balance refundability decision | D · Commercial-dependent | Payment terms, account deletion | Finance |
| Competent authorities, legal instruments and notification limits for data requests in Syria | C · Jurisdiction-dependent | Law-Enforcement & Government Data Request Policy, emergency track, transparency reporting | Local counsel |
| Named emergency-release authoriser and out-of-hours escalation chain | A · Universal platform policy | Emergency request handling | Founder / operations |
| Municipal data-reporting scope, aggregation level and data-sharing agreement | C · Jurisdiction-dependent | City & Municipality Data Reporting Framework, analytics export | City partnerships + local counsel |
| Third-party claim handling route and limitation periods | C · Jurisdiction-dependent | Third-Party Claims Procedure, evidence retention | Local counsel / broker |
| Campaign configuration model: amounts, thresholds, caps and expiry per city | D · Commercial-dependent | Promotions, Credits & Referral Terms, wallet ledger | Commercial / finance |
| Service-availability thresholds, operating hours and city-exit notice period | D · Commercial-dependent | Service Availability, Interruption & Suspension Notice | Operations / commercial |
| Supplier contracting model, audit rights and battery recycling routes | A · Universal platform policy | Supplier & Partner Code of Conduct | Procurement / founder |
| Safe-harbour enforceability under local computer-misuse law | C · Jurisdiction-dependent | Vulnerability Disclosure & Security Reporting Policy | Local counsel |
| Reporting mailboxes live: claims@, legal@, security@, conduct@ | A · Universal platform policy | All four new intake routes | Platform / operations |
CMS
Versioning and content management architecture
Legal content is stored in the backend, not hard-coded: bilingual bodies, version numbers, effective dates, re-consent flags and an append-only consent ledger.
Content model
- legal_documents — slug, bilingual title, category, dependency class, review status, consent requirement, consent surfaces, revocability, publication flag.
- legal_document_versions — version number, effective date, EN/AR body, summary, publication flag, current flag, material-change flag, re-consent flag, jurisdictions and city codes.
- consent_records — append-only: user, document slug, version, surface, accepted or withdrawn, locale, city, timestamp, device context.
- site_flags — publication switches for corporate blocks, including the Founder section show/hide.
Publication rules
- Only one version per document is current; previous versions stay published as an archive with their effective dates.
- Public read access is limited to published documents and published versions; drafts are admin-only.
- A version marked as a material change sets requires_reconsent, which forces re-acceptance at the next relevant surface.
- Jurisdiction and city applicability are stored per version so a city can run a different edition.
Editing and audit
- Only the admin role may create, edit, publish or unpublish documents, versions and flags.
- Consent records are insert-only for riders and readable by admin, support and finance for dispute handling.
- Every publication action is written to the platform audit log with actor, before and after state.
- Legal copy is never hard-coded in the application; the content module in the repository is the seed, the CMS is the source of truth.
Before publication
Legal review checklist
| Item | Required by |
|---|---|
| Corporate entity finalised and named in every document | Before publication |
| Regulatory classification of the vehicle class confirmed | Before public launch |
| Municipal permission and parking policy aligned with the Parking Policy | Before public launch |
| Insurance structure finalised; Insurance & Liability rewritten to match | Before public launch |
| Payment provider selected; Payment & Wallet Terms and Refund Policy updated | Before first real charge |
| KYC and liveness providers selected; notices updated with retention behaviour | Before first real verification |
| Biometric processing lawfulness confirmed by local counsel | Before liveness goes live |
| IoT and hardware structure finalised; telemetry disclosure verified | Before first real vehicle |
| Retention periods mapped to statutory accounting and identity duties | Before publication |
| Consumer-protection, unfair-terms and liability-limitation review | Before publication |
| Arabic legal text reviewed by an Arabic-language legal professional | Before publication |
| Recommended additions adopted or formally declined | Before publication |
| Consent recording verified end to end against the consent matrix | Before first real rider |
| Law-enforcement request policy reviewed: competent authorities, valid instruments, notification limits and the emergency track | Before first real rider |
| Emergency-release authoriser named, trained and reachable out of hours | Before first real rider |
| Staff instructed never to confirm whether a person is a SYIBE customer, and to route every data request to the single legal channel | Before first real rider |
| City reporting scope agreed in writing, with aggregation, suppression threshold and no rider-level feed | Before public launch |
| Third-party claims intake live and answerable without a SYIBE account | Before first real vehicle |
| Promotion and referral parameters held in configuration only; no amount or threshold hard-coded | Before first campaign |
| Service-availability status surface and interruption notices working in the application | Before public launch |
| Supplier Code incorporated into every hardware, logistics and processing contract | Before first supplier order |
| Safe-harbour wording confirmed by counsel; security.txt published; security@ monitored | Before publication |
| Cross-document consistency check re-run after every future amendment, not only at v1 | Ongoing |