Internal audit: tracing decisions back to their source
Internal audit looks at past decisions, not today's screens. TruvaLI stores the rule version, decision justification, approval chain, and access log alongside each event, eliminating the need to export data for sampling.
Internal audit independently tests whether an institution's own controls are working as designed. In money laundering and fraud controls, this testing cannot be done by looking at today's screen: the audit's question belongs to the past, and the answer must be stored exactly as it was on that day.
Why is explaining the past difficult?
Control systems are living systems. Rules change, thresholds are updated, team members come and go. Trying to explain a decision made six months ago using today's rule set yields incorrect results.
| Audit question | What should be in the log |
|---|---|
| Which rule evaluated this event? | The rule ID and its version at that moment |
| On what basis was the rule written at that time? | Rule definition and change history |
| Who made the decision, and who approved it? | Approval chain and authorization log |
| What was the initial decision, and did it change later? | Original decision and change log |
| Who accessed this data, and when? | Access log |
Storing the rule version alongside each event is the most critical item on this list: without it, the justification for a past decision cannot be reconstructed.
How is sampling conducted?
Auditing works through sampling: a set of cases from a specific period is selected and reviewed individually. It must be possible to retrieve this set from within the system using filters in a repeatable manner. Report definitions are created without code, results are saved, and the same definition can be run again in the next period. Details are on the automated reporting page.
When there is no need to export data for auditing, the audit itself does not create a data risk. In an on-premise deployment, all logs remain within the institution's infrastructure; details are on the on-premise deployment page.
Does the maker/checker separation actually work?
It is not enough for the maker/checker separation to be defined; it must also work in practice. What the audit needs to look for is whether there are decisions prepared and approved by the same person. Since approval policies, multi-signature decisions, and delegation of authority are kept in the logs, this control can be queried without even sampling. Details are on the maker/checker, authorization, and audit trail page.
How is control effectiveness measured?
The mere existence of a rule does not mean it is effective. How many times it was triggered, how many cases it turned into, how many went to reporting, and how many were closed without justification can all be measured. A rule that never triggers and a rule that triggers everything are both audit findings.
Seeing what a rule would produce on historical traffic can also be used for auditing: what happens before and after a rule change can be compared. The rule simulation and backtesting page explains this.
Can the audit trail be altered?
No. Decision, justification, approval, and access logs are written immutably, and logs can also be sent to a separate destination; thus, a change within the platform itself does not affect the audit trail.
The daily workflow on the compliance side is covered on the compliance teams page, and the reporting side on the regulatory reporting page.
Common questions
- Why can't internal audit look at today's screen?
- Control systems are living systems; rules and thresholds change. Explaining a decision from six months ago using today's rule set yields incorrect results.
- Why is the rule version so important?
- If the specific rule and the version that triggered it are not stored alongside the event, the justification for a past decision cannot be reconstructed.
- How is audit sampling conducted?
- A subset is selected from the cases of a specific period using filters. Report definitions are created without code, results are saved, and the same definition can be run again in the subsequent period.
- Does data need to be exported for auditing?
- No. In an on-premise deployment, all logs remain within the institution's own infrastructure, so the audit itself does not create a data risk.
- How is it verified that segregation of duties actually works?
- Decisions prepared and approved by the same person can be queried. Approval policies, multi-signature decisions, and delegation of authority remain in the logs.
- How is the effectiveness of a rule measured?
- How many times it was triggered, how many cases it turned into, how many went to reporting, and how many were closed without justification are measured. A rule that never triggers and a rule that triggers everything are both audit findings.
- Can the impact of a rule change be seen in advance?
- Yes. The rule is run on historical traffic, and the before and after of the change can be compared.
- Can the audit trail be altered later?
- It cannot be altered. Logs can also be sent to a separate destination, so a change within the platform does not affect the audit trail.