Privacy Policy.

Schduler Technology Solutions LLC (“Schduler”, “we”, “us”) is the data controller for the personal data collected through the customer application at app.schduler.co and the marketing site at schduler.co. The product is non-custodial crypto trading automation software: customer funds remain on the customer’s exchange at all times and Schduler never holds custody.

For privacy questions or to exercise any of the rights listed below, write to legal@schduler.co. General product contact: hello@schduler.co.

Schduler collects only what is required to operate the product, comply with regulation, and keep the account safe. The full list:

• Account. Email address (Supabase Auth), hashed password (handled by Supabase — Schduler never sees the plaintext), optional display name, jurisdiction attestation, and account state.
• Identity verification (KYC). For live-mode and paid tiers we use Stripe Identity to verify a government-issued ID and a selfie. Schduler never sees the underlying images. Stripe returns only the verification result (verified, requires input, failed) and an opaque session identifier; those are what we persist.
• Exchange API credentials. The API key, secret, and (where the exchange requires it) passphrase you bind to a Schduler bot. These are encrypted at rest with AES-256-GCM using an application-managed encryption key and are never logged in plaintext. Migration to envelope encryption with KMS-managed wrapping keys is on the security roadmap and tracked per credential row via the kmsKeyArn pointer. We persist a permissions fingerprint (SHA-256) and the detected account balance only.
• Billing. When you subscribe via Stripe Checkout, Stripe collects the payment method and bills directly. Schduler stores the Stripe customer ID, subscription ID, tier, and the tax invoice address Stripe captured at checkout. Card numbers and CVCs never reach Schduler infrastructure.
• Audit log. Every state-changing event on your account — sign-in, eligibility attestation, exchange connect, bot activate, plan change, KYC outcome, password change, 2FA enrol — is written to an append-only Activation table with timestamp, event type, and a sanitised payload.
• Session metadata. Approximate IP address (last octet masked at render time), user agent string, and Supabase session identifier. We use these to render the active-sessions panel and to populate security-event records.
• Two-factor recovery codes. Stored as argon2id hashes. The plaintext is shown to you once on enrolment and never again. We never log, mail, or display the codes after issuance.
• Trade telemetry. For each bot instance: asset, side, quantity, price, fill type, PnL, fee, and an engine event blob. This is the operational record of work the engine performed on your authorisation.
• Equity snapshots. Periodic equity curve points for the dashboard sparkline and the user’s own performance review.
• Risk disclosure acceptances. The exact disclosure version you accepted, the timestamp, the source IP, and a canonical payload recorded in an append-only row. Cryptographic signing of the row (Ed25519) ships alongside the engine integration; the schema reserves the field today so historical rows can be backfilled when the signer goes live.
• Cookie preferences. Your choice in the cookie banner is persisted in a first-party cookie called cookieConsent.

Each category above is collected for a specific purpose and rests on a specific legal basis under GDPR:

• Contract (Art. 6(1)(b)). Account, billing, exchange credentials, trade telemetry, equity snapshots, risk-disclosure acceptances. We cannot deliver the product you signed up for without these.
• Legal obligation (Art. 6(1)(c)). Identity verification and the long-tail records that attach to it. Applicable AML and counter-terrorism financing rules require us to identify customers and keep that record for the retention windows listed below.
• Legitimate interest (Art. 6(1)(f)). Audit log, session metadata, security-event records. The interest is keeping accounts secure and being able to reconstruct what happened during an incident. The data is minimised (no PII in payloads, IPs masked at render) and the surface is gated to the account holder.
• Consent (Art. 6(1)(a)). Optional analytics cookies, marketing emails (we do not run a marketing list at this time). You can withdraw consent at any moment from the cookie banner; the withdrawal does not affect any processing that already occurred under the consent.

Schduler relies on the following processors. Each is contractually bound to confidentiality and to GDPR processor obligations under the Data Processing Addendum we accept on each provider’s account. None of them is authorised to use your data for their own marketing purposes.

• Supabase. Authentication (managed Postgres + Auth service). Stores your email, the hashed password Schduler never sees, and the Supabase session records.
• Stripe Payments. Subscription billing, card processing, invoice generation. We never see card numbers or CVCs.
• Stripe Identity. KYC document and selfie capture. Stripe is the controller of the underlying images and biometric vector; Schduler is the recipient of the verification result only.
• Resend. Transactional email delivery (verification, password reset, security alerts, receipts).
• Cloud infrastructure. Hosting and storage for the Next.js application, the Prisma database, and the engine runtime. The region pairs with the legal hosting choice described in Section 6.
• Connected exchanges. The exchange you bound an API key to receives orders Schduler places on your authorisation. Schduler currently supports OKX; additional venues are added as they pass integration and risk review, and the list at the connect step is the authoritative one at any given time. Schduler exchanges data only with the exchange you chose.

We do not sell personal data. We do not share personal data with third parties for their own purposes. We may disclose data to a competent authority where required by binding law and only to the extent required.

Retention windows are aligned with the strictest of contractual need, regulatory requirement, and the evidentiary minimum required to defend a future dispute:

• Authentication + KYC records: seven (7) years from the closure of the account, per the applicable AML/CTF retention obligation.
• Audit log (Activation table): five (5) years from the event. Audit rows are append-only; we do not edit historical entries.
• Trade telemetry, equity snapshots: five (5) years from the closure of the bot instance.
• Encrypted exchange credentials: retained only while a bot instance is bound to them. Revoked credentials are zeroised within thirty (30) days; the audit row referencing the credential ID persists.
• Session metadata: ninety (90) days, then purged.
• Deleted accounts: soft-deleted for thirty (30) days (the “cooling-off” window during which you can restore the account by signing back in). After thirty days the row is anonymised — email replaced with deleted-<id>@schduler.invalid, display name and jurisdiction nulled, PII fields zeroised. The audit log entries are retained (unlinked from the user row) for the audit-log retention window above.

At the date of this version, Schduler hosts the application and the managed database in the European Union (Frankfurt, Germany — Vercel fra1 for the Next.js application and Supabase EU-Central for the Postgres database). The engine runtime, when active, runs in the same EU region. The hosting region is reviewed periodically and may change as the business evolves; the version stamp at the top of this page will move with it.

Where Stripe, Stripe Identity, or Resend process data in a third country, the transfer is governed by the European Commission’s Standard Contractual Clauses through the Data Processing Addendum each processor publishes and which is binding on our account. Field-level encryption is applied to exchange credentials on top of encryption at rest.

Under GDPR you have the following rights with respect to the personal data Schduler holds about you:

• Access. You can download a complete machine-readable export of your account from /account/security → Download my data.
• Rectification. You can edit your display name and tax invoice address directly from the account surface. Email changes flow through re-verification. For anything else, write to legal@schduler.co.
• Erasure (“right to be forgotten”). From /account → Danger zone you can request account deletion. The request is honoured subject to the AML retention window in Section 5 — identity records cannot be erased before seven (7) years have elapsed, but everything else is purged per the schedule.
• Portability. The export above is in pretty-printed JSON, a structured machine-readable format, and contains every record we hold under your user id.
• Restriction. You can pause every bot, revoke every exchange credential, and disable every authentication factor from inside the product. For a broader restriction request write to legal@schduler.co.
• Objection. You can object to processing based on legitimate interest. Write to legal@schduler.co with your reasoning; we will respond within the statutory window.
• Withdraw consent. Any cookie or analytics consent can be withdrawn from the cookie banner, which is re-openable from the Cookie settings link in the footer.
• Right to complain. You may lodge a complaint with the data protection supervisory authority in your habitual residence or place of work.

We respond to substantive rights requests within one (1) calendar month from receipt. If the request is complex we may extend by up to a further two months and will tell you so in writing within the first month.

Schduler uses a deliberately small cookie set. The banner at first visit lets you make a per-category choice; you can re-open it from the Cookie settings link in the footer.

• Essential. sb-access-token, sb-refresh-token (Supabase Auth session), sd_status (edge-runtime status hint), cookieConsent (your banner choice). Always on — the product does not function without them.
• Functional. theme (your dark/light preference, written to localStorage in addition to a session cookie). Off by default; opt-in.
• Analytics. Currently none. Reserved category — any future page-level analytics will be gated on this consent toggle and named explicitly here before it ships.

Concrete security posture, not aspiration:

• Exchange API keys, secrets, and passphrases are encrypted with AES-256-GCM using an application-managed encryption key. Plaintext never reaches the database row. Migration to envelope encryption with KMS-wrapped data keys is on the near-term security roadmap; each credential row carries a kmsKeyArn pointer so the upgrade is forward-compatible without re-onboarding.
• Two-factor recovery codes are hashed with argon2id at parameters that meet OWASP 2024 guidance.
• Two-factor authentication itself is RFC 6238 TOTP, delivered by Supabase MFA.
• The Activation log is append-only by convention (enforced at the route layer; database-level trigger ships with the next migration window). Historical rows are not edited.
• All inbound state-changing requests are origin-checked and rate-limited.
• Session metadata logs mask IP addresses at render time (last octet replaced with •••) and never carry full user-agent strings into payloads.

No security posture is perfect. If you believe you have found a vulnerability, write to security@schduler.co. We will acknowledge within seventy-two (72) hours.

The Schduler engine generates signals and executes orders on the user’s authorisation. These are deterministic operational outputs of trading-strategy software, not automated decisions about a person in the sense of GDPR Article 22. No Schduler system produces a legally significant or similarly significant decision about you from your personal data alone.

Eligibility blocking (US persons, sanctioned jurisdictions) happens at /eligibility based on your own attestation; there is no profile-scoring component.

Schduler is restricted to users who are at least eighteen (18) years of age. US persons and sanctioned jurisdictions are blocked at the eligibility gate before any account becomes operational. We do not knowingly process personal data of children.

We will update this page when our processing changes materially. If the change is material we will email every active account at the address on file before the new version takes effect. The version stamp and effective date at the top of this page are authoritative; previous versions are retained off-platform in the Schduler engineering source history.

Schduler Technology Solutions LLC.

Privacy / DPO: legal@schduler.co. Product: hello@schduler.co. Security: security@schduler.co.