Skip to content

Roles and controls

RoleDoes
MakerRecords and proposes: reviews, adjudications, decisions
CheckerChecks and signs what the maker proposed
ApproverSenior management approval where the route requires it
Compliance OfficerRegulatory work, follow-ups and filings
Head of ComplianceApproves filings; AMLO contact person
Risk ManagerRisk reference data and risk settings
Internal AuditReads everything, changes nothing
System AdminThe institution’s access and sign-in records

User accounts, roles and institutions are set by the platform operator. Every change of access is recorded with an approval reference, an effective date and a reason.

A decision that carries responsibility is proposed by one person and signed by another. The route, whether checker only or checker then approver, is shown before the maker confirms. The same person cannot sign their own proposal.

Everyone sees who holds a piece of work. Unclaimed work can be opened straight from the list by an officer with the right role.

Control layersEvery request passes four layers: screens by role and licence, database functions that check the role before any write, row-level security that separates each institution, and the audit trail.LAYER 1ScreensMenus and screens follow the user's role and the institution's licencesLAYER 2Database functionsEvery write checks the role first · the maker records, the checker signsLAYER 3Row-level securityOn every business table · each institution sees only its own rowsLAYER 4Audit trailActions · sign-offs · sign-ins · imports · delete guardsEVERY REQUEST
Hiding a menu is never the only control: the database refuses what the role may not do.
  • Screens show what the user’s role and the institution’s licences allow.
  • Database functions carry every write, and each one checks the role first.
  • Row-level security is on for every business table. Each user reads only their institution’s rows, as their role allows.
  • Audit trail: actions, sign-offs, sign-ins and sign-outs, import runs and contacts with outside parties are all logged. Records under retention cannot be deleted or edited.

Roles that can open a customer file see every field in full, because each of them works as the institution’s data controller. Exports from reference registers carry the exporter’s name and the time in the file header.

Cycles, deadlines, thresholds and sign-out time are controlled values. Each has an owner, a range the database enforces and a history. Changing one goes through sign-off, and the in-app manual always prints the values in force.