Staff roles and permissions in a brokerage back office: a design guide

A sales agent resigns on a Sunday and joins a competitor two weeks later. Within days, clients from their book start getting calls from the new firm. When the manager looks at the back office, it turns out the agent could export the entire client list, not just their own leads. Nobody had ever asked why.

The short answer: every back-office permission answers three questions. Which part of the system, which action, and whose records? Build roles from what each desk actually does rather than from job titles. Give each role the least it needs. Keep conflicting duties apart. Write down how people join, move and leave, and review access on a fixed schedule.

QUANTIX, which publishes this guide, sells a brokerage CRM and back office, so we have a commercial interest in the subject. The principles below apply to any system, and QUANTIX appears only in the last section. This is not legal advice: what your regulator expects of your internal controls is for your compliance officer to confirm.

Three questions behind every permission

"Admin" and "user" is not a permission model. A workable one combines three dimensions:

Dimension	Question	Examples
Module	Which part of the system?	Leads, customers, transactions, KYC queue, trades, settings
Action	What can the person do there?	View, create, edit, delete, import, export
Data scope	Whose records?	Their own, their direct reports', their team's, everyone's

Data scope is the dimension simple systems leave out. Two agents can hold identical rights on customers, yet one sees only their own book while the other sees the whole client base. That is the difference between an employee who leaves with their contacts and one who leaves with your database.

Two actions are routinely underestimated. Export moves data into a file you no longer control. Delete erases evidence you may need in a dispute or an audit. In most cases, deactivating a record or changing its status is the safer choice.

Start from the desk, not the job title

Titles vary from firm to firm; the work does not. For each desk, write down what it needs, its usual scope and what it has no reason to touch. Treat this table as a starting point, not a template:

Desk	Needs	Usual scope	Has no reason to hold
Sales agents	Leads, calls, notes, lead-to-customer conversion	Own leads and customers	List export, payment approvals, KYC decisions
Sales managers	Assigning and reassigning leads, team follow-up	Team	Transaction edits, platform settings
Retention	Customer record, trading and transactions (read), notes	Own book or team	Withdrawal approval, trade edits
Support	Contact details, request status	As requests are assigned	Full payment details, export
Compliance	Documents, KYC queue, audit trail	Everyone	Lead conversion and assignment
Finance	Transactions, approvals, export for reconciliation	Everyone	Client personal data edits, role settings
Dealing desk	Positions, orders, instrument settings where needed	Everyone	Withdrawal approval, lead edits
System administrator	Users, roles, settings	Everyone	Day-to-day client work from the same login

The last row deserves a second look. Whoever manages roles should not work client files from that login. Keep the administrator account separate and rarely used, so that every change made with it is deliberate and logged.

Data scope depends on an accurate hierarchy

"My reports" and "my team" only work if the reporting lines inside the system are right: who reports to whom, and who sits in which team. Three habits follow.

• Update the hierarchy before the permissions. An agent still filed under a former supervisor stays visible to that supervisor and invisible to the new one.
• Move ownership when the client moves. When a client passes from sales to retention after the first deposit (FTD), change the assigned owner on the record. Otherwise the client stays in the first agent's view and never appears in the second's.
• Grant "everyone" by name. Keep a list of who holds the widest scope on any module, and why. If that list keeps growing, the design needs another look.

Duties one person should not combine

Segregation of duties means a sensitive step is not started and finished by the same person. NIST SP 800-53, one of the most widely used catalogues of security controls, asks organisations to identify and document the duties that need separating, and to give each user only the access their tasks require: the principle of least privilege. In a brokerage, the conflicting pairs usually look like this:

1. Recording a manual deposit and approving it. Whoever makes the entry does not approve it. Our guide to deposit and withdrawal approvals covers this step in detail.
2. Editing a client's payout details and approving their withdrawal. Changing the destination and then approving a payout to it from the same login is the shortest route to internal fraud.
3. Bringing in a client and deciding their KYC. The agent benefits from an approval, so the agent does not make the call. The review itself is designed in our KYC review workflow guide.
4. Changing instrument settings and trading on a client's behalf. Adjusting a spread or leverage and then opening or amending a trade needs a second pair of eyes, or at least a regular after-the-fact review.
5. Managing roles and granting yourself access. Someone other than the person who made a role change should review it.

Small team, and one person covers two of these? Do not pretend the separation exists. Compensate with a written periodic review: each week the manager or owner reads through the manual deposits, approved withdrawals and role changes.

The permissions that deserve the most attention

Keep the number of people holding these rights small, and review them more often than anything else:

• Export with an "everyone" scope on any module that holds client data.
• Delete on leads, customers and transactions.
• Import, because it can change many records at once.
• Creating or editing trades on a client's behalf.
• Manual deposits and withdrawal approval.
• KYC decisions and access to identity documents.
• User and role management.

For each one, ask three things. Who holds it today, by name? When did they last use it? Does every use appear in the audit trail with the value before and after?

Joiners, movers and leavers

Most permission problems appear months after the roles were designed, when people change jobs. Fix three procedures in writing.

• Joiners. A written request from the desk manager stating role, team and supervisor, approved by someone other than the requester. Start from the standard role, and never add "temporary" rights without an end date.
• Movers. When someone moves from sales to retention, for example, remove the old role's rights before adding the new ones. Rights that pile up with every move are how a long-serving employee ends up with more access than their manager.
• Leavers. Deactivate the account on the last working day, reassign their leads and clients, and check what they exported in recent weeks. NIST SP 800-53 likewise expects accounts to be disabled when users are terminated or transferred.

Also ask how staff sign-in is protected: password rules, who may log in, and from which devices. That belongs in your security policy; the permission matrix alone does not cover it.

A fixed access review

Set a fixed date, monthly or quarterly depending on the size of your team, and ask the same questions every time:

1. Does every active account belong to someone still working in that role?
2. Who holds the "everyone" scope, export and delete? Do they still need them?
3. Which custom roles were created or changed since the last review, and by whom?
4. Does the audit trail show a large export, a change to payout details or a trade edit that nobody can explain?

Record the outcome: date, reviewer, what changed. When someone later asks how you control access to client data, those records are the answer.

What this guide does not cover

It does not cover infrastructure security (networks, devices, servers), HR policy and pre-employment screening, or any specific regulator's requirements. Nor does it restate the full set of CRM requirements; for those, see what a CRM for a forex brokerage must actually do.

Where QUANTIX fits

On the QUANTIX platform, permissions live in the CRM and back office, which shares one trading engine and one audit trail with the Trader Portal and the Admin Console. Specifically:

• A permission matrix of 19 modules × 6 actions (view, create, edit, delete, import, export) × 4 data scopes (mine, my reports, my team, all), laid over an employee hierarchy.
• Five ready-made roles (Administrator, Manager, Agent, Support Agent and Compliance Officer), plus roles you define yourself, such as one for finance or the dealing desk.
• Employees with titles, supervisors and an org chart. Navigation and buttons disappear when a role lacks the permission.
• Staff with the right permission can create or edit trades on a client's behalf from the customer record in the Brokerage CRM, and authorised staff record manual deposits from the record, as described under payments and operations.
• An audit trail of more than 70 event types with before-and-after values, filterable, exportable and shown on each customer record.
• Each brand is a separate tenant with its own users and data, managed from the Admin Console.

To be clear about scope: the platform does not currently offer two-factor authentication (2FA) or single sign-on (SSO) for staff accounts, so plan your password and device policy with that in mind. Role design and access reviews remain your firm's decisions. QUANTIX provides operations and compliance tooling; using it does not make a firm compliant or licensed.

To see the permission matrix mapped to your own team structure, book a private demo and bring your list of desks and who approves what today.