Two roles, one gate
One login, many client books, access chosen per book — and a revocation that takes effect on the next click rather than when a token expires.
Admin
Sees every book on the system and picks one to work in. Creates and edits client books, creates logins, approves sign-up requests, resets passwords, and grants book access.
Client
Bound to its own book, which it can read and write. It sets its own rate card. It cannot reach the admin screens at all.
An admin can open a second book, at a level chosen per book
Read the book — P&L, positions, the trade log — and nothing else. Writes are refused with a clear message, not a silent failure.
Everything view allows, plus the write actions: upload a trade file, upload or delete a position file, set a dealer’s margin, deposit, slab and fee, manage the deposit ledger, and download the invoice.
For one concrete case: a client running two branches, each filing its own daily export. One login holds edit on both books and switches between them in the book selector — instead of two sets of credentials, or an admin account handed to someone who should not have the desk.
Each one enforced at a single point, and covered by a test named after it
Every book request passes through the same check, so a screen added next year still has to answer the question.
- A grant with no level named defaults to view. Write access to another desk’s book is never acquired by omission.
- Neither level reaches the admin screens, so a grant can never widen itself.
- Revocation is immediate — grants are read from the database on every request, never trusted from the login token.
- A client with no grants sees one book and is told nothing about the existence of any other desk on the system.
- Your own book is not a grant. It cannot be revoked out from under you.
- While reading someone else’s book the selector says view only and a badge sits in the top bar, so an upload that is about to be refused is never a surprise.
What holds it up underneath
Built to be locked down
Signed sessions with a configurable lifetime, one tenancy check every book request passes through, and an audit log recording who uploaded, replaced, granted and revoked what.
Uploads are treated as hostile
Size caps, file-signature checks, macro-enabled workbooks refused, and duplicate detection by hash. A workbook holding two genuinely different books is refused with the dealer codes in each named, because picking one would be a guess — and a wrong guess is a whole session of P&L on another client’s book.
Sized for real history
Every long table is paged on the server, and every total is computed over the whole filter regardless of what any page shows. It has been driven against real multi-month books, not a demo week.
Your data, your server
One server, yours. Your database, your uploads. Nothing is sent anywhere except the public exchange archives.
Running more than one book?
Tell us the shape of the desk — how many books, how many dealers, who needs to see what — and we will show you how it maps.