Snipefinity Privacy Policy

Effective date: 6 June 2026 Last updated: 8 July 2026 Applies to: the Snipefinity private paper-beta — the Snipefinity web application and the Snipefinity marketing website at snipefinity.com (including its waitlist and contact forms). Operator / controller: Snipefinity is an independent project operated by Ahmad Alibrahim, based in Kuwait (currently unincorporated). The Operator is the data controller for the personal data described here. Beta notice: Snipefinity is in private, invitation-only beta and runs in a simulated (paper-trading) environment.

Table of contents

1. Who we are
2. What Snipefinity does — and what we are not
3. Personal data we collect
4. Data we do not collect
5. AI-assisted features — how your inputs are handled
6. Sub-processors
7. Cookies and similar technologies
8. Data flows and cross-border transfers
9. Sharia classification — what data we use and what we publish
10. Retention periods
11. Your rights
12. Lawful bases for processing
13. Children's data
14. Security
15. Disclaimer-acceptance audit log
16. Changes to this Policy
17. Jurisdiction-specific addenda
18. Forward-looking commitments
19. Contacting us about privacy

1. Who we are

Snipefinity is currently operated as an unincorporated project by Ahmad Alibrahim personally, based in Kuwait (referred to in this Policy as "Snipefinity", "we", "us", and "our"). Ahmad Alibrahim is the data controller for personal data processed through the Snipefinity paper-beta application.

This is a deliberate pre-incorporation state. Snipefinity is a paper-only, friends-only private beta with no real money flow, no payments collected, and no live broker funds. Formal incorporation will be undertaken in connection with future funding or live-trading enablement; at that point, the controlling entity will change and this Policy will be amended accordingly (see §16).

Once Snipefinity is incorporated, this Policy will be amended to identify the controlling entity, its registered office, and a designated DPO contact. Until then, this Policy is offered on a good-faith basis: it describes the actual processing performed by the Snipefinity paper-beta application as of the Last updated date.

2. What Snipefinity does — and what we are not

2.1 What we are

Snipefinity is a Sharia-compliant trading platform for authoring, backtesting, and (post-graduation) live-routing user-authored trading strategies. We are positioned as a pure technology platform. Specifically:

• We are not a custodian. We never hold user funds in any form. Funds always live at your chosen broker.
• We are not an asset manager. We never trade on your behalf. You author your own strategies, or select from templates.
• We are not a financial or investment adviser. Nothing we surface — strategy templates, backtest results, paper-trading outputs, AI-assisted suggestions, or Sharia classification verdicts — is personalised investment advice.
• We are not a broker-dealer or introducing broker. We route signals; your broker executes.
• We are not a money transmitter. No user funds flow through Snipefinity in any product surface.
• We are not a religious authority. Our Sharia classification is informational and algorithmic, not a religious ruling (see §9).

2.2 What the paper-beta application does

The paper-beta surface covers three core product flows:

1. Strategy authoring and backtesting. A block-editor and DSL let you compose trading strategies on Snipefinity's Sharia-compliant universe. A backtest engine runs your strategies against historical market data and returns performance metrics (returns, drawdown, Sharpe ratio, win rate). The DSL rejects references to assets identified as non-compliant.
2. Paper trading. Strategies run forward against live market data with simulated fills. No real money is at risk. The output is a paper-trading track record.
3. Live signal routing (post-graduation). When a strategy graduates through Snipefinity's soft-gate process, it emits signals that flow Snipefinity → SnipeRoute → your broker → execution venue. Snipefinity passes intent; SnipeRoute is the broker-abstraction layer; your broker executes against your funds.

2.3 Platform commitment — Sharia-only

Snipefinity is a Sharia-compliant trading platform at the platform level. Assets identified as non-compliant by our Sharia screening engine are not supported for trading on Snipefinity. There is no user-level Sharia toggle — the constraint is uniform across all users globally. See §9 for our methodology, the avoid-list categories, and the current state of enforcement across product layers.

3. Personal data we collect

We collect only the data we need to deliver the service you have asked us to provide. Personal data is grouped here by purpose and source, with retention details in §10 and lawful bases in §12.

3.1 Identity and authentication (via Clerk)

When you create an account, our identity sub-processor Clerk collects and processes:

Clerk maintains the session JWT and the related session metadata. We rely on Clerk's authentication infrastructure; we do not store your password and we do not implement our own credential store inside Snipefinity.

3.1.1 Pre-live-trading verification gate (light-KYC scope)

Before live trading is enabled for your account, we operate a narrower operator-side verification gate for abuse-control and identity-confirmation purposes (see the Terms of Service). The current scope of the light-KYC step is operator-side and narrower than your broker's KYC programme; the present working scope is email confirmation, phone confirmation, and a minimal-identity attestation (specific field list to be finalised by engineering at the live-trading enablement window).

We do not perform full broker-KYC — that is the broker's role (see §4 "Data we do not collect" — government ID, national ID, date of birth, residential address, source-of-funds, biometric). The Snipefinity-side verification step is principally about identity-confirmation continuity (the email + phone we already collect for MFA, plus the minimal-identity attestation), not about regulated AML/KYC.

The private beta is free, and Snipefinity does not collect any payment instrument during the beta.

3.2 Broker connectivity (via SnipeRoute)

When you connect a broker, our broker-abstraction sub-processor SnipeRoute stores the connection record:

Broker credentials live exclusively at SnipeRoute. They are encrypted at rest with envelope encryption (AES-256-GCM). Plaintext tokens exist only in memory for the duration of a broker call. Snipefinity's other services never see them.

We never collect anything we don't need from the broker — in particular, we do not pull balances or trade history except where it is necessary to compute position sizing.

3.3 User-authored content

When you use Snipefinity, you create and we store:

3.4 AI-assisted-feature inputs and outputs

When you use AI-assisted features (for example, the strategy generator), we store your raw inputs and the AI's outputs. The full handling is described in §5.

3.5 Operational telemetry

We collect operational telemetry to keep the platform reliable and secure:

3.6 Disclaimer-acceptance log

When you accept a jurisdiction-specific disclaimer or risk disclosure, we log the acceptance (timestamp, content version, content-hash, jurisdiction, IP-hash, user-agent). The substrate for this log is our audit-log infrastructure; engineering implementation detail is described in §15.

3.7 Market and reference data (not personal data)

For completeness: Snipefinity ingests market data (open/high/low/close/volume) and reference data from third-party market-data and reference-data providers. None of this data is attributable to you as an individual. We mention it here because it transits the same infrastructure that handles your personal data.

We also ingest per-asset Sharia classification verdicts and per-company-per-year purification ratios from a third-party Sharia data reference-data supplier (specific provider not named pre-contract). This supplier does not process personal data on our behalf — no user identifiers transit to the supplier; we only consume per-asset reference data. The supplier is therefore not a sub-processor for GDPR Article 28 purposes and is not listed in §6. The supplier is disclosed in §9 for operational transparency.

3.8 Waitlist and contact-form data (marketing website)

Our marketing website at snipefinity.com is a separate surface from the application, but it is operated by the same controller and collects a small amount of personal data through two forms:

This data is held in the marketing site's lead store on Cloudflare (Cloudflare D1) — see §6 and §8 for Cloudflare's role and location. We do not use waitlist or contact data for advertising, we do not sell it, and we delete it on request or when the waitlist is wound down. If you go on to create an application account, the identity data we then hold is governed by §3.1.

4. Data we do not collect

We have made deliberate product decisions to avoid collecting data we don't need:

• No funds. Your broker holds your funds; there is no Snipefinity wallet, no withdrawal path, and no money transmission.
• No payment or card data. The private beta is free and Snipefinity collects no payment instrument. If paid plans are introduced later, card data would be held by a third-party billing processor, not by Snipefinity; card numbers and CVV would never transit Snipefinity infrastructure.
• No KYC documents (government ID, passport, national ID, SSN, etc.). KYC is the broker's responsibility — we route signals to a broker account you already own.
• No date of birth or postal address.
• No source-of-funds information.
• No biometric data.
• No precise geolocation. We collect country-of-residence (self-declared) and your IP address (for session security) only.
• No tracking pixels or third-party advertising cookies.
• No religious-belief inference. Although Snipefinity is a Sharia-compliant platform, we do not treat your use of the Service as a declaration of religious belief and we do not store any "user is Muslim" or related profile attribute (see §9.8).
• No sale of personal data, ever. We do not sell, rent, or share your personal data with third parties for their own marketing or advertising. Disclosures to sub-processors are limited to what is necessary to deliver the service (see §6).

4.1 No surveillance-derived pricing

The private beta is free and Snipefinity collects no payment instrument (see §3). Independently of that, we do not set prices, or compute any price-discrimination signal, from your behavioural data, your engagement patterns, your broker activity, your AI-feature usage, or any other personal data we hold. A model that does not derive billable events from your activity is also one that does not require us to retain that activity beyond product-operations and audit purposes (see §10).

5. AI-assisted features — how your inputs are handled

When you use an AI-assisted feature (for example, the strategy generator), your input text is sent for inference and we store your input and the AI's output as described below.

When you use AI-assisted features, your input text is normally sent to one of our third-party AI-inference sub-processors for inference; on some requests a self-hosted fallback model operated by Snipefinity may handle the inference instead. The AI-inference sub-processors we currently use, their locations, and their data-use terms are listed in §6. Where a third-party sub-processor processes your input, it does so under its own commercial terms (which may change); we select AI-inference sub-processors that, under their then-current commercial terms, do not by default use API inputs to train their models and apply only a short trust-and-safety retention window for abuse prevention.

Snipefinity retains your raw AI-feature inputs and outputs for up to 12 months to develop and improve our platform, with a scheduled deletion job enforcing this retention limit. During Snipefinity's beta program, this processing forms part of your beta participation. After the beta program ends, processing continues on the legal basis of our legitimate interest in improving the platform. You may opt out at any time via account settings, and you may request deletion of your retained inputs and outputs through our data-subject-rights mechanism.

5.1 What this means in practice

• On most AI calls, the raw text you type into an AI-assisted feature is sent to a third-party AI-inference sub-processor (the current provider(s) are named in the §6 table); on some requests a self-hosted fallback model operated by Snipefinity handles it instead. Either way, we cannot deliver the feature without processing your input.
• Our AI-inference sub-processors' default commercial terms do not authorise training on API inputs and provide only a short trust-and-safety retention window. Each provider's then-current data-retention policy governs the upstream window; per-provider specifics are in the §6 table.
• Snipefinity stores the input, the output, and the metadata listed in §3.4 for up to 12 months. A scheduled deletion job enforces this cap.
• Lawful basis for the Snipefinity-side storage (phased):
  • During the paper-beta programme: your participation in the beta includes the data-use that is necessary for us to evaluate and improve the platform.
  • After the paper-beta programme ends: legitimate interest in improving the platform, balanced against the limited individual impact given the 12-month cap, the opt-out, and the right to deletion.
• You can opt out at any time in account settings. Opt-out does not affect inference itself (your input must still be processed for inference to occur, whether by a third-party AI-inference sub-processor or by the self-hosted fallback) — opt-out controls Snipefinity-side storage of the raw input and output.
• You can request deletion of any retained inputs and outputs through the data-subject-rights mechanism in §11.

5.2 Access controls

Access to raw retained AI inputs is limited to a small, named set of Snipefinity operators and on-call engineers who need it to investigate incidents or improve the platform. Access is logged.

5.3 Forward-looking

We continuously evaluate stricter data-retention configurations with our AI-inference sub-processors. When activated, the sub-processor list in §6 and this section will be updated.

We may use more than one AI-inference sub-processor at a time, and may add, change, or remove them as our product evolves. The current set is always listed in §6. When we add one, we update §6 and give notice; where a change materially affects how your input is processed, we give advance notice and an opportunity to object before your input is processed by the new sub-processor.

5.4 Your own AI agent (bring-your-own-agent)

When you access Snipefinity through your own AI agent or a third-party assistant (via our programmatic / agent surface, when available), the LLM or model provider you choose to run that agent is your sub-processor, not Snipefinity's. Snipefinity does not control, and is not responsible for, how your chosen agent or its model provider processes the prompts and data you route through it. Data you send to Snipefinity is processed by us as described in this Policy; data your agent sends to its own model provider is governed by your relationship with that provider.

6. Sub-processors

A sub-processor is a third-party service that processes personal data on our behalf to help us deliver Snipefinity. We use sub-processors for hosting, authentication, broker connectivity, error tracking, AI inference, and reference data.

Two parties that touch our infrastructure are not sub-processors for the purposes of this Policy and are deliberately not listed here:

• Third-party Sharia data reference-data supplier — supplies per-asset classification verdicts and per-company-per-year purification ratios. The supplier does not process any personal data on our behalf — no user identifiers transit to the supplier; we only consume per-asset reference data. The supplier is disclosed in §9 for operational transparency.
• our purification service — an internal Snipefinity service that computes Flow A reclassification-purification and Flow B ongoing dividend-purification entirely inside Snipefinity infrastructure. It is not a third party and not a sub-processor. It is disclosed in §9 for operational transparency.

6.1 Active sub-processors (in production today)

Our canonical data store is self-hosted infrastructure operated by the Operator and located in Kuwait — it is not a third-party sub-processor; see §8.1. We re-verify DPF certification status on dataprivacyframework.gov/list at each Policy revision.

6.2 The Sentry browser SDK — explicit disclosure

The Sentry browser SDK loads on every page of the Snipefinity web application and sends error events directly from your browser to Sentry's servers in the United States. We have configured the SDK so that:

• it does not capture identifying personal data by default;
• session replays are disabled;
• performance tracing is disabled;
• a server- and client-side secret-redaction filter strips API keys, tokens, and other sensitive material before transmission.

The Sentry browser SDK does not set first-party cookies. It transmits via XHR / sendBeacon. Because the SDK communicates with a third-party endpoint from your browser, we disclose it explicitly here and in our Cookie Policy.

6.3 SnipeRoute — narrower-scope identity disclosure

Our disclosure of SnipeRoute's data handling is as follows:

SnipeRoute (Snipefinity's broker-abstraction sister service) receives broker-connection metadata, signal payloads, and a limited identity record (your email address from Clerk plus session metadata required to manage your broker connections). SnipeRoute does not store user-set passwords; authentication is delegated to Clerk.

And the forward-clause covering SnipeRoute's identity evolution:

SnipeRoute's entity jurisdiction has not yet been finalised; the location row in §6.1 reflects that. The sub-processor list will be updated when SnipeRoute's entity is incorporated.

6.4 Planned future sub-processors

We list planned future sub-processors so that you have advance notice of services that may become active during the paper-beta or shortly thereafter. We will update this list and notify users before any planned sub-processor begins processing.

6.4.1 Provider-switching language

We continuously evaluate market-data providers and may activate or transition to alternative providers (such as alternative market-data providers) to improve data quality, coverage, or cost-effectiveness. When activated, the sub-processor list will be updated and the change will be reflected in our next policy revision.

6.4.2 LLM expansion language

We use one or more third-party AI-inference sub-processors for content generation, classification, and analytical tasks; the current provider(s) are named in the §6.1 table above. We may use more than one at a time and may add, change, or remove them as our product evolves; we will update the §6.1 table and notify users accordingly.

6.5 What we do not do with your data

Independent of the specific vendors in our stack at any given time:

• We do not sell your personal data, and we do not share it for cross-context behavioural advertising.
• We do not run third-party advertising trackers, advertising pixels, or cross-site tracking technologies.
• We do not profile you to set prices or to make automated decisions that produce legal or similarly significant effects about you.
• We do not collect payment-card data during the beta (the beta is free; see §3).

Whenever we add a third party that processes your personal data, we update the sub-processor list in §6.1 before, or at the time, processing with that party begins.

7. Cookies and similar technologies

The full inventory of cookies and similar technologies used by the Snipefinity web application is in our Cookie Policy. The short summary:

• We use strictly-necessary cookies only today: Clerk's session cookie (which also serves the CSRF anti-replay role) and Next.js routing internals. No consent banner is required for these under GDPR / ePrivacy / Saudi PDPL.
• The Sentry browser SDK runs on every page and transmits redacted error events from your browser to Sentry's servers in the United States via XHR / sendBeacon. The SDK does not set first-party cookies. We disclose this transmission explicitly (see §6.2).
• We do not today use third-party advertising cookies, cross-context behavioural advertising, social-network pixels, or session-replay technology.
• If we activate session-replay or heatmap tooling in the future (see §6.4), we will deploy a cookie-consent banner and PII-masking configuration before the tool collects any data.
• We have a planned activation of behavioural analytics tooling (specific tool TBD) for first-party, anonymised product analytics — restricted to users located in GCC jurisdictions (Saudi Arabia, UAE, Qatar, Kuwait, Bahrain, Oman) via IP-based geolocation at session initialisation. In that configuration (first-party, IP-anonymisation, no cross-site tracking, no fingerprinting, aggregate-only, GCC-only audience), the tooling runs under our Saudi PDPL-aligned strictly-necessary-equivalent treatment without a consent banner. The tool will not initialise for users identified as located in the EU, UK, or other jurisdictions where first-party anonymised analytics are treated as consent-required. EU/UK activation awaits a consent-UI build; we will disclose the chosen path here before EU/UK expansion (geo-gating off / consent banner / strictest national audience-measurement standard).

See the separate Cookie Policy for the full list of cookies and similar technologies and their purposes.

8. Data flows and cross-border transfers

8.1 Where your data lives

Your canonical Snipefinity record — your account profile, your strategies, your backtests, your paper-trading history, and (post-graduation) your live trade intents and executions — is stored on self-hosted infrastructure operated by the Operator and located in Kuwait. This is the primary data-residency location through the paper-beta. Cloudflare provides the edge network and secure tunnel that front the application (see §6.1), and certain processing is performed by our US-based sub-processors (Clerk, Sentry, Anthropic — see §6.1). If we later migrate the canonical store to a managed cloud provider, we will disclose the provider and its location here before the migration.

Because Snipefinity is a GCC-first private beta, keeping the canonical store in Kuwait means your core data remains within the GCC region, close to the user base, rather than being exported to a third country. Subsets of your data are still processed by the US-based sub-processors named in §6.1; those transfers are addressed in §8.3.

8.2 Data flow summary

You → Cloudflare edge / tunnel → the Snipefinity web application (Clerk auth) → Snipefinity services (self-hosted, Kuwait)
                                ├──→ Sentry (errors, redacted)
                                ├──→ Grafana Cloud (logs, metrics — planned)
                                ├──→ third-party market-data and reference-data providers (market + reference data IN)
                                ├──→ Sharia data reference-data supplier (per-asset reference data IN — no user data OUT)
                                ├──→ Anthropic (AI inference OUT, on demand)
                                └──→ SnipeRoute → Broker (signal OUT, on your action)
                                                    └─→ Execution venue
                                                                ↓
                                          Broker holds funds and executes the trade

8.3 Cross-border transfer mechanisms

Where personal data leaves the user's region of residence to reach a sub-processor (see §6), we rely on the following mechanisms.

8.3.1 GDPR / UK GDPR transfers (EU/EEA and UK residents — post-expansion)

• EU-US Data Privacy Framework (DPF) where the recipient is self-certified. US sub-processor transfers rely on the EU-US DPF where the recipient is self-certified, or on SCCs as a fallback. We verify each recipient's current certification status against dataprivacyframework.gov/list at each policy revision rather than asserting a fixed list here.
• Adequacy of the canonical store. Our canonical store is in Kuwait, which is not currently the subject of an EU/UK adequacy decision. Because the paper-beta does not target EU/UK residents (see §17.2 and §17.4), this is forward-looking: before any EU/UK availability we will put SCCs or another valid Article 46 safeguard in place for the transfer to Kuwait (or rely on an explicit-consent derogation for the private beta), supported by a transfer risk assessment.
• Standard Contractual Clauses (SCCs) (Commission Decision (EU) 2021/914) for any US transfer where the recipient is not DPF-certified, and as a fallback in case the DPF is invalidated or a recipient's certification lapses.

We are not within the territorial scope of GDPR today because the paper-beta does not target EU residents (see §17.2). We list these mechanisms here so that the Policy is operationally ready for our planned EU expansion.

8.3.2 Saudi PDPL transfers (Saudi residents)

• Permitted purpose under PDPL Article 29(1)(3): performance of obligations under the contract you have with us (the Terms of Service).
• Permitted purpose under the Transfer Regulations (Article 2): providing services to data subjects.
• Saudi-form Standard Contractual Clauses with sub-processors as appropriate safeguards in the absence of a published SDAIA adequacy list.
• Written risk assessment in accordance with the SDAIA Risk Assessment Guideline for Transferring Personal Data Outside the Kingdom (February 2025).

We transfer your personal data outside the Kingdom of Saudi Arabia under Article 29(1) of the PDPL and the Regulation on Personal Data Transfer Outside the Geographical Boundaries of the Kingdom. Transfers are made under SDAIA-approved Standard Contractual Clauses with our sub-processors, supported by a written risk assessment. We will update this Policy as SDAIA publishes its adequacy list.

8.3.3 UAE — Federal PDPL, DIFC DPL, ADGM DPR

• Federal PDPL: contract necessity (delivering the service you have requested), with separable explicit consent obtained where required before the relevant gated event, in the absence of a published Executive Regulation adequacy list.
• DIFC and ADGM (if our entity is in one of those free zones): transfers to the Kuwait-hosted store and to our US sub-processors flow under SCCs or another appropriate safeguard; we will complete the required transfer assessment before any DIFC/ADGM-entity onboarding.

8.3.4 Smaller GCC (Kuwait, Bahrain, Qatar, Oman)

• Kuwait: cross-border transfers permitted on disclosure to the data subject (provided in this Policy).
• Bahrain: Germany, US, UK, UAE, KSA all appear on the PDPA whitelist — no per-transfer paperwork required for those destinations.
• Qatar: cross-border transfers permitted unless processing violates the PDPPL.
• Oman: controller self-assessment of adequacy — the canonical store is in-region (Kuwait), and US sub-processor transfers rely on DPF/SCCs as adequate safeguards.

8.3.5 US (California and state patchwork — post-expansion)

US privacy laws (CCPA/CPRA and the state patchwork) do not impose cross-border transfer restrictions on data leaving the US. They impose disclosure and rights obligations regardless of where data is stored. See §17.6 for the CCPA/CPRA addendum.

8.4 Why in-region (Kuwait) residency benefits you

Keeping your canonical record in Kuwait — within the GCC region, not in the US — means:

1. Your core data stays close to our GCC-first user base.
2. A simpler cross-border story for GCC users: under most GCC frameworks, data that remains within the region (or moves between GCC states) is the most straightforward case.
3. Less exposure to US extraterritorial legal process for the canonical store. (We acknowledge that the US sub-processors handling subsets of your data — Clerk, Sentry, Anthropic — and Cloudflare's US-operated edge network remain subject to US law.)

9. Sharia classification — what data we use and what we publish

9.1 Engine description and avoid-list

Snipefinity maintains a proprietary Sharia screening engine combining sector classification, AAOIFI-style financial ratios, and LLM-assisted activity analysis.

The engine evaluates each asset against:

• Sector classification — security-type and business-sector exclusions.
• AAOIFI-style financial ratios — debt, cash, receivables, and impermissible-income screens, applied where the underlying financial data is available.
• LLM-assisted activity analysis — description and filing-text analysis.
• A high-risk-industries overlay — auto-routes certain higher-risk sectors to UNCERTAIN (treated as blocking) pending further classification.
• A conservative default: when classification is uncertain, the asset is treated as non-compliant. The same conservative default applies to newly-onboarded assets — until our screening has run, the asset is flagged a conservative-default and treated as blocking for new BUY intents.

Verdicts are versioned, audited, and revisable only by tighten-only operator overrides (an override may move a verdict toward stricter — never looser).

Categorical avoid-list — what we screen out. These categories are derived from our internal screening engine. They are not vendor-attributed (no third-party Sharia data supplier is named as the category source pre-contract).

• Equity avoid-list: conventional financials (banks, conventional insurers); brewers, distillers, and vintners; casinos and gambling operators; adult-entertainment; arms and weapons; pork-derivative products; tobacco; gambling-related products and derivatives.

This avoid-list may be revised as Sharia screening methodology evolves; material changes will be disclosed with the next Policy update.

9.2 Data combination — internal engine plus planned third-party sources

Our screening engine is internal today; we may combine it with industry-recognised Sharia data providers once such a provider is contracted (none is engaged as of the date of these Terms). Any provider would be disclosed in our reference-data-supplier list (§9) upon contractual finalisation.

The third-party Sharia data provider acts as a reference-data supplier, not a sub-processor under GDPR Article 28: no user identifiers transit to the supplier, and the supplier does not process personal data on our behalf. The supplier supplies (a) per-asset classification verdicts that refine our engine's categorical screen, and (b) per-company-per-year purification ratios used by our internal purification service (see §9.9).

9.3 Religious-authority disclaimer

Snipefinity is a technology platform; our Sharia classification is informational and algorithmic, not a religious ruling. Users seeking religious certainty should consult their own qualified Islamic scholar.

9.4 Coverage — what is operational today

Equity Sharia screening is in operational production.

Concrete state, as of the Last updated date:

• Equity: the majority of our screened equity universe carries a definitive compliant/non-compliant verdict; a minority sit in an uncertain state pending further classification, and a smaller share are queued for financial-data backfill (largely OTC names and assets missing the data needed for the AAOIFI ratios).
• Universe-layer Sharia gate: our mandatory universe-layer Sharia gate and the conservative-default flag for newly-onboarded assets are LIVE today. Every external query returns only COMPLIANT assets in non-research environments; new assets are blocked from trading until the screening engine has classified them; strategy-save validation rejects non-compliant references.
• Point-in-time classification history: reclassification handling references each asset's Sharia classification as of the relevant historical date (§9.6).

9.5 Dispute path

You may flag a verdict you disagree with by contacting support; we will review and may revise. We commit to acknowledging dispute submissions within 5 business days and to substantively resolving them within 30 business days of receipt. Final religious certainty is between you and your own qualified Islamic scholar. A self-service dispute mechanism in account settings is in development (see §18).

9.6 Reclassification handling — safe-harbour pattern

When an asset is reclassified from compliant to non-compliant, Snipefinity applies a safe-harbour pattern designed to respect both Sharia principles and your decision-making time:

• Strategies referencing the reclassified asset continue to run normally. We do not freeze a strategy because one of the assets it references has been reclassified. Strategies may continue to emit SELL signals against existing positions in the reclassified asset; SELL intents pass through.

• New BUY intents on the reclassified asset are hard-blocked at the order-routing layer. Once defence-in-depth at SnipeRoute is in place (target gate: live-trading enablement), the block is applied irrespective of the upstream caller.

• Existing positions: you choose the exit. We surface a per-holding banner — "this strategy holds [TICKER] — now non-compliant since [DATE]. Force-exit now, or let the strategy decide." A one-click force-sell control is provided.

• User preference on_sharia_flip. You may configure how your strategies respond to a compliance flip on assets they hold. Three options:

  • hold (default) — we notify you; your strategy continues to run; you exit manually via the in-product UI when you choose.
  • auto_exit (opt-in) — we notify you; the system schedules a force-exit at the next bar or session open after a flip is detected.
  • prompt (a future planned option; not yet available) — we notify you and require a confirm-or-dismiss action within a fixed window; if you do not respond, we fall back to hold.

  The notification always happens regardless of your preference. The preference changes the action we take (automatic or manual), not whether you are notified. Your data-rights over the notification and the audit record are unchanged by the preference.

• Backtest parity. Our backtest engine accepts your on_sharia_flip setting through its simulation configuration so that historical backtest results reflect how your preference would have acted at each reclassification event in the backtest window. This is a data-processing detail: backtest runs that consume your preference do so under the same retention regime as other backtest data (see §10).

• We never auto-liquidate without your opt-in. Under hold (default), forced sale removes your agency, creates ledger and broker-execution liability, and raises fiqh concerns. The decision to exit remains yours. Under auto_exit, you have explicitly elected the automated path.

• Grace period. A default grace window of 90 days applies to force-exit prompts under hold. After the grace expires, the UX escalates (more prominent banner; export-and-reminder); we never close the position on your behalf under hold.

• Backtest results referencing the reclassified asset are preserved as historical records with a reclassification-date watermark. Backtests reference an asset's classification at the time of each historical trade (point-in-time).

• Purification. Gains accrued during the haram period — and dividends received during that period — purify per the rules in §9.9 (Flow A).

Before live trading is enabled, reclassified assets will be blocked from new purchases and you will be notified in-product and by email; the full safe-harbour pattern lands before live-trading enablement (see §18). Where the operator engages a fatwa board in the future, the grace window and specific UX may be revisited.

9.7 Methodology school

Our baseline methodology is AAOIFI-style. Users following different methodologies should consult their own scholars to understand any differences.

9.8 What data we collect about you for Sharia classification

For the Sharia classification feature itself, we do not collect or infer your religion. Sharia screening is a platform-wide product constraint — every user is on the compliant universe. There is no toggle. We do not treat your use of Snipefinity as a declaration of religious belief, and we do not store "user is Muslim" or any related profile attribute.

9.9 Purification — Flow A and Flow B

Purification is the calculation and ledgering of amounts that should be set aside or donated to remove impermissible income from a portfolio. Snipefinity provides the calculation, ledger, and user-facing tooling to help you track purification, but we do not enforce donations — the actual donation, whether and to whom, is your religious-obligation responsibility. The ledger is a record-keeping convenience, not a deduction or a transfer.

Flow A — Reclassification purification (event-driven, on exit)

When an asset that you hold is reclassified from compliant to non-compliant and you later exit the position, the purification amount for that exit is calculated as:

purification_capital_gain = max(0, exit_price − price_at_reclassification) × shares
purification_dividends    = sum of dividends received during the haram period × per-company-per-year ratio for the relevant year(s)
purification_total        = purification_capital_gain + purification_dividends

The "haram period" is the time between the reclassification date and your exit date. Gains accrued before the reclassification (i.e., during the compliant period) are not subject to purification. Multi-lot positions use a weighted-average cost basis; foreign-currency dividends and proceeds are converted at the rate prevailing on the donation-date entry.

Flow B — Ongoing dividend purification (continuous, per dividend event)

For compliant stocks that carry a small non-zero share of impermissible income (the AAOIFI-style ratio screen permits compliance with a small fractional purification obligation), each dividend received generates a per-dividend purification entry:

purification_amount = dividend × per-company-per-year purification ratio for the dividend year

Industry-standard practice; the scholarly basis for the small-fraction-purification approach is the long-standing methodology used by AAOIFI-aligned screens.

Data sources and processing location

Both flows consume per-company-per-year purification ratios from the third-party Sharia data reference-data supplier introduced in §9.2. The ratios are reference data; no user identifiers leave Snipefinity to obtain them. All purification calculations run inside our own purification service — an internal Snipefinity service (not a sub-processor; not a third party) — using your position and dividend data already held within Snipefinity infrastructure (see §3.3).

User-facing tooling

We provide:

• A per-holding purification ledger (running entries per Flow A and Flow B);
• A "mark as donated" control (recording your own action; we do not transmit funds);
• Running year-to-date and lifetime ledger views;
• An annual purification statement;
• A bulk-donate-mark action.

Our role, your obligation

Snipefinity calculates and ledgers; you decide whether and to whom to donate. The religious-obligation responsibility remains with you. Snipefinity does not act as a charity, a transmitter of charitable funds, or a religious authority. Some edge cases — multi-currency portfolios, corporate actions (splits, mergers, spin-offs), re-reclassification (haram → halal → haram), and the choice of donation recipient — are noted in §18 as items for future operator and fatwa-board sign-off; the published Policy will be amended (v1.1) when those edges resolve.

10. Retention periods

When you close your account, we delete or anonymise data we do not need to retain for legal, regulatory, audit, or fraud-prevention purposes. The append-only audit categories (trade intents, executions, audit events, audit logs) are retained for compliance and reconciliation reasons and cannot be deleted on request to the extent that retention is required by applicable law.

11. Your rights

You have rights over your personal data. The specific rights and timelines depend on the law that applies to you (see §17 for jurisdiction-specific addenda). The summary below covers the most expansive set we apply across our user base.

How to exercise your rights

The fastest route is account settings → Privacy → Data and Rights. You can also email privacy@snipefinity.com from the email address on your account.

We aim to respond as quickly as possible. Our service-wide ceiling is 10 working days to meet the strictest GCC response window (Bahrain); we may extend by an additional 30 days for unusually large or complex requests, with notice to you. Specific statutory windows for your jurisdiction are listed in §17. The full cross-service self-service erasure endpoint is targeted for live-trading enablement; in the interim, requests are processed via the email and in-product routes above.

We verify your identity through your authenticated Clerk session for in-product requests; out-of-band requests require email confirmation from the account email on file. We do not require new credentials; we will not deny service to you for exercising a right.

12. Lawful bases for processing

We rely on the following lawful bases (GDPR Article 6 framing; the same bases map to UK GDPR and to the GCC frameworks with adjustments). Where additional bases apply under a specific jurisdiction (e.g., Saudi PDPL Article 5 / Article 6 categories), the jurisdiction addendum in §17 lists them.

We do not currently rely on Article 9 (special categories) lawful bases because we do not intentionally collect special-category data. If you voluntarily paste special-category data into a free-text input (for example, the AI feature), our handling defaults to deletion on request and the 12-month TTL described in §5.

13. Children's data

Snipefinity is not intended for and is not directed to individuals under 18 years of age. Account creation requires you to be of legal age to open and operate a brokerage account in your jurisdiction (typically 18+; in some jurisdictions, including for some UAE broker products, 21+).

We do not knowingly collect personal data from children. If you believe a child has provided personal data to us, please contact privacy@snipefinity.com and we will delete the data and close the account.

14. Security

We take security seriously and apply controls in proportion to the sensitivity of the data we hold.

• Broker credentials at SnipeRoute are encrypted at rest using AES-256-GCM envelope encryption. Plaintext tokens exist only in memory during a broker call. Snipefinity's other services never see plaintext credentials.
• Secret-redaction filter: a server-side and client-side redaction layer scrubs API keys, tokens, headers, and known secret-shaped substrings from outbound observability events before they leave our infrastructure. The redaction layer covers Sentry events, Grafana logs, and breadcrumb metadata.
• Security-relevant audit records are stored append-only and cannot be silently altered by application code. A consolidated audit-log system lands at paper-beta launch with configurable retention tiers (see §10).
• Authentication is delegated to Clerk; we do not store user-set passwords for Snipefinity-routed sessions. MFA (TOTP and SMS, depending on Clerk configuration) is supported.
• Transport is TLS for all inbound and outbound traffic.
• Access controls: production access is limited to a named set of operators and on-call engineers; access is logged.

No security control is absolute. We will notify you (and the relevant supervisory authority where required) of any breach affecting your personal data within the timelines required by the law applicable to you. The applicable timelines are set out in §17; the tightest deadline binding our service-wide incident-response procedure is Kuwait CITRA's 24-hour ceiling, so we target that ceiling for regulator notification and will notify as soon as reasonably practicable, with the EU/UK/Saudi/UAE 72-hour ceiling as the secondary check.

We maintain an internal security baseline and review it periodically.

15. Disclaimer-acceptance audit log

We log, for each user, every jurisdiction-specific disclaimer and risk disclosure shown to that user — capturing the timestamp, the content version, a hash of the content shown, the user's jurisdiction at the time, a hashed IP, and the user-agent.

The substrate is the audit-log infrastructure, landing at paper-beta launch with configurable retention tiers (default: indefinite for disclaimer-acceptance entries — see §10). Cadence, retention-tier configuration, and operator-access controls are maintained under our internal security and data-governance procedures. Where this Policy is updated and triggers re-acceptance of any disclaimer, the prior acceptance record remains in the log as evidence of acceptance under the prior content version.

16. Changes to this Policy

We may revise this Policy from time to time. When we do, we will update the Last updated date at the top of this document and (for material changes) notify you in-product (via banner) and by email.

Material changes that trigger advance notice include:

• Adding a sub-processor that processes user personal data (advance notice via email; sub-processor list updated at activation).
• Changing the lawful basis for any processing activity.
• Narrowing or expanding your rights.
• Changing the scope of AI-feature data handling.
• Changing the basic structure of the Sharia classification methodology in a way affecting end-users.
• Incorporation of the controller (i.e., Snipefinity moving from its current unincorporated state to a named legal entity).

PP v1.1 amendment process. If an engineering milestone tied to a forward-looking commitment (see §18) slips, we will publish an interim v1.1 amendment narrowing the commitment to match the actual state of the platform before the corresponding gated event (e.g., live-trading enablement). This is a formal commitment in our internal process: forward-clauses are not silently abandoned.

Canonical amendment process. The full amendment process — routine vs. material vs. Sharia-milestone-driven — is described in the Terms of Service (§17). This §16 of the Privacy Policy is the privacy-specific application of that single canonical process; the Acceptable Use Policy and Cookie Policy reference the same process.

17. Jurisdiction-specific addenda

This Policy is read in conjunction with the addendum that corresponds to your jurisdiction. If multiple addenda apply (for example, you are a Bahraini user with EU residency), each applies in respect of the rights it grants.

17.1 Saudi Arabia (PDPL)

The Saudi Personal Data Protection Law (Royal Decree M/19, in force 14 September 2023; fully enforceable since 14 September 2024) applies to processing of personal data of Saudi residents wherever we sit. We are subject to PDPL even though our controller is currently based in Kuwait and unincorporated.

Your PDPL rights (Article 4 + Implementing Regulations):

• right to be informed;
• right of access;
• right to rectification;
• right to deletion ("right to be forgotten");
• right to restrict processing;
• right to withdraw consent (at any time, without affecting prior lawful processing);
• right to object to direct marketing;
• right to complain to SDAIA;
• right to compensation for material or moral damage.

Response window. 30 days from receipt of your request (extendable once by another 30 days with prior justified notice).

Breach notification. We will notify SDAIA without undue delay and, in any event, within 72 hours of becoming aware of a personal data breach where notification is required under the PDPL Implementing Regulations, and will notify affected data subjects where the breach is likely to result in serious damage.

Cross-border transfers. See §8.3.2.

Sensitive personal data. The PDPL Implementing Regulations include "location data" and "credit data" within the sensitive-data category. We disclose that we collect your IP address (for session security), country of residence (for jurisdiction tailoring), and that we transmit IP addresses to sub-processors in the US (Clerk, Sentry, Anthropic) and to Cloudflare's edge network, while the canonical store is in Kuwait. We do not collect credit-bureau-grade data. We treat broker access tokens and broker account identifiers as financial-account material and apply heightened controls (AES-256-GCM envelope encryption; access logging — see §14). We rely on contract necessity for these processing activities and, where a jurisdiction requires separable explicit consent, will obtain it before the relevant gated event; this Policy is the disclosure that any such consent is given against. We acknowledge that a maximalist regulator reading of "location data" could capture IP and country-of-residence as sensitive; this is subject to ongoing review.

Complaints to SDAIA. You may file a complaint with the Saudi Data & AI Authority (SDAIA) via the National Data Governance Platform.

Saudi DPO contact. During the unincorporated phase, Ahmad Alibrahim serves as the privacy lead; a designated DPO will be named when headcount and entity structure allow separation. Saudi-resident DPO residency requirements (if triggered by SDAIA registration threshold confirmation) will be addressed pre-launch to Saudi residents.

17.2 European Economic Area (EU GDPR + ePrivacy + EU AI Act)

The paper-beta is not currently targeted at EU residents and we do not consider ourselves to be within the territorial scope of GDPR Article 3 today. If you are an EU resident who has nonetheless signed up, this Policy describes the rights and protections we will accord you on a good-faith basis; the formal Article 27 EU representative will be designated before EU expansion.

Your GDPR rights (Articles 15–22 + Art. 7(3)):

• right to be informed (Arts. 13–14);
• right of access (Art. 15);
• right to rectification (Art. 16);
• right to erasure (Art. 17);
• right to restrict processing (Art. 18);
• right to data portability (Art. 20);
• right to object (Art. 21);
• right not to be subject to solely automated decision-making producing legal or similarly significant effects (Art. 22);
• right to withdraw consent (Art. 7(3));
• right to lodge a complaint with a supervisory authority (Art. 77).

Response window. Within one month of receipt (extendable by two further months for complex requests, with notice).

Breach notification. We will notify the lead supervisory authority within 72 hours of becoming aware of a personal data breach (GDPR Art. 33), and will notify affected data subjects without undue delay where the breach is likely to result in a high risk to their rights and freedoms (Art. 34).

EU AI Act (Regulation (EU) 2024/1689) — Article 50 transparency. Our AI features are designed so that, where Article 50 applies (from 2 August 2026), you are informed when you interact with an AI feature and AI-generated content is labelled. We will confirm the in-product labelling and metadata implementation before those obligations take effect.

ePrivacy / cookies. See §7 and our Cookie Policy. We acknowledge that the "no banner needed" position for first-party anonymised analytics is contested in some EU member states; the relevant configuration will be finalised before EU launch.

Cross-border transfers. See §8.3.1.

Supervisory authorities. You may lodge a complaint with the data-protection authority in your member state of residence, place of work, or place of alleged infringement.

EU representative (Art. 27 GDPR). Not yet appointed; an Article 27 representative will be designated before any EU expansion.

17.3 United Arab Emirates (Federal PDPL / DIFC DPL / ADGM DPR)

The UAE operates a layered regime: a federal PDPL (Federal Decree-Law No. 45 of 2021) for mainland UAE and most ordinary free zones, plus two independent free-zone regimes — DIFC DPL (Law No. 5 of 2020) and ADGM DPR (2021). The framework that applies depends on where you reside in the UAE and on where our entity is incorporated (we are currently unincorporated — see §1).

Your rights (uniform across federal PDPL, DIFC DPL, and ADGM DPR): information, access, rectification, erasure, restriction, portability, objection, withdrawal of consent, complaint to the regulator.

Response window. Federal PDPL: pending Executive Regulations. DIFC and ADGM: 30 days, GDPR-style.

Breach notification. DIFC and ADGM: 72 hours to the Commissioner / Office of Data Protection (DIFC practice + ADGM DPR explicit). Federal PDPL: timing to be set by the Executive Regulations — we apply a 72-hour planning baseline in the interim and notify affected data subjects where required.

Sharia screening framing. All three frameworks treat data revealing religious belief as sensitive / special category. We frame Sharia screening as a platform-wide product constraint and do not store any "user is Muslim" profile attribute (see §9.8). We treat Sharia screening as a content / market-coverage feature, not as a religious-belief inference.

Cross-border transfers. See §8.3.3. If our entity sits in DIFC or ADGM, transfers to the Kuwait-hosted store and to our US sub-processors flow under SCCs or another appropriate safeguard.

Regulators. UAE Data Office (federal); DIFC Commissioner of Data Protection; ADGM Office of Data Protection.

17.4 United Kingdom (UK GDPR + DPA 2018 + PECR)

The paper-beta is not currently targeted at UK residents. As with the EU addendum, this section is forward-prepared.

Your UK GDPR rights. Same set as the EU GDPR rights in §17.2, as supplemented by the Data Protection Act 2018 (as amended by the Data (Use and Access) Act 2025).

Response window. One month (extendable by two further months for complex requests, with notice).

Breach notification. We will notify the Information Commissioner's Office (ICO) within 72 hours of becoming aware of a personal data breach (UK GDPR Art. 33). We will notify affected data subjects without undue delay where the breach is likely to result in a high risk (Art. 34). We do not currently self-classify as a public electronic communications service provider, so PECR Reg. 5A's 24-hour telco-style ceiling does not apply to us.

PECR. Cookies and similar technologies — see §7. We will revisit the analytics-tooling position before any UK user activation.

Complaints. You may complain to the Information Commissioner's Office (ICO) at ico.org.uk.

17.5 Smaller GCC (Kuwait, Bahrain, Qatar, Oman)

Kuwait — CITRA Data Privacy Protection Regulation (Administrative Decision No. 26/2024). We disclose to Kuwaiti users (a) the categories of personal data we process (see §3); (b) our sub-processors and the countries to which data flows (see §6, §8); (c) your right to withdraw consent.

Kuwait breach notification. Within 24 hours to CITRA of becoming aware of a personal data breach — the tightest deadline in MENA and the binding ceiling on our service-wide incident-response runbook (see §14). Affected data subjects are notified without undue delay unless effective protective measures have been applied.

Bahrain — Law No. 30 of 2018 (PDPL). The Bahrain PDPA whitelist includes Germany, the United States, the United Kingdom, the UAE, and Saudi Arabia. Response window for data-subject requests: 10 working days (our service-wide ceiling). Breach notification: within 72 hours to the PDPA where the breach affects data subjects' rights, with affected-subject notification where high risk. Regulator: PDPA, Ministry of Justice.

Qatar — Law No. 13 of 2016 (PDPPL). Response window: 30 days. Breach notification: within 72 hours to the NCGAA where serious damage is likely; affected subjects notified accordingly. Regulator: NCGAA.

Oman — Royal Decree 6/2022 (PDPL); Executive Regulations effective Jan 2024. Response window: 45 days. Breach notification: without undue delay to the MTCIT (the Executive Regulations do not specify a numeric ceiling; we apply a 72-hour planning baseline). Regulator: MTCIT.

17.6 United States — California (CCPA/CPRA) and the state patchwork

Snipefinity does not currently target US residents and is below all state-law thresholds today. The following applies when, after US expansion, we accept US-resident users.

Categories of personal information collected (over the prior 12 months): identifiers (email, name, IP, device ID); commercial information (your strategies, paper-trading records, broker connections); internet or other electronic network activity (your interactions with the Snipefinity web application); inferences drawn from any of the above (none drawn today — see §11 on automated decision-making).

Categories of Sensitive Personal Information collected (CCPA §1798.140(ae)): broker access tokens, broker account identifiers (treated as account-login and financial-account material). We do not treat use of Snipefinity as an inference about your religious beliefs (see §9.8).

Sources. You, OAuth providers you authorise, your broker, our sub-processors.

Purposes. Providing the service you request; security; debugging; legitimate business purposes consistent with our service.

Sale / sharing. We do not sell or share personal information.

Your CCPA / CPRA rights. Right to know; right to delete; right to correct; right to opt out of sale/sharing (no-op today — we don't sell or share); right to limit use of Sensitive PI; right to non-discrimination; right (from 1 January 2027) to opt out of Automated Decision-making Technology (ADMT) when used for significant decisions. We characterise our Sharia classification and AI-assisted strategy generation features as not ADMT making significant decisions about you: Sharia screening operates on assets (not on users); AI-assisted strategy generation is human-in-the-loop (you initiate the prompt, you accept or reject the output, you decide whether to deploy the resulting strategy).

Response window. Acknowledge within 10 business days; substantively respond within 45 calendar days (extendable by another 45 days with notice).

Breach notification. California-resident breach notification is "in the most expedient time possible and without unreasonable delay" (Cal. Civ. Code §1798.82). The strictest state ceilings in our planning baseline are Colorado and Florida at 30 days; our service-wide internal target for US-resident breach notification is 30 days. State-by-state notification is handled in our incident-response runbook.

Global Privacy Control (GPC). We detect and respect the Sec-GPC: 1 header as an opt-out signal. Because we don't sell or share today, the signal has no operative effect — we will surface a confirmation indicator in account settings nonetheless.

Authorised agents. You may designate an authorised agent to submit requests on your behalf.

State patchwork. A single CCPA-grade disclosure is intended to satisfy the bulk of the in-effect state laws (Virginia VCDPA, Colorado CPA, Connecticut CTDPA, Utah UCPA, Texas TDPSA, Oregon OCPA, Indiana, Kentucky, Rhode Island, Delaware, Iowa, Tennessee, Montana, New Hampshire, New Jersey, Minnesota, Maryland, and others). We accept that Texas TDPSA applies regardless of revenue (based on processing of Texas-resident personal information, with a narrower small-business exemption than other state laws) and that Rhode Island RIDTPPA applies at the lowest absolute threshold (35,000 residents) — both may apply first as our user base grows.

Colorado AI Act (SB 24-205, effective 1 June 2026). A compliance assessment will be completed before any Colorado-resident user accesses AI-assisted features. Our current view, subject to that assessment, is that Sharia screening and AI-assisted strategy generation are not "high-risk AI systems" making "consequential decisions" within the meaning of the Act, because they are not used to make decisions about financial services, employment, education, healthcare, housing, insurance, or legal services in a way directly affecting the user (see ADMT characterisation above).

Notice for California residents (Shine the Light): we do not disclose personal information to third parties for their direct-marketing purposes.

18. Forward-looking commitments

Some features described in this Policy are operational today and some are forward-looking. We list the forward-looking commitments here, each with a target gate that fixes when the commitment must be substantively in place. If a milestone slips, we publish an interim v1.1 amendment before the gated event (see §16 amendment process).

We will mark each commitment as Achieved, In progress, or Delayed in this section as we update the Policy.

19. Contacting us about privacy

The fastest route is account settings → Privacy → Data and Rights.

• General privacy questions and data-subject requests: privacy@snipefinity.com
• Privacy lead during the unincorporated phase: Ahmad Alibrahim
• Operator address: Kuwait

You may also lodge a complaint with the supervisory authority in your jurisdiction (see §17).