Privacy policy

Last updated September 16, 2026

PX Journals is a trading journal for futures traders, made by PX Trading LLC, 502 W 7th Street, Suite 100, Erie, PA 16502, United States. This policy says what the product stores, where that data is held, which other companies can see it, what a trader can ask for, and how a trader takes it back or deletes it. It covers the app, the public pages and the marketing site. A resident of a U.S. state with a privacy law finds the rights that law grants under State privacy rights below.

Where the data lives

The journal itself is held in the United States (ruling 72): the account, the fills, the trades, everything written by hand, and every image. There is one exception and it is named rather than buried. The company that sends the trial-ending email is in the European Union, and it receives an email address and the text of that message. No trade, no journal entry and no broker data leaves the United States, with one exception the trader controls: a page the trader chose to share is public, and the site delivery network serves it and its images from wherever a reader is.

PX Journals is not offered in the European Union, the European Economic Area, the United Kingdom or Switzerland (rulings 72, 83), and visitors from those regions are turned away before they reach a page.

What is collected

What a trader provides

• Contact and profile data: an email address, and a display name taken from the sign-in provider or from the part of the email address before the at sign. Signing in with Google supplies the email address and name Google holds; no password is ever set or stored (ruling 79).
• Journal content: tags, reflection answers, day notes, account nicknames, manual trades, fills imported from a CSV file, and images attached to a trade or a day.
• Broker credentials: an authorised token or a trader supplied API key, encrypted before it is stored and used only to read. A database copy carries no working broker token, and no broker password is ever held. What a credential could do is the broker's design, not PX's: a Tradovate authorisation is whatever Tradovate's own consent screen shows, and a TopstepX API key is a full-access key because TopstepX issues no other kind, which is why it should be treated like a password.
• Reports and messages: an in-app report about a wrong guess or a disputed number, and any email sent to the support address (ruling 25).
• The time zone the browser reports, so dates on the screen match the trading day (ruling 85).

What is read from other companies

• Broker fills and the trades built from them: symbol, side, size, prices, times and fees, read from the broker account a trader connects, using the access the trader authorised.
• Subscription status and billing dates mirrored from the payment processor. Card numbers never reach PX Journals.

What is recorded automatically

• Request logs at the hosting and delivery providers, which record the address a request came from, the page asked for and the time, for operating and securing the service.
• Error reports from the software itself, which carry the failing page or route and the browser that made the request, sent to the error-reporting provider.
• No advertising identifiers, and no cross site tracking. Product analytics is cookieless everywhere. Inside the product it is at most seven funnel events sent by the server, and no record of anything a trader clicks (rulings 72, 103). The public marketing page counts one page view, with the address of the page and the site the visit came from, and when a call to action button is pressed it also counts the name of that button. Both carry an identifier made fresh on every page load and kept only in memory: no cookie, nothing written into the browser, and a reload makes a new one. It is sent to PostHog with each of those two events and kept there for as long as they are, marked so that no person profile is built from it, which is why it cannot follow a reader from one visit to the next or onto another site.

What is not collected

• No card numbers, and no bank details.
• No precise location, no contacts, no government identifiers, no date of birth.
• Beyond the request logs and the two marketing events above, no data about anyone other than the trader who signed in: nothing about their clients, family or contacts, and nothing bought from a data broker.

How it is used

Data is used to run the journal: to build trades from fills, to show statistics, a calendar and prop firm rule tracking, to render the pages a trader chooses to share, to bill a subscription, to send the one notice a trial requires, to answer a support request, to keep the service secure, and to count the seven funnel events above. Nothing is used for advertising, nothing is used to build a profile of a trader, and nothing is used to train an artificial intelligence model.

Who else can see it

These companies process data on behalf of PX Journals, each for one job, under their own terms. Nothing is sold, and nothing is shared for advertising.

• Supabase. Database and sign-in. Data held in the United States.
• Railway. The server that runs the product. Data held in the United States.
• Cloudflare. Site delivery and image storage. Data held in the United States.
• Stripe. Payments and subscription billing. Data held in the United States.
• Brevo. The trial-ending email. Data held in the European Union.
• Sentry. Error reports from the software itself. Data held in the United States.
• PostHog. Cookieless product analytics. Data held in the United States.

Brevo sends the notice three days before a trial converts (ruling 90). It receives an email address and the text of that message, nothing about a trade.

Beyond those companies, data leaves PX Journals in three cases. A trader publishes a shared page, and whatever they ticked becomes public at that link until they revoke it. The law requires it, or a request from a court or an authority has to be answered, or answering protects a trader, the product or the public from fraud or harm. Or the business changes hands, in which case the account moves with it under this policy and the change is announced in the product before it happens.

How long it is kept

An account keeps its history for as long as it exists (ruling 9). Canceling a subscription does not delete the account or start a deletion countdown (ruling 91). Retained history remains readable and fully exportable. Request logs and error reports are kept by their providers for their own short operational windows, not for the life of the account. Database backups are taken weekly and kept for twelve weeks, so a deleted row can persist in a backup for up to twelve weeks after the delete; a backup is held only for recovery, never read for analytics, publication or ordinary use, and is never restored into the live product except to recover from data loss. If that ever happens, the restore is announced in the product and every account deletion requested after the backup was taken is run again before the product comes back.

A trader who deletes their account starts the delete straight away (ruling 53), and it finishes in three parts rather than one. The account records go in a single transaction: accounts, fills, trades, journal, notifications, billing mirror, queued background work, the record of every image, every other record tied to the account, and every shared page, so shared links stop resolving from that moment. The image files sit in image storage rather than the database, and the same transaction books the job that empties them out of storage shortly afterwards; storage that refuses is tried again until it takes them, rather than left holding the images. Deleting the account also cancels any subscription in the same step, so nothing is charged afterwards. The sign-in record is kept, because deleting it needs a key held by the sign-in provider that the product does not have. What stays is an email address and the sign-in method behind it. Signing in with it again starts an empty account. A trader who wants that record gone too writes to [email protected] after the delete, and it is removed at the sign-in provider by hand within five business days, which also removes the trial-used marker below.

If the account has trial history, PX keeps one trial-used marker linked to the retained sign-in identity so returning to PX does not grant a second trial. The marker holds no Stripe customer or subscription id, payment details, email address, status or date. It is removed if that sign-in identity is deleted. An account with no trial history retains no marker. Detailed billing records held by PX are deleted with the account; payment records held by Stripe remain subject to Stripe's own retention policy.

Taking it back, and deleting it

Every account can export everything it holds, at any time and without asking: CSV files of fills, trades and journal, and a full takeout with every image, downloaded from the settings screen (rulings 53, 81). Every account can delete itself. There is no screen for deleting an account yet. The delete is a call to the product API, made with an API key a trader makes on the settings screen, in two steps. The first counts what is about to go, points at the takeout, and hands back a confirmation good for fifteen minutes; nothing is deleted until a second call sends that confirmation back. Neither is a support request. A trader who would rather ask than call an API can write to [email protected], and the same delete is run for them within five business days of the request being verified. One request is enough: it covers the account, any subscription, every broker credential, the sign-in record and the trial marker, and the reply says what went and what remains in backups for the window above. Image files are gone from storage within thirty days of the delete, and are unreachable from the moment the account records go.

A trader corrects their own data inside the product: account names, plan bindings, parser guesses and every journal entry are editable in place (ruling 87). A connected broker can be disconnected from the accounts screen at any time; history stays and syncing stops (ruling 9).

Security

Broker credentials are encrypted with AES-256-GCM before they are written. Row level security is on for every table: every table holding a trader's own rows fences them to that trader, and the rest are either public reference data such as firms, plans and fee schedules, or closed to the browser entirely. Shared pages are frozen snapshots that carry no account identity unless the trader ticked the box that adds it, and revoking a share stops the page resolving. Sign-in is a one-time emailed code or Google, never a password held by the product. No system is perfectly secure; a breach that affects a trader is disclosed to them as the law requires.

Children

The product is for adults trading futures accounts and is not offered to anyone under eighteen. An account found to belong to a minor is deleted, and a parent or guardian who believes one exists can write to [email protected].

Other sites

The product links to brokers, prop firms and the payment processor, and a shared page can be embedded elsewhere. Google, when chosen as the way to sign in, sees that sign-in under its own policy. Those companies keep their own privacy practices, and a link is not an endorsement.

Do Not Track and Global Privacy Control

Nothing is sold and nothing is shared for advertising, so a browser's Do Not Track or Global Privacy Control signal asks for what already holds. Neither signal changes what the product does, because there is nothing for it to switch off.

State privacy rights

A resident of a state whose privacy law reaches PX Journals, among them California, Colorado, Connecticut, Virginia and Texas, can ask for the following, and the same answers are given to every trader regardless of state.

• To know what is held and to receive a copy of it. The takeout above is that copy, and the What is collected section is the list of categories.
• To correct it. Editing in the product is the correction.
• To delete it. The two-step delete above is the deletion.
• To opt out of sale, of sharing for targeted advertising, and of profiling. There is nothing to opt out of: PX Journals sells no personal information, shares none for advertising, runs no targeted advertising and makes no automated decision with a legal or similarly significant effect on a trader.
• Sensitive information. One thing the product holds is sensitive under California law: the broker credential a trader connects, because it is a credential that allows access to a financial account. It is used only to read the account the trader connected, which is the service the trader asked for, and never to infer anything about them, so the right to limit its use has nothing further to limit. Disconnecting the broker removes it. Nothing else the product collects is a sensitive category, and no data is used to infer characteristics about a trader.
• To appeal. A trader whose request is refused can reply to the refusal at [email protected] and the refusal is reviewed again, with the reasons given in writing.

A request made from inside a signed-in account needs no further verification. A request made by email is honoured when it comes from the email address on the account, and an agent acting for a trader is asked for that trader's written permission. Exercising any of these rights never changes the price or the service. No personal information has been sold or shared for advertising in the twelve months before the date at the top of this page. Under California Civil Code section 1798.83 a California resident can ask which third parties received personal information for their own direct marketing; the answer is none, and the request goes to the same address. A Nevada resident can direct that personal information not be sold; none is.

Changes

A change to this policy changes the date at the top of this page. A change that alters what happens to existing data is announced in the product before it takes effect.

Contact

Questions about this policy and requests under it go to [email protected], or by post to PX Trading LLC, 502 W 7th Street, Suite 100, Erie, PA 16502, United States.