Security and custody

What is settled about credentials, access, custody and withdrawal authorisation — and what is not settled about the operational detail behind them.

What is settled.

Credentials“How do you handle passwords, and will you ever email me one?”

Never. No code path in this system generates a password or sends one, and that is verified by tests rather than asserted in a policy — a static scan of the server source plus a dynamic check that inspects every outbound message and stored record. Demo and production access both work the same way: a single-use link, and you choose your own credential on the page it opens. Stored credentials are scrypt verifiers at OWASP-recommended parameters, with the algorithm and parameters recorded per row so they can be upgraded without a migration.

Access and audit“Who at your company can see or change my data?”

Back-office actions are role-based per action and logged with who performed them, and that log is exportable — it is on the data ownership page as an entity you can take with you. Operating your environment means our engineers can reach it; what they do is recorded in the same log you can read. On the managed-infrastructure side the same applies: we can see your flow because we operate the deployment, and we are not a counterparty to it.

Withdrawal authorisation“What stops money leaving without the right approvals?”

Configurable steps, and a trail the database will not let anyone edit. The rules are yours: you set how many approvers a withdrawal needs and whether that requirement changes with amount, method or destination, and the configuration lives in your environment rather than with us. One rule is not configurable — the person who raised a withdrawal cannot be the person who approves it, at any amount, administrators included. A control that can be switched off by the account it exists to constrain is not a control, and it is the first thing an attacker holding one stolen session would switch off. The trail is immutable in the database rather than by convention: updates and deletes on the approval log are refused by a trigger and the application role is not granted them, which is the same construction as the consent log described on the data ownership page and holds regardless of which role connects, ours included.

Freezing withdrawals“Something looks wrong at three in the morning. Can I stop withdrawals myself?”

Yes, and without us. You freeze withdrawals yourself — platform-wide or on a single account — effective immediately, with no ticket raised and nothing required from ForgeBroker. Requests already approved but not yet settled are held by that same switch rather than allowed to drain, which matters because during an incident that batch is where the money at risk actually sits: a freeze that stops only new requests stops the wrong ones. We can help you investigate afterwards, and we would expect to, but we are deliberately not a step in stopping it. A control that waits on our response time is one your incident inherits our office hours for.

Custody“Who holds client money, and who holds the keys to it?”

You do, and you do. Keys are held by the broker, not by us: they are handed over to you during setup, and there is no stage — setup, operation, support or incident — at which ForgeBroker holds them, escrows them, keeps a copy or can recover them. Client funds are not present in ForgeBroker systems at any point. The platform records balances and instructs movements against accounts and wallets that stand in your name, which is what makes a dispute with us unable to strand your clients’ money: there is nothing of theirs in our custody to freeze. The consequence runs both ways and is worth stating rather than burying — we cannot recover a key you lose, and that is the same property that stops us moving your funds. Which providers hold the accounts, and how they are segregated, is your arrangement with them and belongs in your own disclosures; we are not a party to it and will not describe it on your behalf.