Handing a piece of software your brokerage credentials is the single largest act of trust in this whole product category, and most tools in it say almost nothing about what happens next.
Here is what happens in ours.
The shape of the problem
To trade your account, something has to be able to authenticate as you. There is no clever way around that. The question is what form that authority takes, how narrow it is, where it is stored, and who can read it.
Bad answers are common. A single master credential held by the vendor, with access to every customer account. Credentials in plain text in a database. One shared secret used by every running process, so a compromise anywhere is a compromise everywhere.
Each of those is easier to build than the alternative, which is why they are common.
Scoped tokens, not master keys
TTMT has a master API token for our trading infrastructure. It can do a great deal, including creating and deleting accounts.
Your trading container never sees it.
When your account is provisioned, that master token is used once, at the moment of setup, to mint a scoped token. A scoped token authenticates against your account specifically and carries narrowed permissions. It is what the container running your trades actually uses.
The consequence is the point. The process that executes your trades, which is the part running continuously and therefore the part with the largest exposure, cannot reach anyone else's account. Not because it is asked not to, but because the credential it holds does not address them.
Scoped tokens expire. They are regenerated on a schedule, well before expiry, by a job that runs against the master token in a place your container is not.
Encrypted at rest
Tokens are encrypted in the database. They are decrypted at the point of use, by the process that needs them, and the encryption functions live in the database layer rather than in application code.
A database dump therefore yields ciphertext. That is the property worth having, because the realistic threat is not somebody defeating the encryption. It is a backup landing somewhere it should not, or a query returning more than intended.
One secret per container, not one for everyone
Your trading service runs in its own container. When the dashboard needs to talk to it, that request is authenticated.
Every container is provisioned with its own secret, generated at setup. The dashboard looks up the specific secret for the specific instance it is calling and presents that.
The alternative, a single shared secret across the whole fleet, is much simpler and much worse. With one secret, anything that learns it can talk to every container. With per-instance secrets, learning one gets you one, and rotating one affects one.
The database enforces isolation, not the application code
Every table holding sensitive data has row-level security on it. The rules live in the database, and they say a user can reach their own rows.
The reason this matters is that application code has bugs. A query that forgets a filter, a join that widens more than intended, an endpoint that trusts a parameter it should have checked: these are ordinary mistakes and they happen in every codebase.
If isolation is enforced only in application code, any one of them leaks data. If it is enforced in the database, the same mistake returns an empty result instead.
Financial tables are scoped per account. Settings tables are scoped per user, because you need to see your own settings across all of your accounts. The distinction is deliberate rather than incidental.
Your trades do not look like ours
A smaller thing, and the one prop traders ask about most.
Order comments and deal reasons carry nothing that identifies TTMT. Your trades look native to your broker and to your prop firm, because they are your trades placed on your account, and there is no reason for them to be labelled otherwise.
What I am not claiming
No system is unbreakable and I am not going to write a paragraph implying ours is. Every design above reduces blast radius rather than eliminating risk. The master token exists. The database exists. Compromise is possible.
What these choices change is what a compromise gets you. A leaked container secret gets one container. A stolen scoped token gets one account, for a limited time, with limited permissions. A database dump gets ciphertext. There is no single credential whose loss is catastrophic across every customer, and that is the property actually worth engineering for.
You should also hold your side. Use a broker password unique to trading. Where your broker offers an investor password or a read-only mode for anything you do not need to be a trading credential, use it. And if you stop using TTMT, change the password rather than trusting that we deleted something.
Related: how TTMT watches a trade after it's placed, and what a signal copier is.
Start a free 7-day trial at telegramtometatrader.com.
