PLATFORM · SECURITY
Thirty-five permissions. No one moves money alone.
Role-based access control across every module. Per-broker database isolation. Every sensitive action requires a second approver. Every session is auditable.
Security in a brokerage platform is not a checkbox. It's the assumption that the person sitting at the dashboard could be malicious, and the system still makes the right decisions. Slate's security layer was built under that assumption — a comprehensive RBAC matrix, a second-approver gate on every action that moves money, and per-broker database isolation that holds even if the application layer is compromised.
The RBAC matrix
Thirty-five permissions, mapped per role, enforced at every layer.
Slate ships with 35 distinct permissions spanning every module: trading, payments, CRM, workflows, compliance, back office, reporting. Permissions map to roles; roles map to users; the enforcement happens at the API layer, the database layer (via row-level security on per-broker isolation), and the UI layer (which hides controls the user can't invoke anyway). A role can be authorized to propose a bonus but not to approve it. A role can be authorized to read client PII but not to export it. The granularity is the point.
Why two-person approval
One authorized role proposes. A different authorized role approves. The action fires.
Every action that moves money — bonus grants, fee adjustments, margin changes, KYC overrides, jurisdiction rule changes, withdrawal approvals above a threshold — passes through the second-approver gate. The proposer cannot approve their own action. The audit ledger records every proposal, every approval, every rejection, and the reason. Your compliance officer knows, by construction, that nothing you can't account for can happen on the platform.
Per-broker database isolation
Each broker runs in a separate database. Not a schema. Not a tenant column.
Multi-tenant SaaS platforms usually share a database across tenants and trust a `broker_id` column to keep them separate. Slate does not. Each broker runs in its own PostgreSQL database with its own credentials, its own row-level security, and its own backup lineage. A SQL injection or application bug that leaks one broker's data cannot leak another's, because the connection string was never anywhere it could do that. For multi-entity operators, the isolation is enforced at the DNS, the load balancer, the application, and the database — four layers, all aligned.
Sessions, tokens, and duplicate protection
HS256 JWTs with bcrypt-hashed credentials. Three layers of idempotency. Duplicate logins flagged and queued for review.
Authentication uses HS256 JWTs with bcrypt-hashed password storage and configurable session expiration. Every mutating API request is idempotent across three layers — database, application, and gateway — so a webhook retry or a double-clicked button never causes a duplicate effect. Duplicate-login detection catches the common account-sharing pattern and sends it to compliance for review. Every login, every token refresh, every suspicious event is in the audit ledger.
35 RBAC permissions · Two-person approval on money moves · Per-broker database isolation · Row-level security · HS256 JWT sessions · Bcrypt password hashing · 3-layer idempotency · Duplicate-login detection · Full audit ledger
Use this to solve
See the permission matrix.
Book a demo and we'll walk you through a real broker's RBAC configuration — role by role, permission by permission.