Role-Based Access Control for Money Transfer Operators: A Practical Design Guide

Most access problems in a money transfer business are not break-ins. They are a support agent who can still export the watch list, a rates analyst whose changes nobody checks, or a leaver whose account worked for three weeks after their last day. Each is a design failure, and each is the first thing an auditor asks about after something goes wrong.

This guide is for compliance heads, operations leads and CTOs deciding who can do what, and then showing that the decision is being followed. We show where RemitSo's admin panel helps: it gives you fine-grained controls and the records to prove them. Deciding who gets what, and running reviews, remains your team's job.

In role-based access control, permissions are attached to roles and people are given roles. When someone changes job, you change their role rather than hunting through individual settings.

Start with the permissions, the smallest units of action: see a transaction, approve a KYC document, change a rate, export a list, post a journal. Then group them into roles that match real jobs, not individuals.

• Least privilege. Each role gets what the job needs and nothing more.
• Few roles, clearly named. A 10 to 20 person operator rarely needs more than six to eight.
• Separate viewing from changing. Many people need to see a transaction; very few need to alter anything about it.

Least privilege is only practical if permissions are fine enough. If "compliance" is one switch, you give support too much or too little. RemitSo has 89 separate access controls, each described in plain language, so an administrator can grant exactly what a job needs. Roles group them, and a role can have a parent role, so a senior compliance role builds on the standard one instead of duplicating it.

Departments organise people by the work they own. RemitSo comes with seven pre-set: Senior Management and Board; Compliance; Customer Service and Onboarding; Payments and Treasury; Finance; Technology; Agents and Branch Staff.

Least privilege limits how much one person can do. Segregation of duties limits what one person can do alone. For money movement, the chain has three steps:

1. Create. Someone sets up a payout, a rate change, a new fee or a transfer review.
2. Approve. A different person checks it is correct and allowed.
3. Release. The approved item goes out exactly as approved.

Nobody approves their own work.

The third step is often overlooked. If recipient details can change after sign-off, the approval covered something other than what was paid. In RemitSo, payouts are locked once approved and never edited.

The same applies to the books. In RemitSo, reading the general ledger and entering a journal by hand are separate permissions. Finance, compliance and auditors can read everything, while only a named financial controller posts manually. Entries are never edited, only reversed with both left visible.

• Changing what flags a transfer. Watched names, watched email addresses, watched email domains and high-risk countries decide who gets a second look. In RemitSo each has its own rights to see, add, change, remove, import and export, so only compliance changes them and nobody can quietly export the watch list.
• Exporting personal data. Treat export as a separate right from viewing; support almost never needs it. Within a transaction, decide which fields each role needs: support can confirm a status without seeing account numbers.
• Editing exchange rates and fees. A wrong margin loses money on every transfer until someone notices. Limit to the rates desk, reviewed by someone else. Where automatic feeding (an optional add-on) is used, RemitSo also refuses a feed rate that moves beyond the configured guardrail and switches the feeder off, with an alert to its subscribers.
• Ruling on screening hits and KYC documents. Risky transfers wait for a person; that decision belongs with compliance.
• Pausing and resuming transaction processing. Useful during maintenance, incidents or compliance actions; disruptive in the wrong hands.
• Managing users and roles. Whoever can grant permissions can grant themselves anything. Keep this with an administrator who holds no money-moving permissions.

Screens deserve the same care. RemitSo grants some part by part: each group of Scout figures separately, so a payments role sees the machinery figures without the compliance queues; each part of the Compliance Dashboard separately, so a board member sees screening figures without the customer worklist.

A starting point for a typical operator. Rows follow RemitSo's permission areas; where your platform splits view and change rights, keep the same split. Keep the final version as a controlled document: an auditor will compare it with your live configuration.

The choices are deliberate. The administrator manages users and roles but cannot move money, change what flags a transfer or see customer data. Compliance sees who holds which role but cannot change it, and alone can change or export the watch lists. Support sees KYC documents to help customers but cannot rule on them. Finance reads the whole ledger; only the controller posts by hand.

If your platform combines two rights, such as viewing and exporting, note it in your access policy and add a compensating review.

Role design assumes the person using an account is its owner. Passwords are reused, phished and shared. Two-step sign-in, a code from an authenticator app or sent by email, closes most of that gap. In RemitSo each user is given an MFA method alongside their roles.

• No exceptions for seniority. Directors and administrators hold the most powerful accounts. Enrol them first.
• Prefer an authenticator app for approval or admin permissions. A compromised mailbox puts both email factors in one place.
• No shared accounts. A shared login makes every record resolve to a team, not a person.

Then check the policy holds. RemitSo logs every staff and customer sign-in with time, IP address, city, country, client app, operating system and whether MFA was completed, and you can filter to sessions where it wasn't. That is evidence for auditors and early warning of account misuse.

Joiners. Assign role and department when the account is created, so the person starts with the intended access. The line manager requests it; someone other than the administrator approves. In RemitSo, requests for a console account wait for a decision, showing request type, originating device and IP, and expiry, so there are no shadow accounts.

Give approval permissions only after required training is signed off. A department sets who must complete a training, and its head is told when someone falls behind, so accountability sits with the team that owns the work.

Movers. The most common source of excess access. Remove the old role when you add the new one; never stack them without an end date.

Leavers. Act on the last working day; for a difficult exit, before the conversation. RemitSo users can be suspended or deactivated rather than deleted, so past actions stay attributable. Switching a department off keeps its membership and history.

Review all accounts at least annually, and sensitive permissions (watch lists, rates, fees, exports, manual journals, user management) quarterly.

1. Pull the current list of accounts, roles and departments from the live system, not a spreadsheet.
2. Find dormant accounts. RemitSo shows each user's last sign-in and last password change, so an account unused for 90 days stands out. Suspend it unless someone can justify it.
3. Send each manager their team's list to confirm, change or remove.
4. Check sensitive roles separately, including whether anyone holds two steps of the same chain.
5. Record the decisions, reviewer and date. The record is the evidence.

Nobody reviews their own access. Include AI tools too: in RemitSo, where the AI assistant (an optional add-on) is licensed, a staff member can connect it with a personal access token to look up and diagnose transfers and customers. It sees only what that person can see and never receives personal data, so your role design carries over to AI use.

Access control has two halves: preventing what should not happen and proving what did. An auditor wants to see that a control exists, that it applied to a named person, and that someone reviewed the results: who did it, when, what it was before and after. Without the "before", you know a rate changed but not by how much.

In RemitSo, the records that answer those questions are:

• A searchable, plain-language audit log: who changed what, and when, filterable and readable without an engineer. Every override of an AML limit is recorded in it.
• Login sessions: every sign-in with location, app, operating system and MFA status.
• Rate history: the full history of exchange rates, to check any change against the pricing decision behind it.
• Screening decisions: sanction lookup shows every screening, what it matched and what an officer decided about each match.
• KYC decisions: customer and recipient documents approved or rejected, with rejection labels.
• AI assistant question log (where the optional AI assistant add-on is used): every question an assistant asks on a staff member's behalf.

Use them actively: review rate changes and MFA-incomplete sessions on a schedule, and sample screening rulings and KYC rejections monthly. See also why audit logs are critical for remittance compliance and how to build a compliance dashboard.

The details are illustrative, not drawn from any real operator.

Monday. A request for the watched-names list reaches a support agent. The agent's role can see KYC documents but holds no rights on watched names, so there is nothing to export. The request goes to compliance, who decide what, if anything, can be shared.

Wednesday. The compliance officer filters login sessions to those where MFA wasn't completed. One stands out: a finance account, a country where nobody on the team works, an unfamiliar operating system. The account is suspended, the password reset and an authenticator app enrolled. Because it held ledger read rights but not manual journal rights, nothing could have been posted.

Friday. The rates desk changed one corridor's margin midweek. In the weekly review, the finance lead opens the rate history, compares old and new rates with the analyst's pricing note and records the review.

1. An approved role-to-permission matrix matches the live configuration.
2. Every member of staff has a named account; no shared logins.
3. Two-step sign-in is enforced for everyone, and MFA-incomplete sessions are reviewed.
4. Nobody approves their own payouts, refunds, rate changes or screening rulings.
5. Approved payouts are locked and never edited.
6. Only compliance can change or export watched names, emails, domains and high-risk countries.
7. Reading the ledger and posting manual journals sit with different people.
8. The person who manages users holds no money-moving permissions.
9. Leavers were suspended or deactivated on their last day; accounts unused for 90 days are justified or suspended.
10. The latest access review is recorded, with decisions, reviewer and date.
11. Staff with approval permissions have training signed off by someone else.

RemitSo's admin panel turns these controls into settings you can grant, check and prove. See the admin features.

• 89 plain-language access controls, grouped into roles with parent roles: least privilege becomes practical.
• Access granted deliberately: around a hundred console pages and actions require a permission, and new permissions reach nobody until granted, so a new screen does not quietly open to everyone.
• Transaction details granted field by field: support sees what it needs to answer a customer without the fields it does not.
• Screens granted part by part: Scout figure groups and Compliance Dashboard parts, so people see the overview without someone else's customer data.
• Separate see, add, change, remove, import and export rights on watch lists: only compliance changes what flags a transfer.
• Ledger reading separate from manual journals: finance sees everything; a named controller posts by hand.
• Login sessions with location, app and MFA status, and a searchable, plain-language audit log of who changed what, and when: audit evidence and early warning of misuse.
• Rate-limited codes: sign-in, sign-up and verification codes are rate-limited in the apps and the console, which blunts guessing and code-flooding attacks.
• Account requests, suspension, last sign-in and password change: fast joiners and leavers, no shadow accounts.
• Departments that own training, with the staff training programme as an optional add-on: heads hear when someone falls behind, and nobody signs off their own. Every staff member can see and complete their own training.
• AI assistant access that follows the user's rights, an optional add-on: no personal data sent, every question logged.

Your team still decides who gets which role, runs the reviews and acts on the alerts.

Read the release notes, or book a demo to walk through roles and permissions with your own team structure in mind.