Access Control & Roles
Who can do what, and why neither role can do the other’s job.
1. The two roles
Ledger has exactly two roles. Every signed-in session belongs to one of them, and every request re-checks the role and the record’s ownership on the server — the interface hides what you cannot do, but the server is what enforces it.
Applicant
Can
- Start and complete their own onboarding application
- Add and verify their own documents
- See their own application status, review notes and audit record
- Use their own account dashboard and transaction history once approved
Cannot
- See any other applicant's data
- Review, approve or reject any application — including their own
- See the review queue, case files or the global audit log
Compliance reviewer
Can
- See the review queue and open any case file
- Override document verification states, with a written reason
- Approve, reject or request more information on submitted applications
- Read the global audit log across all applications
Cannot
- Edit an applicant's identity or business data
- Edit or delete anything in the audit log
- Approve a case with unverified documents or a confirmed screening hit
2. Separation of duties
The person who provides the data is never the person who judges it. Applicants cannot review any case, so no one can approve their own account. Reviewers cannot edit application data, so the case a reviewer decides on is exactly the case the applicant submitted. Where the two roles do touch the same record — a reviewer overriding a document state, or requesting more information — the action requires a written reason and is attributed to the reviewer in the audit log.
3. Append-only audit guarantee
The audit log is written once, by one door.
Audit events are created through a single code path and there is no code path anywhere in the system that updates or deletes one — not for applicants, not for reviewers, not for administrators. Each event records who acted, what happened, which state changed and when. If the underlying application is ever erased, the events survive it, unlinked.
4. Session security
- Sessions are carried in a signed cookie scoped to this application’s own path, so it is never sent to anything else on the same domain.
- The cookie is
httpOnly— scripts in the page cannot read it — and marked secure in production so it only travels over HTTPS. - Cross-site sending is restricted (
SameSite=Lax), which blunts cross-site request forgery. - Sessions expire after 7 days, and logging out clears the cookie immediately.
- Post-login redirects only accept internal paths, so a crafted link cannot bounce a signed-in user to another site.