Privacy Policy

We collect the following categories of personal data. Each category lists representative example fields and the primary purpose; full retention windows are summarised in §8 and the lawful basis is summarised in §3.

• Account data — name, email address, username, role within your tenant, password (bcrypt-hashed at cost factor 12; we never see the plaintext, and we cannot recover it), language preference, time zone, account-creation timestamp, last-successful-login timestamp, last-successful-login IP (truncated to /24). Used to authenticate you, route you to the correct tenant, and audit actions performed under your account.
• Profile data — phone number (optional), preferred greeting, professional title (optional), profile avatar URL (if provided), notification preferences (digest cadence, mute windows). Provided by you; you can update or remove these at any time from your profile page.
• Tenant-membership data — your role within a tenant (Owner, Admin, Advisor, Viewer), the date you joined the tenant, who invited you, and the scope of any per-feature permission grants.
• Authentication artifacts — server-side session records (session ID, expiry, the bound user agent + /24 IP block, last-seen timestamp), email verification tokens (short-lived, single-use), password reset tokens (short-lived, single-use), Google OAuth identifiers when you sign in via Google, and (where enabled) WebAuthn credential public keys. We never store private keys.
• Customer-supplied portfolio data — holdings, transactions, beneficiary structures, uploaded documents, account balances, target allocations, IPS / mandate documents, custodian references, target-tax lots. We act as Processor; the customer entity is Controller. Specific rules around this data are in the DPA. We do not control which individuals appear in this data; the customer is responsible for the lawful basis for processing.
• Beneficiary and family-tree data — where Customer Data includes individuals other than the authenticated user (Faraid heirs, Zakat dependants, named trustees, executors), this is Customer Data and remains under the Customer’s controllership. We do not contact beneficiaries directly.
• Document and file metadata — file name, MIME type, size, SHA-256 hash, uploader identity, upload timestamp, and per-document tenant scoping. The file body is encrypted at rest and is accessible only via tenant-scoped requests.
• Device + connection data — IP address (for audit + rate-limiting; truncated to /24 before any external transmission), user-agent, broad device class, approximate locale derived from Accept-Language. Browser-side cookies only as described in §5.
• Operational telemetry — request logs, error reports (sent to our Sentry-protocol observability stack with PII scrubbed), product analytics events (PostHog: event names + categorical properties, never query content or financial values). See §10 for the explicit denylist of fields and the scrubber pipeline.
• Audit-log data — every authenticated state-changing action recorded with actor user ID, tenant ID, action type, target resource ID, request ID, IP /24 block, and timestamp. Logs are immutable and retained per §8.
• AI Analyst interactions — when you use AI features, the question text and the relevant data context are sent to Anthropic for processing. We retain a hashed prompt fingerprint, token-count metadata, and surface identifier for cost attribution and rate-limit accounting. See §4 for the safeguards on this transfer.
• Support and feedback data — content of support tickets, in-app feedback you submit, and any screenshots you attach. Do not paste credentials or third-party PII into support; use the secure data- share path instead.
• Marketing-site data — for visitors to our public marketing site only: page-view events, referrer (if provided), opt-in newsletter email address. We do not run cross-site advertising trackers.
• Billing data — managed entirely by Stripe; we receive only a Stripe customer identifier, the subscription identifier, the tier+amount you pay, the billing email, and the country of the billing address (for VAT determination). We never see card numbers, CVVs, or full billing addresses.
• Survey, NPS, and research data — if you choose to participate in optional research sessions or NPS prompts, the responses you submit and any identifying context you choose to include. Always optional.

Most personal data is provided directly by you or by your tenant administrator. Some is generated automatically by your interaction with the Service (telemetry, audit logs, derived analytics outputs). A limited subset comes from third parties, as listed below.

• You. When you create an account, complete your profile, upload Customer Data, type free-text questions to the AI Analyst, attach documents, or contact support.
• Your tenant administrator. When you are invited to a tenant, the admin provides your email, role, and (optionally) display name. Admins may also upload Customer Data describing you (for example, an internal staff directory).
• The Service itself. Server-side logs, audit entries, derived analytics outputs (returns, risk metrics, Sharia score, Faraid distribution), and AI prompt-attribution metadata are generated by your authenticated activity.
• Stripe — billing identifier, subscription state, invoice metadata, and payment-status events surfaced via webhook.
• Google — when you sign in via Google OAuth, we receive your name, primary email, the unique Google subject identifier, and your locale. We do not request access to Drive, Calendar, Gmail, Contacts, or any other Workspace scope.
• Public market-data providers — for pricing, FX, and reference data attached to Customer holdings. These providers do not receive personal data from us; only instrument identifiers.
• Sanctions / KYC lists — where the Customer enables sanctions screening (Tier 3+), beneficiary names supplied by the Customer are matched against publicly published sanctions lists.

We process personal data on the following lawful bases. The terminology is aligned with PDPL Article 4, GDPR Article 6 (and Article 9 for any special-category data), DIFC Data Protection Law Article 10, and ADGM Data Protection Regulations 2021 Section 4.

• Contract (PDPL Art. 4(1), GDPR Art. 6(1)(b), DIFC Art. 10(1)(b), ADGM s. 4(1)(b)). To deliver the Service you subscribed to: account creation, authentication, tenant provisioning, analytics generation, AI Analyst answers, document storage, billing.
• Legitimate interests (GDPR Art. 6(1)(f), DIFC Art. 10(1)(f), ADGM s. 4(1)(g); PDPL recognises an analogous “protection of Controller’s legitimate interests” basis in Art. 4(7)). Security, fraud prevention, audit-trail integrity, product improvement, error diagnostics, network and information security, abuse-prevention rate limits, and communicating service-related notices. Where we rely on legitimate interests we have conducted a balancing test against the rights and freedoms of data subjects; you can request the assessment via privacy@operafo.ae.
• Legal obligation (PDPL Art. 4(2), GDPR Art. 6(1)(c), DIFC Art. 10(1)(c), ADGM s. 4(1)(c)). UAE federal tax record-keeping (currently seven (7) years), AML / sanctions obligations where applicable, lawful regulator requests, court orders, and DFSA / FSRA examinations to which a Customer may be subject.
• Consent (PDPL Art. 6, GDPR Art. 6(1)(a), DIFC Art. 10(1)(a), ADGM s. 4(1)(a)). Marketing emails (you can unsubscribe at any time from any message), optional integrations you opt into (e.g. enabling marketing-site PostHog analytics). Consent is withdrawable; withdrawal does not affect the lawfulness of processing carried out before withdrawal. We do not rely on consent for the core Service functionality.
• Vital interests (GDPR Art. 6(1)(d), DIFC Art. 10(1)(d)). Rare; would only apply to a life-threatening incident requiring disclosure.
• Public interest / official authority (GDPR Art. 6(1)(e)). Generally not relied upon by OperaFO; included for completeness.
• Customer instructions. For data we process on behalf of a customer Controller, the lawful basis runs from the customer to the data subject; OperaFO acts only on the customer’s documented instructions per the DPA. Where a Customer has documented its own balancing test or consent collection, OperaFO relies on the Customer’s representation.

Where Customer Data includes any special-category personal data within the meaning of GDPR Art. 9 (for instance, religious affiliation inferred from participation in Sharia or Zakat workflows), the Customer is responsible for the additional Art. 9 lawful basis (typically explicit consent or a substantial-public-interest basis under local law).

When you use AI Analyst features (Daily Brief, PortfolioConcierge, AI summary cards on dashboard / risk / Sharia / cash-flow surfaces, Morning Brief for Tier 4 tenants), the following data leaves OperaFO’s infrastructure and is processed by Anthropic at its US data centres under their enterprise data-protection terms:

• the prompt (system prompt + the question you asked + the context we attached, e.g. portfolio holdings as needed by the surface);
• the response, which is then displayed in the UI and may be cached by us for the period stated in the feature’s documentation (Daily Brief: 24 h; on- demand summaries: not cached unless you save the run);
• request-side metadata (model identifier, token counts, latency, cost-attribution tenant ID) for accounting and rate-limit enforcement.

Inputs that may be sent to the model.

• the system prompt (templated, version-pinned per surface);
• the user question or instruction you typed;
• the structured data context the surface attaches — for example, a holdings snapshot for the dashboard brief, a risk-decomposition table for the risk brief, a Sharia compliance snapshot for the Sharia brief, or a cash-flow projection for the cash-flow brief;
• for the Morning Brief (Tier 4): a curated set of recent portfolio events, news headlines we have ingested, and a bounded slice of the audit log;
• any free-text notes or rationale you choose to attach to a proposal decision.

PII scrubber denylist. Free-text fields (the question you typed, your notes, your free-text rationale on a proposal decision) are passed through a regex PII scrubber before leaving our trust boundary. The scrubber implementation lives at api/common/pii_scrubber.py and is pinned by contract tests. The current denylist masks:

• email addresses (RFC 5322-shaped local-part + domain);
• international phone numbers in E.164 form (e.g. +9715XXXXXXXX) and common UAE/Gulf local formats;
• IBANs and bank-account-shaped numerics;
• payment-card-shaped digit runs that pass a Luhn check;
• Emirates ID numbers (784-YYYY-XXXXXXX-X);
• passport-number-shaped tokens for common nationalities in our customer base;
• API-key-shaped tokens (long base64 / base58 / hex strings, JWT-shaped triplets, Stripe key prefixes, Anthropic key prefixes);
• IPv4 / IPv6 addresses appearing in free text.

Counsel reviews any change to the denylist; the scrubber fails closed (no LLM call is made if scrubbing throws).

Enterprise terms with Anthropic.

• Anthropic operates under a zero-day-retention contract for our enterprise tenant: prompts and responses are not retained beyond the request lifecycle.
• Inputs and outputs are not used to train shared or foundational models.
• Model traffic is sent over TLS 1.3 to Anthropic endpoints; the API key is held only on the API service, never on the client.
• We never send Customer Data to public AI services (consumer ChatGPT, public Bard / Gemini, public Mistral le Chat, etc.).

Opt-out path. A Tenant Owner may disable AI Analyst features for their tenant from Settings → AI; doing so removes the AI surfaces from the UI and prevents any further outbound model traffic for that tenant. Existing cached AI responses are purged within twenty-four (24) hours of opt-out. Individual users on a tenant where AI is enabled can simply not use the AI surfaces; no AI traffic is generated by passive navigation.

Other cross-border transfers. Our hosting region is [counsel to confirm: Helsinki / EU- Central via Hetzner Online GmbH]. Transfers outside the host jurisdiction occur for: Anthropic (US) for AI; Stripe (US) for billing; PostHog (US/EU, depending on deployment region) for product analytics; the Sentry-protocol observability provider (EU, GlitchTip self-hosted in our own region) for error reporting; and the transactional-email provider (region depending on final selection — see §11). Each is subject to Standard Contractual Clauses or equivalent transfer mechanisms recognised by the regulator(s) applicable to you. The current sub-processor list and transfer- mechanism table is maintained at /legal/dpa.

We use a minimal cookie set. The authenticated product sets only the strictly necessary cookies required to operate sessions and remember your locale; the marketing site additionally sets an analytics cookie when you consent to telemetry. We do not use third-party advertising cookies, social-network tracking pixels, or ad-targeting tools on the authenticated app.

Cookie schedule (authenticated app).

• of_session — purpose: holds the session bearer token. Scope: webapp.operafo.ae. Attributes: HttpOnly, Secure, SameSite=Strict, Path=/. Expiry: ~7 days (sliding). Strictly necessary; the Service cannot function without it.
• of_session_exp — purpose: paired with of_session, holds the session-expiry timestamp so the client can warn you before forced logout. Scope: webapp.operafo.ae. Attributes: Secure, SameSite=Strict, Path=/ (not HttpOnly so the client can read the timestamp). Expiry: matches of_session. Strictly necessary.
• of_csrf — purpose: double-submit CSRF token bound to the session. Scope: webapp.operafo.ae. Attributes: Secure, SameSite=Strict, Path=/. Expiry: matches the session. Strictly necessary.
• of_locale — purpose: language preference (en / ar). Scope: webapp.operafo.ae. Attributes: Secure, SameSite=Lax, Path=/. Expiry: 365 days. Convenience.
• of_theme — purpose: light / dark theme preference. Scope: webapp.operafo.ae. Attributes: Secure, SameSite=Lax, Path=/. Expiry: 365 days. Convenience.
• of_tenant — purpose: last active tenant for users with access to multiple tenants. Scope: webapp.operafo.ae. Attributes: Secure, SameSite=Strict, Path=/. Expiry: 30 days. Convenience.

Cookie schedule (marketing site).

• of_consent — purpose: records your cookie-consent choice on the marketing site. Scope: www.operafo.ae and operafo.ae. Attributes: Secure, SameSite=Lax. Expiry: 365 days. Strictly necessary.
• ph_* (PostHog) — purpose: product analytics on the marketing site only when telemetry is enabled. Scope: marketing site domain. Attributes: Secure, SameSite=Lax. Expiry: up to 365 days. Set only after you accept analytics consent. Not set on the authenticated app routes at all.

We do not use third-party advertising cookies, social- network tracking pixels, or ad-targeting tools on the authenticated app. The marketing site does not set personalisation cookies for behavioural advertising. Browser-side local storage is used by the authenticated app for non-sensitive UI preferences only (table column-widths, last-opened panel); session credentials are never stored in localStorage or sessionStorage.

We use personal data for the purposes set out below. Each purpose is bound to a lawful basis in §3.

• To operate, render, and maintain the Service — including provisioning your tenant, applying your per-tier feature flags (Tier 1 Free, Tier 2 Starter, Tier 3 Professional, Tier 4 Agentic), and keeping your data available across deploys.
• To authenticate users and apply tenant-level row-level security so users in tenant A cannot see data in tenant B (enforced at the database role level via Postgres FORCE ROW LEVEL SECURITY on the application role).
• To run computed analytics on the data Customer supplies — risk, allocation, returns, concentration, regime, liquidity, scenario stress, Sharia compliance scoring, Faraid succession distribution, Zakat calculation, target-band drift detection.
• To provide AI-augmented narratives via Anthropic, with the safeguards in §4.
• To maintain a complete audit trail of authenticated actions (your tenant’s own; exportable on request) for compliance, internal investigation, and customer self-service.
• To send transactional emails — welcome, email verification, password reset, billing receipts, security alerts, service incident notifications, tenant-membership changes, and feature change-log notices for material changes. These are not marketing.
• To prevent abuse — rate limiting at the route, user, and IP-block level; anomaly detection; suspension after repeated failed logins; bot challenge on the marketing site sign-up.
• To improve the product through aggregate analytics (event names + categorical properties; see §1 and §10). Individual prompts and Customer Data values are never used for product analytics.
• To debug errors and incidents using PII-scrubbed error reports, with engineer access logged and time- bounded.
• To send service-related communications about scheduled maintenance, breaking changes, and end-of-life of features.
• To send opt-in marketing communications where you have consented; you can unsubscribe at any time from any message.
• To comply with applicable law and respond to lawful regulator or court requests, subject to our process for verifying validity (§7).
• To enforce our Terms of Service, investigate misuse, and protect the safety of our users, our staff, and the public.

We disclose personal data only:

• to sub-processors we engage to provide the Service (the current list is in §11). Each is bound by contractual obligations no less protective than this Policy and the DPA, and is used only for the purpose disclosed.
• to your tenant administrator (the Controller). Tenant admins can see audit trails and user activity within their tenant; they cannot see data in other tenants. Activity within a tenant attributed to your account is visible to admins of that tenant.
• to professional advisors (auditors, external counsel, accountants) under written confidentiality, where reasonably necessary for the governance of OperaFO itself. Such disclosure is always limited to the minimum necessary.
• to regulators or law enforcement when required by a binding legal request, subject to our process for verifying validity. We push back on overbroad requests, give notice to affected Controllers where lawful, and limit production to the minimum necessary. Requests should be served on legal@operafo.ae.
• to a buyer or successor in a merger, acquisition, or sale of all or substantially all of our assets, subject to confidentiality and the buyer’s commitment to honour the same Privacy Policy. We will give thirty (30) days’ advance notice of any such transfer to tenant owners.
• to insurers and forensic responders in the event of a security incident, under confidentiality and only to the extent necessary for incident handling.
• with your express consent for any other purpose.

We do not sell personal data, we do not rent or trade personal data, and we do not share personal data with advertising networks for cross-site behavioural advertising. We do not use Customer Data to train shared AI models.

We retain personal data only for as long as we need it for the purposes described in this Policy, plus any period required by law or for legitimate business purposes (audit, dispute resolution, fraud prevention, tax, regulator examinations).

Approximate retention windows by category (final windows pending counsel confirmation by Customer regulator):

• Account data — for the lifetime of the account, plus seven (7) years for audit-log integrity. Tenant owners may request earlier deletion subject to outstanding legal-hold requirements.
• Profile data — for the lifetime of the account. Removed within thirty (30) days of deletion request, subject to legal-hold.
• Authentication artifacts — sessions expire after seven (7) days idle (rotation-based); email-verification and password-reset tokens are invalidated within twenty-four (24) hours of issue or on use, whichever is sooner.
• Customer-supplied portfolio data — for the lifetime of the tenant; on tenant termination, exported on request and deleted within thirty (30) days plus the routine backup-aging cycle (up to ninety (90) days additional in immutable backup snapshots).
• Beneficiary and family-tree data — same as Customer-supplied portfolio data.
• Document and file metadata + bodies — for the lifetime of the tenant; on deletion of an individual document the body is unlinked immediately and purged from primary storage within seven (7) days, with backup-aging up to ninety (90) days.
• Audit logs — seven (7) years (immutable; default). Customer regulator (FATF / DFSA / FSRA / SCA) expectations vary; counsel to confirm exact windows by regulator. Where a Customer is subject to a longer statutory retention than seven (7) years, the longer period applies for that Customer.
• Request logs and operational metrics — ninety (90) days.
• Raw error reports (Sentry-protocol) — thirty (30) days.
• Product-analytics events (PostHog) — twelve (12) months at event grain; longer at aggregated grain.
• AI Analyst interaction logs — twelve (12) months at our side (for cost attribution and rate-limit accounting); Anthropic retains nothing beyond the request lifecycle.
• AI response cache — Daily Brief: up to twenty-four (24) hours; on-demand summaries: not cached unless you save the run; saved runs: lifetime of the tenant or until you delete them.
• Billing records — seven (7) years per UAE federal tax record-keeping requirements.
• Support and feedback data — twenty-four (24) months from ticket close, then archived in a redacted form for trend analysis.
• Marketing consent records — for as long as you remain subscribed, plus three (3) years after unsubscribe to evidence the prior opt-in.
• Legal-hold data — for the duration of the legal hold, regardless of any earlier deletion schedule.

After the applicable retention period, data is either deleted or irreversibly aggregated such that it can no longer identify a data subject.

Subject to applicable law (PDPL Articles 13–19, GDPR Articles 15–22, DIFC Articles 32–39, ADGM Sections 17–22), you have the rights below. For data we process as Processor on behalf of a Customer, we will route your request to the Customer; please contact your tenant administrator first where your data is in a tenant.

• Access. You can request a copy of the personal data we hold about you, the categories, the recipients, the retention period, the source (if not collected from you), and the existence of any automated decision-making.
• Correct. You can ask us to correct personal data that is inaccurate or incomplete. Most fields you can edit yourself from your profile.
• Erase. You can ask us to delete personal data, subject to our retention obligations and the rights of other parties (e.g. audit-log entries that document an action you performed under your account may need to remain for the audit- retention period). We will tell you which records we cannot delete and on what basis.
• Restrict certain processing — for example while we verify the accuracy of contested data, or while we evaluate your objection.
• Object to processing based on legitimate interests; we will stop unless we demonstrate compelling legitimate grounds that override your interests, rights, and freedoms, or the processing is necessary for the establishment, exercise, or defence of legal claims.
• Port your personal data to another service in a structured, commonly used, machine-readable format. For Customer Data, the Tenant Owner can export from Settings → Export.
• Withdraw consent where consent was the basis (e.g. marketing emails). Withdrawing consent does not affect the lawfulness of processing based on consent before its withdrawal.
• Not be subject to solely automated decisions with legal or similarly significant effects (see §15).
• Lodge a complaint with the relevant supervisory authority — see §13.

How to submit a request. Email privacy@operafo.ae from the email address associated with your account where possible. Tell us which right you are exercising and, where it is not obvious from your account, what data the request relates to.

How we verify your identity. For low-risk requests (e.g. unsubscribe) we rely on a signed reply from the registered email address. For higher-risk requests (access, erasure, port) we may require you to confirm the request from your authenticated session, send a confirmation token to your registered email, or — if your account is no longer active — provide additional information sufficient to establish that the data relates to you. We do not request copies of government ID unless there is no less-intrusive alternative.

Response timelines. We acknowledge receipt within seventy-two (72) hours. We respond substantively within thirty (30) days, extendable by a further sixty (60) days where the complexity or volume of the request requires it; we will tell you within thirty (30) days if we need the extension and why.

Fees. Requests are free. We may charge a reasonable fee or refuse to act only if a request is manifestly unfounded or excessive (in particular, because of its repetitive character).

Exemptions. Some data may be exempt from disclosure or deletion — for example, audit logs required by law, data subject to legal privilege, data whose disclosure would compromise security or another person’s rights, and aggregated or pseudonymised data that can no longer be linked to you. We will explain each exemption that applies.

We implement technical and organisational measures designed to protect personal data against unauthorised or unlawful processing, accidental loss, destruction, or damage. The current measures include:

• Tenant isolation. Postgres FORCE ROW LEVEL SECURITY policies enforced at the database role level (operafo_app). The role cannot see rows for any tenant other than the one bound to its current session GUC. Tenant binding is established by the authentication middleware and audited on every request. Independently verified by an automated isolation check that runs against the live database and is pinned in the test suite gating every release.
• Encryption in transit. TLS 1.3 preferred, TLS 1.2 minimum, modern cipher suites only, HSTS with preload, certificate pinning at the load balancer for upstream calls to Anthropic and Stripe.
• Encryption at rest. AES-256-GCM at the database-volume layer; backups are encrypted with separate keys; uploaded documents are encrypted with a per-tenant key. Keys are rotated on a defined schedule and on personnel change.
• Authentication. bcrypt password hashing at cost factor 12 with rotating salts. HttpOnly + Secure + SameSite=Strict session cookies. CSRF double-submit token. Same-origin gating on the login endpoint. Rate-limited failed-login lockout per account and per IP. Optional Google OAuth. Optional WebAuthn / passkeys.
• Authorisation. Role-based access control at the route and resource level. Per-tenant feature flags. Defence-in-depth: even with a bypassed authorisation check at the application layer, RLS prevents cross-tenant reads.
• PII scrubber. Free-text fields are passed through a regex scrubber before any external transmission. Denylist + regex are pinned by contract tests in api/tests/common/test_observability.py. See §4 for the full denylist.
• Secrets management. Production secrets are held in environment configuration that is not in source control; access is limited to named engineers; rotation is logged.
• Audit logging. Every authenticated state-changing action is logged with actor, tenant, timestamp, request ID, and target resource. Logs are immutable. Customers can request a tenant-scoped export at any time.
• CI security gates. Static analysis, dependency-vulnerability scanning, secret-scanning on every commit. The PII-scrubber contract tests, the RLS verification, and the cookie-attribute tests are required-to-merge.
• Incident response. Documented in internal runbooks. Severity ladder, designated on-call, customer-comms templates. Tenant owners are notified of any customer-impacting incident within seventy-two (72) hours of discovery, and within shorter periods where applicable law requires.
• Backups and disaster recovery. Daily VPS-level snapshots with seven-day retention; database-level pg_dump on a separate cadence for catastrophic-recovery objectives; documented RTO and RPO targets; periodic restore drills.
• Vendor management. Each sub-processor is on a written processing agreement with SCCs or equivalent transfer mechanisms where applicable; sub-processors are reviewed at least annually for posture (compliance reports, breach history, certifications).
• Personnel. Access to production data is limited to a small number of named engineers under written confidentiality. Joiners-Movers-Leavers process: access is provisioned only after written approval; on role change, access is reviewed within fourteen (14) days; on departure, access is revoked within twenty-four (24) hours of the last working day. Engineers complete annual security and privacy training.
• Endpoint posture. Engineering laptops are full-disk encrypted, screen-locked, patched on a managed cadence, and have host-based controls.
• Logging and monitoring. Centralised application logs and metrics; alerting on anomalies (failed-login spikes, RLS violations, error-rate shifts, unusual outbound model traffic).
• Network controls. Production network is segmented; database is not directly exposed; the application service speaks only to whitelisted egress endpoints.

No security regime is perfect; we will continue to improve as the platform matures and as new risks emerge. The current staging environment runs at webapp.operafo.ae under the same hardening as production.

Our current sub-processor list, with the legal entity, purpose, data categories shared, transfer mechanism, and certification status. Items marked [counsel to confirm] are provisional pending counsel finalisation and may change before general availability.

• Anthropic, PBC (US) — purpose: AI Analyst features (Daily Brief, PortfolioConcierge, AI summary cards, Morning Brief). Data shared: scrubbed prompt + structured data context; no raw PII in free-text fields after the scrubber. Transfer mechanism: SCCs / equivalent under enterprise data-protection terms; zero-day retention; no model training on inputs. Certification: SOC 2 Type II [counsel to confirm: latest report].
• Stripe, Inc. (US) — purpose: billing, subscription management, invoicing. Data shared: subscription identifier, billing email, tier + amount, billing-country (for VAT). Transfer mechanism: SCCs. Certification: PCI-DSS Level 1, SOC 1 Type II, SOC 2 Type II, ISO 27001.
• Hetzner Online GmbH (Germany / Finland) — purpose: primary hosting (compute, network, storage). Data shared: all data necessary to host the service. Transfer mechanism: processing agreement under GDPR Art. 28; primary region Helsinki / EU-Central. Certification: ISO 27001.
• GlitchTip (self-hosted Sentry-protocol observability) — operated by us in our hosting region — purpose: error reporting and diagnostics. Data shared: PII-scrubbed event payloads, stack traces, breadcrumbs, request IDs. Transfer mechanism: not a third-party transfer (run in our own infrastructure).
• PostHog, Inc. [counsel to confirm: EU region] — purpose: product analytics and feature-flag service. Data shared: event names, categorical properties (tier, surface, route), pseudonymised distinct IDs. Never receives query content or financial values. Transfer mechanism: SCCs where US region is used. Certification: SOC 2 Type II [counsel to confirm].
• [counsel to confirm: transactional email provider — e.g. Postmark / Amazon SES] — purpose: delivery of transactional emails (welcome, verification, password reset, billing receipts, security alerts, service incident notifications). Data shared: recipient email, subject, body, delivery metadata. Transfer mechanism: SCCs where applicable. Certification: SOC 2 Type II [counsel to confirm].
• [counsel to confirm: market-data provider] — purpose: pricing, FX, instrument reference data. Data shared: instrument identifiers only; no personal data.
• [counsel to confirm: sanctions / KYC list provider] (only where the Customer enables the feature on Tier 3+) — purpose: matching beneficiary names against publicly published sanctions lists. Data shared: name strings supplied by the Customer.
• Cloudflare, Inc. (US/global) [counsel to confirm] — purpose: CDN and WAF for the marketing site. Data shared: standard request metadata (IP, user-agent, URL). Transfer mechanism: SCCs.

We notify customer tenant owners at least thirty (30) days before adding a new sub-processor or materially changing the role of an existing one. Notice is by email and a change to the published list at /legal/dpa. Customers may object on reasonable grounds; the objection process is set out in the DPA.

The Service is intended for B2B use by family-office professionals; it is not directed at, nor do we knowingly collect personal data from, children under sixteen (16) years of age. We do not run advertising or profiling targeted at children, and the marketing site does not use age-gating because it is not aimed at a child audience.

If you believe we hold personal data of a child in error, please contact privacy@operafo.ae and we will promptly delete it.

Children appearing in Customer Data. Where Customer Data uploaded into a tenant pertains to a minor — for example, a child named as a beneficiary in a Faraid succession scenario, a Zakat dependant, or a future-trust beneficiary — this is Customer Data and remains under the Customer’s controllership. The lawful basis runs from the Customer Controller, and the Customer is responsible under PDPL, GDPR Article 8, DIFC, ADGM, and UAE Federal Decree-Law No. 3 of 2016 on the Rights of the Child (Wadeema Law) for obtaining any consent or other lawful basis required. We process such data only on the Customer’s documented instructions and apply the same technical safeguards as adult-subject personal data, including tenant isolation, encryption, and the AI input scrubber. We do not contact the child directly under any circumstances.

Where a Customer is a regulated entity (DFSA / FSRA / SCA), the Customer’s own client-onboarding rules may impose additional protections; this Policy does not displace those protections.

You have the right to lodge a complaint with the relevant data-protection supervisory authority for your jurisdiction. Where reasonable, we ask that you contact us first at privacy@operafo.ae so we have an opportunity to resolve the issue directly; you are not required to do so before approaching the regulator.

• UAE PDPL. The UAE Data Office established under Federal Decree-Law No. 45 of 2021. Complaints can be filed via the official channels published by the UAE Data Office.
• ADGM. Office of the Data Protection Commissioner of the Abu Dhabi Global Market — https://www.adgm.com.
• DIFC. Commissioner of Data Protection of the Dubai International Financial Centre — https://www.difc.ae/business/operating/ data-protection/.
• EU. Your local Data Protection Authority (e.g. Datatilsynet (DK), CNIL (FR), AEPD (ES), DPC (IE)).
• UK. The Information Commissioner’s Office (https://ico.org.uk).
• KSA. The Saudi Data & AI Authority (SDAIA) — for residents covered by the Saudi PDPL.
• Other jurisdictions. Your local data-protection authority where one exists.

Our Data Protection contact. Our designated Data Protection contact is reachable at privacy@operafo.ae. Postal address: OperaFO Technology Services LLC, [counsel to confirm: registered address], United Arab Emirates. [Counsel to confirm whether a formal DPO appointment is required given current scale and processing posture under PDPL Art. 10, GDPR Art. 37, DIFC, and ADGM regimes.]

Security disclosures. Vulnerability reports go to security@operafo.ae. We do not currently run a paid bug-bounty programme but we acknowledge good-faith research and do not pursue researchers who follow responsible-disclosure norms.

The Service is operated from the United Arab Emirates and hosted in [counsel to confirm: EU-Helsinki via Hetzner]. If you access the Service from outside the host jurisdiction, you understand that your personal data will be transferred to and processed in jurisdictions whose data-protection regimes may differ from those of your country of residence. We rely on Standard Contractual Clauses or equivalent mechanisms recognised by the regulator(s) applicable to you for international transfers — see §4.

What happens by jurisdiction.

• UAE / GCC. Data is hosted in the EU and replicated to the UAE only where the Customer’s regulator requires onshore hosting (currently arranged on a Customer-by-Customer basis under the DPA). PDPL applies; ADGM / DIFC apply where the Customer is established in those free zones.
• EU / EEA. GDPR applies. Transfers of EU-origin personal data outside the EU/EEA rely on SCCs (Module Two for controller-to-processor transfers, Module Three where a sub-processor is involved) supplemented by transfer-impact assessments for the destinations listed in §11.
• UK. UK GDPR applies. We use the UK’s International Data Transfer Agreement (IDTA) or the UK Addendum to the EU SCCs.
• KSA. The Saudi Personal Data Protection Law (PDPL) applies to data subjects in KSA. Transfers outside KSA rely on the SDAIA- approved transfer mechanisms.
• Singapore. The PDPA applies. We comply with the transfer-limitation obligation by way of contractual clauses with sub-processors that provide a comparable standard of protection.
• United States. US state privacy statutes (CCPA/CPRA, VCDPA, CPA, CTDPA, UCPA, and others as enacted) may apply to US residents. We honour applicable opt-out and access rights via the §9 channels. We do not sell or share personal information for cross-context behavioural advertising.
• Other jurisdictions. We honour rights granted by your local law to the extent they apply to us, and we route requests via §9.

Sub-processor list and current transfer-mechanism table at /legal/dpa.

The Service performs automated computations over Customer Data and produces AI-augmented narratives. None of these computations produce a decision that has legal or similarly significant effects on a data subject without human intervention; a licensed advisor or principal must review the output before any decision is taken in reliance on it.

Automated computations performed.

• Returns and performance attribution — time-weighted return, money-weighted return, contribution by holding / asset-class / region / factor.
• Risk metrics — volatility, drawdown, Value-at-Risk, Expected Shortfall, factor exposures, regime classification, scenario stress outputs.
• Concentration and liquidity — single-name, single-issuer, single-sector exposures; liquidity-tier classification.
• Sharia compliance scoring — per-instrument screen on AAOIFI-style ratios and business-activity criteria, producing a compliance status and (where applicable) a purification amount.
• Faraid succession shares — computation of statutory inheritance shares from a family-tree input under Sunni Faraid rules; the result is a calculation, not a legal opinion.
• Zakat calculation — assessable base, due amount, and per-recipient suggested allocation under the configured madhhab.
• Proposal generation (Tier 3+) — rebalance proposals derived from target allocations and current holdings.
• Drift and threshold alerts — alerts triggered when defined bands are breached.
• AI-augmented narratives — the AI surfaces in §4. These are summaries, not decisions, and are clearly labelled as AI-generated.

Human review. Each surface either (a) requires explicit user action to apply any change (rebalance, allocation update, distribution), (b) is read-only narrative for a human to consider, or (c) is a calculation surfaced for a human professional to interpret. The Service does not autonomously execute trades, distributions, or contractual decisions.

Right to human review. If you believe an automated computation has affected you and you want a human to review it, contact privacy@operafo.ae. We will route the request to a qualified reviewer and respond within the §9 timelines. To the extent any future feature does involve solely automated decision-making with significant effects, we will seek explicit consent and provide a meaningful human-review path.

We may update this Privacy Policy from time to time. The current version is dated at the top of this page, and prior versions are available from privacy@operafo.ae on request.

Material changes — those that adversely affect your rights, expand the categories of data we collect, add a new processing purpose, change the lawful basis, or add a new sub-processor — are notified by email to tenant owners at least thirty (30) days before they take effect, and surfaced as an in-app banner for at least the same period. Where applicable law requires a longer notice period or an opt-in, we follow that requirement.

Less material changes — clarifications, formatting, typographical fixes, sub-processor sub- changes within an existing role — are published here and reflected in the “Last updated” date.

Continuing to use the Service after a change has taken effect is acceptance of the updated Policy. If you do not agree to a material change, you may terminate as described in the Terms of Service and request export and deletion under §9.