Maker/checker, authorization and audit trail
The governance layer determines who can perform which actions in the system and how every operation is recorded. In TruvaLI, no decision goes live without a second approval, and every access is converted into an immutable record.
Maker/checker
Authorization groups are defined by the institution. When a compliance specialist (maker) writes a rule or closes a case, the action does not take effect until it is approved by the pre-authorized approver pool (checker). As soon as approval is granted, a secure callback is sent to your core system.
This structure automatically answers the most frequently asked questions in audits: who wrote the rule, who approved it, and who closed the case.
Segregation of duties
Developer, system administrator, and business user roles are separated from each other. A role does not have access to permissions it does not need to perform its own job. In institutions with multiple platforms or subsidiaries, each department only sees its own data source, rules, and alerts.
Dynamic authorization
Permissions are defined at the screen, button, and data level, not just the module level. A user might view a screen but not be able to perform a specific action within it, or they may see certain fields in a masked format. Sensitive fields are partially hidden from unauthorized users.
Access security
- Mandatory two-step verification, which is also required for critical approval steps.
- Password complexity, reuse limits, and periodic renewal.
- Account and IP lockout upon repeated failed login attempts.
- Automatic termination of inactive sessions.
- Restricting access to approved IP ranges and devices.
Immutable audit trail
Every access and every change in the system is recorded. Records cannot be edited retroactively: the integrity of the archives is verified using hash values, and a legally valid timestamp is added to approvals.
Archiving data during the legal retention period is executed automatically.
Why does it matter?
An audit questions how a decision was made and whether it is traceable, rather than just whether the institution made the right decision. In the eyes of auditors, a correct decision without a written justification often amounts to the same thing as a decision never made.
What it delivers to the institution
- Ensuring no unauthorized changes go live.
- Proving who performed each action and when.
- Granting permissions strictly on a need-to-know basis.
- Eliminating audit preparation as a separate project.
Common questions
- Is maker/checker mandatory for every action?
- The institution determines which actions are subject to approval. Rule publishing and case closure are the two most commonly used steps: authorization groups and approval pools are defined according to the institution's own hierarchy.
- Can audit records be modified retroactively?
- No. Records are kept in an immutable format, and archive integrity is verified with hash values. A legally valid timestamp is added to approvals.
- How granular can authorization be configured?
- Down to the screen, button, and data level. A user may view a screen but not perform a specific action within it: sensitive fields can be displayed with masking.
- We have multiple subsidiaries, can we segregate the data?
- Yes. Data sources are managed independently, and each department only sees its own source, rule set, and alerts.