Skip to content
Back to blog
Compliance June 14, 2026 · By MEXAR Engineering

Access control your auditor will recognise

Regulators ask who can do what, and how you can prove it. Here is how MEXAR structures role-based access control so segregation of duties is fine-grained, least-privilege, and reviewable in version control.

When a central bank reviews a money-services operator, a recurring question is deceptively simple: who can do what, and can you prove it? Segregation of duties — the cashier who takes money cannot also approve the transaction — is a control regulators expect to see enforced, not just described in a policy document. MEXAR is built so that answer is concrete.

Roles grant permissions; permissions are granular

Access control runs on role-based access control (RBAC) via Laratrust. There are two simple primitives:

  • a Role — a named job, like cashier, seller, or accountant
  • a Permission — a fine-grained ability, like dpt.transaction.create

Users hold roles, roles grant permissions, and a user can additionally hold a direct permission when needed. The important part is the granularity: permission names follow a strict, readable pattern.

{scope}.{module}.{action}

The scope says whose data it touches — dpt. for a department operation, sys. for cross-department administration, user. for a person’s own resources. The module is the domain (transaction, cashier, report…). The action is the verb: list, view, create, edit, delete, export, and the one auditors like — audit. Sensitive domains add semantic actions instead of overloading “edit”: a transaction has distinct approve, cancel, revert, and assign permissions, and the cashier flow splits into receive.confirm, receive.reject, send.process, and send.complete.

That granularity is what makes segregation of duties real. “Can confirm an incoming payment” and “can approve a transaction” are different permissions, so they can sit with different people.

Least privilege by default

Roles are designed to grant the minimum a job needs. A cashier gets payment processing; an accountant gets reports and stock; a seller gets transaction management and customer views. Only root carries the wildcard *. Wildcards exist for convenience — dpt.cashier.* grants every cashier permission — but the guidance is to prefer explicit grants over broad ones.

Access is also layered with the department boundary: holding a permission is not enough on its own — a user must be a member of the relevant department, with an appropriate department role, and hold the permission. Where you are and what you may do are checked together.

Routes enforce this declaratively. A single permission guards an endpoint, and where two are required the check is explicit — for example, notification endpoints demand both dpt.notification.* and dpt.user.* together (AND), while other routes allow any of several (OR).

The part auditors appreciate: it lives in version control

Here is what turns “we have access controls” into “we can prove our access controls”: the entire policy is defined in version-controlled files, not clicked together in a forgotten admin screen. Permissions live in .jsonc definition files by scope (department.jsonc, global.jsonc, users.jsonc), and roles — with their granted permissions — live in roles.json:

{
    "name": "cashier",
    "display_name": "Cashier",
    "description": "Handles payment processing",
    "permissions": ["dpt.cashier.*", "dpt.transaction.view"]
}

A sync command (app:acl:diff) reconciles those files to the database in clear phases — create new permissions, remove orphaned ones, sync roles, then propagate each user’s combined permissions from their roles. Run it on deploy and the running system always matches the files in git.

The compliance payoff is direct: the answer to “who can approve a transaction?” is a diffable file with a full change history — who changed a role, when, and what it granted before. That is exactly the evidence a segregation-of-duties review asks for, available without screenshots or a manual audit.

Why it matters

Strong access control is table stakes for a regulated money business, but provable access control is the differentiator. By making permissions fine-grained, roles least-privilege, the department a hard boundary, and the whole policy reviewable in version control, MEXAR lets an operator walk into a regulatory review with the controls — and the paper trail — already in hand.