Audit Trail, RBAC and Security in a Lending Platform

How a workplace-banking platform stays defensible and secure — an immutable audit trail, role-based access control with ten lending roles, maker-checker separation, and the session, CSRF and inter-service protections behind it.

When a regulated lender processes an unsecured check-off loan, the loan itself is only half of what matters. The other half is the evidence: who did what, when they did it, what authority they held to do it, and whether anyone could quietly change the record afterwards. For a bank, a SACCO or a microfinance bank, that evidence is what makes a lending decision defensible to an internal auditor, a board credit committee or the regulator. A workplace-banking origination platform therefore has to treat the trust layer — auditing, access control and security — as first-class infrastructure rather than an afterthought bolted onto the loan workflow. This article walks through how that trust layer is built in the Workplace Banking (WPB) platform: an immutable audit log, a role-based access model spanning ten lending roles and twenty-one permissions, maker-checker separation at the database level, and the session, request and inter-service controls underneath. Throughout, the framing is deliberate. WPB is built as an audit-ready architecture designed around SOC 2 and GDPR-aligned controls; it is not a certification claim, and nothing here should be read as one.

An immutable audit trail you cannot quietly rewrite

The foundation of the trust layer is the audit log, and its single most important property is that it cannot be altered after the fact. WPB's dedicated Auditing microservice writes to an audit_log table in PostgreSQL that is protected by a database trigger preventing any UPDATE or DELETE statement from succeeding. This is not a permission that an administrator can toggle off from an application screen — it is enforced in the database engine itself. The practical effect is that even a user with elevated rights, or a compromised service account, cannot reach into the history and edit an entry, soften a decline reason or remove a record that has become inconvenient. The log is append-only by construction.

Equally important is how entries get there in the first place. The audit trail is not populated by developers remembering to call a logging function at each point in the code. Instead, the Auditing service runs a queue consumer that listens to workflow events on the messaging backbone — RabbitMQ on-premises or Azure Service Bus in the cloud — and writes an audit entry automatically as each event occurs. Because the loan workflow publishes events as applications move between stages and decisions are taken, the audit record is a near-complete shadow of everything that happened to a loan. That decoupling matters: the record is generated as a side effect of the work, not as a discretionary step a busy officer might skip.

For day-to-day use and for examinations, the captured history has to be retrievable. The audit log is filterable and paginated, so a reviewer can narrow the trail to a single application, a date range, an actor or an event type without scrolling through the entire institution's activity. The combination — automatic capture, append-only storage, and structured retrieval — is what lets an institution answer the auditor's recurring question with confidence: show me, end to end, exactly what happened on this loan and who touched it.

Role-based access control: ten roles, twenty-one permissions

If the audit log answers "what happened", role-based access control (RBAC) governs "who is allowed to do it". WPB's Authorization microservice defines ten lending roles and twenty-one discrete permissions, and access is enforced not in the abstract but at the level of the individual workflow stage. A user can only take the actions their role is authorised to take, at the stages where that role is expected to act. The ten roles map directly onto the real division of labour in a workplace-lending operation:

Two design choices in this model are worth drawing out. First, the authority to approve a loan is deliberately scarce — only the Credit Analyst and the Credit Approver can take the Approve action, while sales and administrative roles are confined to comment, forward, return and decline actions appropriate to their stage. Second, the separation between the Credit Admin Inputter and the Credit Admin Verifier is not a convention or a training expectation; it is a structural split that underpins maker-checker, discussed next. Because permissions are bound to stages, the workflow and the access model reinforce each other: an application sitting at credit analysis simply cannot be approved by a sales officer, regardless of intent, and the audit log records every authorised action against the role that performed it.

Maker-checker enforced where it counts

Four-eyes control — one person prepares an action, a different person verifies and releases it — is a standard expectation in banking, but expectations are only as good as their enforcement. WPB enforces maker-checker at the most sensitive point in the process, disbursement, and it does so with a database constraint rather than application logic alone. The Disbursement service requires that the inputter and the verifier of a disbursement are different users, and that requirement is encoded as a constraint in the database. An attempt to have the same user both input and verify is rejected at the data layer, which means it cannot be bypassed by a UI quirk, a direct API call or a misconfigured screen.

This is the difference between a policy and a guarantee. A policy that says "the same person must not approve their own disbursement" depends on everyone following it; a database constraint makes the prohibited state impossible to record. The mechanics of how the maker prepares a loan booking and disbursement, and how the verifier releases it — including RTGS and bankers-cheque settlement paths — are covered in detail in our companion article on maker-checker in loan disbursement. For the purposes of the trust layer, the point is that the most consequential financial action in the lifecycle is protected by separation of duties that the system itself will not let you break.

Session, request and inter-service security

The audit trail and the access model assume that the identity behind each action is genuine and that requests cannot be forged or intercepted. WPB's portal is a Next.js application that acts as a backend-for-frontend (BFF), and several controls sit around it to protect the session and the traffic between components.

• Encrypted session cookie. User sessions are held in an iron-session encrypted cookie (wpb-session) with an eight-hour time-to-live. The cookie is httpOnly, so client-side scripts cannot read it, and SameSite=Strict, which prevents the browser from attaching it to cross-site requests. The session is opaque to the browser and expires within a working day.
• CSRF protection. Cross-site request forgery is mitigated with a double-submit cookie pattern carrying an HMAC signature, so a state-changing request has to present a token that the server can verify rather than one an attacker could guess or replay from another origin.
• Inter-service authentication. The microservices authenticate to one another with an x-api-key header validated by an API-key middleware. Critically, the BFF proxy injects this key server-side, so the credential never reaches the browser. A user's machine never holds the keys that the services trust, which removes an entire class of credential-leakage risk from the client.
• Secret storage. The keys, connection strings and other secrets that make all of this work are kept in Kubernetes Secrets on-premises or in Azure Key Vault in the cloud — managed secret stores rather than configuration files checked into a repository or pasted into environment screens.

These controls are intentionally unglamorous, and that is the point. There is no native mobile application and no biometric layer to reason about — the portal is web only — so the attack surface to secure is a known, bounded one, and the protections are the well-understood, defensible primitives appropriate to it. For a fuller picture of how the platform connects to core banking and external bureaus behind these boundaries, see the overview of workplace-banking system integrations.

Audit-ready, by design — not a certification

It is worth being precise about what "audit-ready architecture" means and what it does not. WPB is engineered with the controls that compliance frameworks expect to see — separation of duties, least-privilege access, an immutable and complete activity record, encrypted sessions, managed secrets and a clean inter-service trust boundary. The architecture is designed to align with SOC 2 and GDPR-style control objectives, and the engineering is backed by a substantial automated test suite across the backend, frontend and end-to-end layers. None of that is the same as holding a certification. A SOC 2 attestation or an ISO 27001 certificate is the outcome of an independent audit of an operating organisation over time; it is awarded to a deploying institution's control environment, not pre-granted by a platform. What WPB provides is the technical groundwork that makes such an exercise tractable: when an auditor asks for evidence of access control, separation of duties or a tamper-resistant record, the platform can supply it. Institutions building or strengthening a formal compliance programme around this can draw on dedicated financial-crime compliance advisory to map the controls to their chosen framework.

This trust layer is one chapter of a larger story. To see how auditing, RBAC and maker-checker fit alongside affordability checks, compliance screening, the thirteen-stage workflow and disbursement, read the complete guide to workplace banking.

Frequently asked questions

Can audit records be edited or deleted?

No. The audit_log table in PostgreSQL is protected by a database trigger that blocks any UPDATE or DELETE operation, so entries are append-only once written. This protection lives in the database engine rather than in application settings, which means it cannot be switched off from a screen or circumvented by a user with elevated application rights. Entries are also written automatically by a queue consumer that listens to workflow events, rather than by a discretionary logging step, so the record captures activity as it happens. The result is a tamper-resistant, complete history that a reviewer can filter and page through when reconstructing exactly what occurred on a given loan.

What roles does the platform support?

The Authorization service defines ten roles spanning the lending lifecycle: Direct Sales Executive, Sales Manager, Sales Centre Compliance Analyst, Credit Analyst, Credit Approver, Scheme Loan Administrator, Credit Admin Inputter, Credit Admin Verifier, System Admin and Auditor. These are governed by twenty-one discrete permissions that are enforced at the level of each workflow stage, so a user can only take the actions their role is authorised to take at the stages where that role acts. The split is deliberate — for instance, only the Credit Analyst and Credit Approver may approve a loan, and the Credit Admin Inputter and Verifier are kept structurally separate to support maker-checker on disbursement.

Is the platform SOC 2 certified?

No, and it is important not to overstate this. WPB is built as an audit-ready architecture designed around SOC 2 and GDPR-aligned control objectives — separation of duties, least-privilege access, an immutable audit trail, encrypted sessions, CSRF protection and managed secret storage. A SOC 2 attestation, however, is the result of an independent audit of a deploying organisation's operating controls over time; it is earned by the institution that runs the platform, not pre-granted by the software. What the platform offers is the technical foundation that makes such an audit far more straightforward. You can explore the platform on the Workplace Banking product page or arrange a walkthrough of the audit, RBAC and security controls via a demo.