RTX5 Broker Administration:Manager and Admin Consoles
Preview broker staff workflows for account scopes, groups, symbols, spreads, routing, approvals and audit records. Confirm each web/Windows client task and permission boundary on a named build.
Choose a console and confirm its scope
Broker Manager and Admin consoles serve staff operating a broker deployment. Capital-manager tools serve investment allocation and investor mandates; access to one should not imply access to the other.
Swipe horizontally to view all columns.
| Client | Tasks to demonstrate | Build and availability |
|---|---|---|
| Manager web | Assigned accounts, operational actions and denied access to unassigned groups. | Not verified: browser/client/server versions, task coverage and review date have not been published. |
| Manager Windows EXE | Sign-in, assigned accounts, operational actions and consistent server permission enforcement. | Not verified: signed installer, supported Windows version and server compatibility record have not been published. |
| Admin web | Permission changes, group/symbol configuration, approval workflow and audit export. | Not verified: supported-task results and named build are unpublished; interface availability does not establish full parity. |
| Admin Windows EXE | The same agreed administrative scenarios, including permission denial and session expiry. | Not verified: package version, server compatibility and task acceptance results are unpublished. |
Roles & Permissions
Manager Role
Proposed operations within assigned tenant/account groups: review accounts and approved requests. A Manager title alone does not grant payment approval or trading-configuration authority.
Admin Role
Explicitly scoped configuration and permission management. Tenant, group, symbol and action boundaries still apply; an Admin title is not unrestricted system-wide access.
Account Scopes
Specify permitted tenant, account groups, symbols and operations. Verify direct API, export and stale-session denial outside that scope.
Audit Logging
Required audit output identifies actor, target, before/after values, approver, timestamp, configuration version and result. Actual fields and retention require verification.
Configuration & Operations
Groups
Define proposed account groups and approved trading conditions; test supported configuration and isolation on the named build.
Symbols & Spreads
Specify supported symbols, units, spread/commission profiles and schedules with per-group permissions and versioned approval.
Routing Rules
Disclose external, internal or hybrid execution policy and supported routing controls. Changes require scoped permission, approval and reviewable records.
Approvals
Specify requester, approver, effective version and reconciliation for supported payment or configuration changes. Approval is separate from provider settlement.
Permissions Matrix
Test who may modify pricing, approve withdrawals, change rules or override a setting. Retain denied-case and tenant/account-isolation results.
Client Access
Manager/Admin web and Windows EXE tasks require independent build and acceptance records. Shared server APIs do not establish complete client parity.
Define who can request, approve and apply a change
The following matrix is an illustrative least-privilege policy for discussion. Actual permission names, approval separation and enforcement must be confirmed in the deployed build.
Swipe horizontally to view all columns.
| Action | Requester / scope | Approval and audit boundary |
|---|---|---|
| View or service accounts | Manager assigned to a tenant and account group. | Deny unrelated groups and tenants, including direct API requests and exports. |
| Change spread or commission | Authorized administrator within an assigned tenant, group and symbol scope. | Record old/new values, reason, approver, effective time and policy version; communicate the applicable trading conditions. |
| Approve withdrawal | Payments operator assigned to the relevant client and request. | Separate request creation from approval when required; account approval does not itself confirm provider settlement. |
| Change routing policy | Administrator with an explicit routing permission. | Review the execution-policy impact, approval and rollout/rollback version before applying changes. |
| Override a rule or grant access | Specifically authorized administrator; an Admin title alone is insufficient. | Record the exact scope, reason, duration and approving identity. Review inherited permissions and expiry. |
- 01
Request a versioned change
Illustrative request CFG-EXAMPLE-01 changes a demo group's symbol markup from 0.2 to 0.3 pips. Capture group, symbol, units, effective time and the existing configuration version.
- 02
Review the effect
A separate authorized reviewer checks the example change against the published account terms, symbol precision and affected accounts. Reject requests outside the requester's tenant or permission scope.
- 03
Apply and record
Apply only after approval. The audit entry should link request, operator, approver, before/after values, configuration version, timestamp and outcome. Failed changes should also have a traceable result.
- 04
Reconcile or roll back
Read the effective configuration and test an affected demo account. If the result differs from the approved request, follow the agreed rollback process and retain both change records.
Swipe horizontally to view all columns.
| Scenario | Expected policy result |
|---|---|
| Manager requests an account in another tenant | Access denied with no account details returned; denial recorded according to the audit policy. |
| User can view withdrawals but tries to approve one | View permission does not authorize approval; request remains unchanged. |
| Removed permission is reused through an existing session | Server enforces the agreed revocation policy; old interface state cannot authorize the action. |
| Two administrators edit the same configuration version | Detect the stale version and require review instead of silently overwriting the later change. |