> ## Documentation Index
> Fetch the complete documentation index at: https://docs.compuzign.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Roles and permissions for credit union staff
> Understand the built-in roles, what each role can do, which department they belong to, and how permissions are assigned per credit union.
The Loan Origination System uses role-based access control. Every user holds exactly one role within a workspace, and that role determines which pages, queues, and actions are available to you. Roles are configured per credit union, so the same person could hold a **Credit Officer** role in one workspace and an **Adjudicator** role in another.
Roles are assigned by your **Administrator** or your **HR** team. If you need access to a feature that is not available to you, contact them to discuss a role change.
## Built-in roles
Captures new loan applications and manages the member relationship at intake. Can search, create, and edit member records, submit KYC information, add or remove guarantors and their supporting documents, and submit completed applications for adjudication. Sees only their own loans.
Reviews submitted loan applications and makes credit decisions. Can approve, decline, or request additional information. Has read access to all loans across all branches, can claim unassigned loans from the team queue, and can transition loans through workflow stages.
Reviews and resolves collateral documentation attached to a loan. Can raise security requests and review and fulfil them, ensuring all pledged assets are properly documented before disbursement proceeds. Can claim unassigned securities work from the team queue.
Executes approved loans by scheduling and releasing funds. Manages the payee directory used to route payments. Can claim unassigned disbursement work from the team queue, and is responsible for confirming that disbursement instructions are complete and accurate before funds leave the credit union.
Oversees lending operations across all branches. Can view all loans regardless of branch, assign or reassign loans to officers, manage the loan product catalogue, publish updated rate tables, edit the standing fee schedule, apply manual rate overrides on individual loans, and access analytics and reports. The manual rate override (`loans.override`) is a Credit Manager lever that Adjudicators deliberately do not hold, keeping pricing separate from the approve or decline decision.
Manages lending activity within their branch. Can view all loans in their branch, assign loans to officers within that branch, and view branch-level reports.
Administers the workspace. Manages users, invitations, roles, branding, loan products, rate tables, the fee schedule, and all workspace configuration, and can run the full loan capture flow. Alongside the HR role, it invites new staff and changes role assignments; unlike HR, it also suspends members, manages lending configuration, and runs the loan capture flow. It does not adjudicate loans, review securities, or disburse funds. Those stages belong to the Adjudicator, Securities, and Disbursement roles.
Handles workspace staff administration. Invites new team members, assigns and changes their roles, and deactivates departing accounts, the same user management an Administrator does. HR is deliberately walled off from lending: it cannot open member records, view or decide loans, or move funds. Keeping the person who provisions accounts away from money and member data is a segregation-of-duties safeguard your regulator expects.
A front-desk lookup role with the lightest footprint. Staff can search the member directory to confirm a member's branch and status, and nothing more. They never see contact or demographic details, never see the sensitive identifiers such as TRN, licence, or bank account, and hold no loan, disbursement, or administration access.
## Role capabilities at a glance
The table below summarises what each role is permitted to do.
| Action | Credit Officer | Adjudicator | Securities | Disbursement | Credit Manager | Branch Manager | Administrator |
| ------------------------------------------------------------- | :------------: | :---------: | :--------: | :----------: | :------------: | :------------: | :-----------: |
| Create and edit loan applications | ✓ | | | | | | ✓ |
| Submit loan for adjudication | ✓ | | | | | | ✓ |
| Adjudicate (approve or decline) loans | | ✓ | | | | | |
| View own loans | ✓ | | | | | | |
| View all loans (all branches) | | ✓ | ✓ | ✓ | ✓ | | ✓ |
| View branch loans | | | | | | ✓ | |
| Claim loans from team queue | | ✓ | ✓ | ✓ | | | ✓ |
| Assign or reassign loans to officers | | | | | ✓ | ✓ | ✓ |
| Upload a loan-migration batch | ✓ | | | | ✓ | ✓ | ✓ |
| Review and reconcile a migration batch | ✓ | | | | ✓ | ✓ | ✓ |
| Sign off, commit, or void a migration batch | ✓ | | | | ✓ | ✓ | ✓ |
| Review and resolve securities | | | ✓ | | | | |
| Disburse funds | | | | ✓ | | | |
| Run AML or sanctions screening | | | | ✓ | | | |
| Advance settlement status | | | | ✓ | | | |
| Reverse a disbursement | | | | ✓ | | | |
| Approve a held disbursement (maker-checker) | | | | | ✓ | | |
| Configure disbursement controls | | | | | ✓ | | |
| Manage payee directory | | | | ✓ | ✓ | | |
| Record or adjust loan collateral | | | ✓ | ✓ | ✓ | | ✓ |
| Place or release a security hold (lien) on a member's account | | | ✓ | ✓ | ✓ | | ✓ |
| View security holds on a loan | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| View and search member records | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Create and edit member records | ✓ | | | | | | ✓ |
| Submit member KYC | ✓ | | | | | | ✓ |
| View guarantor documents | ✓ | ✓ | ✓ | ✓ | | | ✓ |
| Upload guarantor documents | ✓ | | ✓ | | | | ✓ |
| Remove guarantor documents | ✓ | | | | | | ✓ |
| Prepare a loan legal document | ✓ | | ✓ | ✓ | | | ✓ |
| Upload a signed legal document | ✓ | | ✓ | ✓ | | | ✓ |
| View loan legal documents | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Void a loan legal document | | ✓ | | | ✓ | | ✓ |
| Manage document templates | | | | | ✓ | | ✓ |
| Manage loan products and rate tables | | | | | ✓ | | ✓ |
| Manage fee schedule and its General Ledger accounts | | | | | ✓ | | ✓ |
| Change the Mandatory Shares policy | | | | | | | ✓ |
| View reports and analytics | | | | | ✓ | ✓ | ✓ |
| Invite staff and manage roles | | | | | | | ✓ |
| Workspace configuration and branding | | | | | | | ✓ |
The Administrator runs the loan capture flow and sees every loan through its all-loans read, but it holds none of the adjudication (`loans.adjudicate`), securities (`securities.review`), disbursement (`loans.disburse`), or payee-directory (`disbursements.payees.manage`) capabilities. Five roles see loans across all branches through `loans.read.all`: the Adjudicator, Securities, Disbursement, Credit Manager, and Administrator. That all-branches read is a superset of the branch-scoped view. Only the Branch Manager holds the branch-scoped `loans.read.branch`.
**Disbursement controls split the work across two roles on purpose.** The Disbursement officer is the maker: they screen payees for AML and sanctions (`disbursements.screen`), advance the settlement status (`disbursements.settlement.update`), and reverse a released disbursement (`disbursements.reverse`). The Credit Manager is the checker: they approve a held disbursement (`disbursements.approve`) and configure the control thresholds (`admin.disbursement.config`). Keeping approval out of the Disbursement officer's hands means the person who releases funds is never the only person who signs off, so maker is never checker. See [Disbursement controls](/disbursement/controls) and [Settlement](/disbursement/settlement).
**Recording collateral and holding a member's own funds sit with the securing and disbursing roles.** Recording or adjusting the collateral on a loan, and placing or releasing a **security hold (a lien)** on a member's shares or savings, are held by the **Securities** officer, the **Disbursement** officer, the **Credit Manager**, and the **Administrator**. A hold ring-fences the member's pledged funds so they cannot be withdrawn while the loan is outstanding, and it is released when the loan settles. The **Credit Officer**, the **Adjudicator**, and the **Branch Manager** can view a loan's holds but cannot place or release one, and the **HR** and **Staff** roles hold none of this. A hold stays visible on the member's own profile for as long as it is in force.
**Guarantor documents follow the same access as member documents.** The three guarantor-document capabilities, `loans.guarantors.documents.view`, `loans.guarantors.documents.upload`, and `loans.guarantors.documents.delete`, are granted to exactly the same roles that hold the matching `members.documents.*` capability. So the Credit Officer, Adjudicator, Securities, Disbursement, and Administrator can view a guarantor's ID, income, and employment files; the Credit Officer, Securities, and Administrator can upload them; and the Credit Officer and Administrator can remove them. A reviewer who can open a member's file can open the guarantor's file on the same loan, and no wider.
**Editing the fee schedule is held by the Credit Manager and the Administrator** through the `fees.manage` capability. A Branch Manager does not hold it. This is the standing fee catalogue, the processing fee, legal, valuation, stamp duty, and the rest, that pre-fills every disbursement. A Disbursement officer still waives or adjusts a single loan's fees at funding, but the catalogue itself is a manager-level setting. The same two roles also set the **General Ledger account** each fee posts to on the disbursement sheet, so a fee books to the right account and the double entry stays balanced. See [Edit the fee schedule](/admin/fee-schedule).
**Changing the Mandatory Shares policy is reserved for the Systems Administrator.** The Mandatory Shares figure is the flat share amount a member must hold, set once for the whole workspace. Only the **Administrator**, your Systems Administrator, can change it. It is deliberately not delegated to the Credit Manager the way the fee schedule is. The separate **Minimum Shares** percentage, which can differ by loan product, is a per-product lending setting changed with the rest of your loan configuration.
**Legal documents split preparing from reversing.** The stage operators prepare and file the documents for their own stage: a **Credit Officer** handles the draft-stage consent and declaration, **Securities** handles the guarantee and the security agreement, and **Disbursement** handles the disbursement sheet, all through `loans.legal_documents.prepare` and `loans.legal_documents.execute`. Voiding a prepared or executed document is a supervisory control (`loans.legal_documents.void`) held by the **Adjudicator**, the **Credit Manager**, and the **Administrator**, so the person who prepares a document is never the one who reverses it. Everyone in the loan's pipeline can view legal documents (`loans.legal_documents.view`). The template catalogue itself (`documents.templates.manage`) is a Credit Manager and Administrator setting, alongside products, rates, and fees. See [Legal documents](/legal-documents/overview) and [Document templates](/legal-documents/templates).
**Loan migration is open to four roles, and sign-off is optional.** Bringing your existing loan book onto the platform uses three capabilities: `loans.import.upload` to upload and stage a workbook, `loans.import.review` to review, attribute, and reconcile the staged loans, and `loans.import.signoff` to record the sign-off, commit a batch, and void one. All three are held by the **Credit Officer**, the **Credit Manager**, the **Branch Manager**, and the **Administrator**, and no other role holds any of them. There is no maker-checker on import: anyone with migration access can commit the ready loans, with or without a recorded sign-off first. That dual-control separation exists only on the live disbursement path, where money actually moves, not on migration. A former officer who is no longer on staff is recorded as a **historical actor**: they appear in the attribution picker so migrated work is credited to them, but never in the assignment picker, and they cannot sign in. See [Loan migration](/migration/overview).
## HR and Staff
The lending roles above all work loans and member records. Two more roles sit outside that flow: one runs staff administration, the other is a light front-desk lookup. Both are walled off from lending and member data by design.
The **HR** role does the same user administration an Administrator does, and nothing else. HR invites and manages staff accounts and assigns their roles, so a credit union can hand employee onboarding and offboarding to its people team without also handing over member records or the ability to move money. This separation is deliberate. Because HR grants roles, letting HR also approve disbursements or read member files would give one person both sides of a sensitive action, so those capabilities are kept out of HR entirely.
The **Staff** role is the least-privilege front-desk lookup. Its only access is a masked member directory: search for a member and see their name, member number, branch, and active or suspended status. That is enough to confirm you are talking to the right member and route them to the right person. It never reveals contact details, dates of birth, employment, next of kin, or the encrypted identifiers, and it holds no create, edit, loan, disbursement, or administration power.
| Action | HR | Staff |
| ---------------------------------------------------------------------- | :-: | :---: |
| Invite staff and manage their roles | ✓ | |
| Deactivate a departing staff account | ✓ | |
| Look up members in the masked directory (name, number, branch, status) | | ✓ |
| Open a full member record or reveal sensitive details | | |
| View, decide, or work on loans | | |
| Screen, approve, or release disbursements | | |
| View reports, analytics, or the audit log | | |
| Change workspace or lending configuration | | |
**HR provisions accounts but never touches money or member data.** This is segregation of duties. The role that can assign other people's roles is deliberately blocked from disbursement approval and from reading member records, so no single person can both grant themselves a path and use it. The Administrator remains the all-in-one workspace owner; HR is the narrower, staff-only administrator.
## How roles are assigned
Roles are chosen at the point of invitation. When an **Administrator** or an **HR** user sends an invitation, they select the appropriate role before the email is sent. The new team member joins with that role active from their very first sign-in.
Each user holds exactly one role per workspace. If someone's responsibilities change, an Administrator or HR updates the role at any time from **Administration → Team & roles**. A **Credit Officer** promoted to **Credit Manager** is one example. Changing the role replaces the previous one rather than adding a second, and the new role takes effect on the user's next page load.
The **Administration → Team & roles** page also shows a per-role permissions panel, so an administrator can see exactly which capabilities each role in the workspace holds, including the HR and Staff roles.
## Capability stacking
Some actions require more than one capability to line up before they succeed. Capability stacking enforces separation of duties: gaining one capability is never enough on its own to perform a sensitive action, which keeps a single role misconfiguration from opening up sensitive actions unexpectedly.
Submitting a loan for adjudication moves it from DRAFT to SUBMITTED, and that transition stacks three capabilities plus a data check:
1. **`workflows.transition`**, the global workflow engine gate.
2. **`loans.transition`**, the loan-domain gate.
3. **`loans.submit`**, the per-transition capability, granted to **Credit Officers** and **Administrators**.
4. **The member's KYC is Verified.** The member's `kycStatus` must equal `VERIFIED` before submission is allowed.
If any capability or the KYC check is missing, the **Submit** button is hidden or the action is rejected, and the platform shows a clear message about what still needs to be completed.
Moving a loan from one stage to the next, for example from **Approved** to **Securities**, requires three layers:
1. **`workflows.transition`**, the global workflow engine gate.
2. **`loans.transition`**, the loan-domain gate, which ensures the transition request is for a loan workflow and not another workflow type.
3. **The per-transition capability** for that specific move. The adjudication moves and the moves into and through the securities stage (including **Approved** to **Securities**) require `loans.adjudicate`. The moves that return a loan from **Securities** back to **Draft** or **Adjudication** require `securities.review`, and the disbursement moves require `loans.disburse`.
All three must be present. This layered approach means that gaining access to one capability alone is never enough to perform a sensitive action.
These stacking rules are enforced automatically. The Submit or transition action is hidden, or rejected by the server, whenever any required capability is missing, which is why an action can be unavailable even when your role looks correct.