PLATFORM · TRADING ENGINE
The trading engine. Atomic. Accountable. Fast.
ACID execution via stored procedures. Five asset classes. Six order types. Stopout with session-level audit. Negative balance protection enforced at the engine — not the CRM.
The trading engine is the one piece of a brokerage where being wrong is not recoverable. A balance that's slightly off, a trade that posts twice, an order that fills when it should have been rejected — every one of those is a phone call from a client that your retention rules can't fix. The Slate engine was built under the assumption that every trade is a permanent record, and every balance is the source of truth.
The execution model
Every trade posts through an ACID stored procedure. Every balance is atomic.
A buy order at Slate doesn't cross two systems that might or might not agree. It executes inside a single stored procedure that debits the balance, credits the position, writes the ledger entry, and updates the exposure — in one transaction, with one outcome, with one audit row. Either everything happens or nothing does. The retry logic is idempotent across three layers, so a duplicated webhook never duplicates a trade. The "zombie position" bug that chases every bolted-together brokerage platform does not exist here.
The order type matrix
Six order types. Stop-loss, take-profit, and trailing stops as first-class citizens.
Market, limit, stop, stop-limit, trailing stop, and conditional — six order types, all native to the engine, all executable against any of five asset classes (FX, crypto, commodities, indices, stocks). Stop-loss and take-profit are attached to the position at the engine level, not inferred from the client app, so they survive client disconnect. Trailing stops recompute on every tick inside the engine's tight loop.
When the market moves against your client
Session-level stopout audit. Negative balance protection at the engine, not the CRM.
Stopouts fire through the engine's session layer with a full audit trail: every liquidation, every margin call, every negative-balance-protection event is recorded in the TimescaleDB financial ledger with the exposure state at the moment of the fire, the reason, and the approving role if any. Negative balance protection is a hard rule at the engine — no client ever ends a session with a debit balance on the book. Your CFO's spreadsheet of "clients we should write off" is empty.
The data feeding the screen
Sub-second WebSocket prices. Economic calendar. Market data baked in.
Traders see prices on a sub-second WebSocket feed that terminates at the engine, not a separate data vendor's widget. The economic calendar, the symbol metadata, and the trading session rules all live in the same transactional database as the trades — so a server-side rule like "freeze this symbol during the NFP release" is a single-row update, not a vendor integration. Price feeds are configurable per symbol; any new feed source is live in hours.
ACID stored procedures · 6 order types · 5 asset classes · Sub-second WebSocket prices · Stop-loss at engine level · Trailing stops per-tick · Session-level stopout audit · Negative balance protection · 3-layer idempotency · TimescaleDB financial ledger · Any new LP route in hours
See the engine running.
Book a demo and we'll walk you through an ACID stored procedure posting a trade — live, in a real broker's Slate environment.