Skip to main content
The Loan Origination System keeps a tamper-evident record of every action taken in your credit union workspace. The audit trail is a legal-grade record. It cannot be modified or deleted. It is the source of truth for regulatory inquiries, internal investigations, and dispute resolution.

​
What the audit trail records

Every meaningful event is captured automatically. Recording is always on. There is nothing to configure.

Loan lifecycle events

Every loan state change is logged with full before and after context. That includes application submitted, adjudication decision recorded, securities resolved, and disbursement executed.

Member and document activity

Every member record update, document upload, and identity verification attempt is recorded, including the actor who performed it and when.

Access and authentication

Every login, logout, failed login, and permission-denied event is captured, and the session ID is recorded whenever the action came from an authenticated session.

Configuration changes

Every change to rates, workflow configuration, user roles, and workspace settings is logged, including who made the change and its previous value.

​
Non-repudiation: who did what

Every audit entry captures a complete picture of the actor at the exact moment of the action. There is no ambiguity about who performed an action, under what authority, and from where. Each entry records:
  • Actor identity: the user’s ID. The viewer resolves that ID to the current name and email when you open an entry, so the immutable record always points at exactly one person.
  • Role at the time: the role the user held when they performed the action. This is a snapshot, so later role changes do not affect historical records.
  • Capabilities at the time: the exact permissions the user held at that moment
  • IP address: the network address the request came from
  • User agent: the browser or client used
  • Authentication method: how the user authenticated, recorded as password for staff actions or system for platform-initiated actions
  • MFA status: whether multi-factor authentication was satisfied for that session
  • Session and request IDs: for cross-referencing with other systems

​
Accessing the audit viewer

Viewing the audit trail requires the reports.view capability. The seeded Administrator, Credit Manager, and Branch Manager roles all carry it, so all three see the full workspace-wide audit trail. A role that holds only loans.read.branch (and not reports.view) gets a narrower view, scoped to the events for its assigned branch. Operational roles, including Credit Officer, Adjudicator, Securities, and Disbursement, hold neither capability and cannot open the audit trail in this release.The Audit log link in the navigation is gated separately on the audit.export capability, which only the Administrator role holds. A Credit Manager or Branch Manager does not see the nav link, but they can still reach the page by visiting /admin/audit-viewer directly, where reports.view grants them the same workspace-wide view.
1

Open the Audit log

In the navigation, under Administration, click Audit log. The page header reads Audit trail, and you will see the trail for your entire credit union workspace, with the most recent events at the top.
2

Apply filters to narrow the results

Use the filter bar to search by resource, actor, action type, or time range. The four search patterns are described below.
3

Click any row to expand it

Click any audit entry row to see the actor name and email, role, IP address, sequence number, request and trace IDs, the decision rationale for adjudication events, and the full event payload JSON.

​
Four ways to search the audit trail

Select a Resource type from the dropdown, such as LoanApplication or Member, and enter the resource’s ID in the Resource ID field. This returns every event that touched that specific record.Example: To reconstruct the complete history of a loan application for a regulatory inquiry, select LoanApplication and enter the Loan ID. You will see every state change, decision, document upload, and access event for that loan in chronological order.
Enter a staff member’s name, email address, or user ID in the Actor field. The platform returns every action that person performed across the workspace during the selected time range.Example: If a staff member’s credentials may have been compromised, search by their user ID to review every action taken under their account.
Use the Event type dropdown to filter by a specific event name. The dropdown lists every event type the platform can emit, so you can search for an event even before it has occurred in your workspace.Common event types include:
  • loan_application.submitted
  • adjudication.decision.recorded
  • disbursement.executed
  • member.updated
  • permission.denied
  • audit.exported
Set a From and To date and time to restrict results to a specific window. Combine it with other filters. For example, you can pull all adjudication.decision.recorded events in the past calendar year to produce a focused record for a regulatory inquiry.
The Request ID and Trace ID are shown read-only when you expand an entry row, so you can correlate an event with the application logs. They are not searchable filters in this release.
Use the time-range filter together with a specific Loan ID to reconstruct the complete history of a loan application. Select the LoanApplication resource type, enter the Loan ID, and set the date range to cover the application period. You will see every event from submission to disbursement in a single view.

​
Quick CSV or JSON export

The audit trail offers a fast, lightweight export of whatever you are currently looking at. Apply your filters, then export the visible rows to a spreadsheet-ready CSV file or a pretty-printed JSON file straight from the toolbar. The quick export is built for day-to-day work, not for regulators:
  • It writes plain CSV (RFC 4180, with a UTF-8 byte-order mark so Excel opens it cleanly) or pretty-printed JSON.
  • It is capped at 1,000 rows. If your filtered view is larger, the file holds the first 1,000 rows and the download flags that it was truncated.
  • It carries no digital signature, no hash-chain proof, and no immutable cloud copy. For a record that a regulator can verify offline, generate a compliance export bundle instead.
The quick export honors the same scope as the trail itself, so you can only export rows you are already permitted to see. Every quick export is itself recorded as an audit.exported event whose payload carries source: quick-export, so the export is part of the trail it came from.

​
Hash-chain integrity

The audit log is hash-chained. Each entry stores a SHA-256 cryptographic hash that links it to the previous entry. This means:
  • If anyone modifies, deletes, or reorders any audit entry, even a single character, the chain breaks at that point and every subsequent entry becomes invalid.
  • The break is detectable automatically. A chain-integrity job runs every hour and alerts immediately if the chain is broken, naming the exact failure: a payload hash mismatch, a broken link to the previous entry, or a chain hash mismatch.
  • Every hour, the latest chain state is committed as a signed anchor. Once a day, at 4 AM UTC, those anchors are pushed to external immutable cloud storage with compliance-mode object lock and a 7-year retention lock. The push is RSA-SHA256 signed. Even an attacker with direct database access cannot rewrite history without breaking the external anchors.
The audit log is not just protected by application-layer access controls. It is mathematically verifiable.
The audit log is append-only and cannot be modified or deleted. This is enforced at the storage level by a Postgres trigger that blocks UPDATE and DELETE. It is not merely an application-layer restriction. No platform interface or administrative action can alter or remove an existing audit entry.
To provide a cryptographically-signed, verifiable record to regulators or auditors, use the Compliance Export feature.