Multi-Account Terminal and Manager Tools: Allocation, Monitoring and Audit Architecture
Operating hundreds of accounts from one terminal requires three architectural pieces: a deterministic allocation engine, exception-based monitoring and a complete audit trail.
Allocation engine
Specify the allocation inputs (equity, balance, fixed lot or percentage), rounding, minimum and maximum lots, and behaviour for partial fills and rejections. The engine must be deterministic so the same inputs always give the same allocation. See our PAMM MAM and terminal page.
Monitoring
Monitor aggregate exposure, per-account deviations from the allocation rule, failed orders and accounts near stop-out. Alert on exceptions and keep a dashboard of aggregate state.
Access control
Define roles for managers, operators and auditors, restrict instruments and size, and require strong authentication. See CRM and integration security controls.
Audit trail
Log every order, allocation, modification and login with identity and timestamp. Retain logs for the required period and protect them from alteration.
Integration and reconciliation
Reconcile account balances, fees and statements with the CRM on a schedule, using the interface specified in the Manager API guide. Review regulatory implications in the PAMM/MAM specification.
Performance and capacity testing
Test the terminal with realistic account counts: order latency for allocation across hundreds of accounts, behaviour when many accounts reject, and screen update time.
Document the limits you find and keep headroom, because production load is rarely smooth.
Allocation engine specification
Specify the allocation engine as a deterministic function: inputs (master order, account set, account equity or balance, symbol constraints), rule (equal, equity-proportional, ratio, risk-based), rounding to the symbol step, minimum and maximum volume, and handling of residuals. Define what happens when an account cannot take its share: skip, reduce or reject the whole allocation.
Publish worked examples with fixed numbers and use them as test cases. Include odd lot sizes, very small accounts and accounts at the margin boundary.
Allocation test matrix
| Case | Input | Expected | Evidence |
|---|---|---|---|
| Equity-proportional, mixed sizes | 6 lots across 10k, 20k, 30k | 1, 2, 3 lots | Fill report |
| Rounding residual | 1.00 lot across 3 equal accounts at step 0.01 | 0.33 each plus residual rule | Allocation log |
| Margin shortage | One account below required margin | Defined skip or reduce | Rejection record |
| Partial fill | Master fills 60 percent | Pro rata allocation | Fill report |
| Symbol unavailable | Account restricted | Defined skip | Log |
Run the matrix after any change to rules or platform version.
Monitoring and capacity
Define dashboards for exposure by account, deviation from master, rejected allocations, latency from master order to last account fill and accounts near margin call. Set alert thresholds and owners.
Test capacity with realistic account counts: allocation latency at hundreds and thousands of accounts, behaviour during mass rejection and screen refresh time. Document limits and keep headroom.
Access control and audit
Separate roles for trading, rule configuration, fee settings and support. Require approval for rule changes and keep an immutable audit trail of who changed what and when. Reconcile allocations with fills and with CRM statements daily.
See our manager access guide for role design.
Worked example: mass rejection
During a volatile minute, 40 of 500 accounts reject due to margin. The engine applies the defined rule: skip those accounts, allocate to the rest and record the skipped list with reasons. The dashboard shows the rejection count and the affected accounts, and support receives a prepared message.
After the event, review whether margin thresholds or order sizing rules should change. The record becomes input to rule tuning.
Change management
Treat allocation rule changes as controlled changes with impact analysis, testing on a replica of account data and a release window. Version rules and keep the history linked to allocations.
Disaster recovery for the terminal
Define recovery objectives for the terminal and its data: allocation rules, account lists, history and audit trail. Test restoring a replica and verifying that allocations match known results. Document the manual procedure for trading if the terminal is unavailable, including how allocations will be applied afterwards.
Rehearse the procedure so that staff know how to proceed under pressure.
Frequently asked questions
How should allocation be specified?
As a deterministic function with rounding, limits, residual handling and exception rules, plus worked examples.
What happens when an account lacks margin?
Define the behaviour in advance (skip, reduce or reject) and disclose it.
What should be monitored?
Exposure, deviation from master, rejections, latency and margin proximity.
How do I test capacity?
With realistic account counts, mass-rejection scenarios and measured latency.