idle

Privacy Policy

Last updated July 17, 2026

1. The short version

Idle collects the minimum it needs to run a treasury product: who you are (via Clerk), what your workspace records (in our database), and your subscription state (via Stripe). The public demo collects nothing — its ledger lives in your browser. We run no analytics or advertising trackers today, we don't sell data, and the only cookies are the ones that keep you signed in.

2. What we collect, and where it lives

  • Account and waitlist data (Clerk). When you join the waitlist or sign up, our identity provider Clerk collects your email, name, and authentication credentials. Idle reads your profile basics and verified email; passwords and auth secrets stay with Clerk.
  • Workspace records (Neon Postgres). Organizations, members, invitations (including invitee email addresses), and the financial records your team enters — accounts, journal entries, transfers, T-bill positions. This is your data; we store and process it to run the Service.
  • The audit log.Workspace actions are recorded append-only: who, what, when, and from where — the client IP address and a deliberately coarse browser/OS family (e.g. “Chrome on macOS”). Full user-agent strings are never stored. This is a compliance record for your organization, not analytics.
  • Connected bank data (Plaid). If your organization connects a bank account, our data aggregator Plaid provides — read-only — the institution name, account names, masked account numbers, account types, balances, and transactions (date, description, amount). You authenticate at your bank inside Plaid's flow; your bank credentials never touch Idle. The access token Plaid issues is stored only encrypted (AES-256-GCM) and is discarded when you disconnect or revoke access at your bank. Idle cannot move money through a connected account. Plaid's own handling is governed by its End User Privacy Policy.
  • Billing (Stripe).For paid plans we store your organization's Stripe customer and subscription identifiers and subscription status. Card numbers go directly to Stripe and never touch our servers.
  • Operational logs (Vercel). Our hosting provider produces standard server request logs, which we use to keep the Service running and secure.

3. The demo collects nothing

The Meridian Robotics demo needs no account. Its simulated ledger is seeded and stored in your browser's local storage; nothing about your demo session — balances you type, transfers you simulate — leaves your machine or reaches our servers. Rate data is fetched by our servers from public sources and served to you; no per-user data goes the other way.

4. What we don't do

  • No selling or renting of personal data, to anyone, ever.
  • No third-party analytics, advertising pixels, or cross-site tracking. If we add privacy-respecting product analytics later (it is on our roadmap), this policy and our cookie stance will be updated first.
  • No reading of your workspace financial records except to operate the Service, debug with your permission, or as the law requires.
  • No use of your data to train machine-learning models.

5. Cookies

Idle sets only strictly-necessary cookies: the session cookies our identity provider Clerk needs to keep you signed in and protect against request forgery. There are no analytics, preference, or advertising cookies — your theme choice, and the demo ledger itself, live in local storage on your device and are never transmitted. Because every cookie is strictly necessary for the Service to function, we do not show a cookie consent banner; if we ever add non-essential cookies, consent will ship in the same release.

6. Who processes data for us

We share data only with the processors that run the Service: Clerk (identity and waitlist), Neon (database hosting), Stripe (payments), and Vercel (application hosting and logs). Each receives only what its role requires. We disclose data beyond this only if the law compels it, and where permitted we will tell you first. Market-data requests to FRED and the U.S. Treasury are made by our servers on their own behalf and carry no user data.

7. Retention and deletion

Workspace records persist for the life of the workspace — a lapsed subscription downgrades the plan but deletes nothing. The audit log is append-only by design (plan limits control how far back it is visible, not what exists), because that is what makes it an audit log. If you ask us to delete your account or organization, we will delete or anonymize your personal data within a reasonable period, except records we must keep for legal, security, or financial-compliance reasons — and we will tell you which those are.

8. Your rights

You can access, correct, export, or delete your personal data by emailing justin@notar.nyc. Waitlist emails are deleted on request. Depending on where you live (e.g. the EU/EEA under GDPR, California under CCPA/CPRA) you may have specific statutory rights; the formal mechanics of honoring them — legal bases, data-transfer mechanisms, and a designated representative — are for counsel to settle before this policy leaves draft. Our intent meanwhile is simple: it's your data, and you can have it or have it gone.

9. Security

Data moves over TLS and is stored with providers that encrypt at rest. Access to production data is limited to those who operate the Service. Tenancy is structural: every workspace row is scoped to its organization in the database schema itself, and role limits are enforced server-side. No system is perfectly secure; if a breach affects your data, we will notify you as the law requires and as fast as we honestly can.

10. Children, changes, contact

Idle is a business tool, not directed at children under 16, and we do not knowingly collect their data. Material changes to this policy will be announced on this page (and to account holders by email) before taking effect. Questions or requests: justin@notar.nyc. See also our Terms of Service and product disclosures.