Saolix Group
When an examiner asks about a screening decision from last year, two questions follow. What did the system decide? And how do you know the record you are showing me is the record that was written? The second question is the harder one.
Most systems answer it with access controls: only certain people can edit the audit table. That is necessary, but it is a promise, not evidence. In Saolix Eagle we wanted the record itself to show whether it had been changed. This piece explains how.
One transaction, or nothing
The first rule is about timing. When an analyst or a connected system screens a name interactively, three things are written: the screening result, the case it opens (if any), and the audit record. They are written together: if the audit record cannot be written, the screening does not happen, so no interactive decision ever exists without its record. Batch runs are recorded as a whole.
A decision without its audit record never exists, not even for a moment.
What goes into a record
Each screening audit record holds what an examiner needs to understand the decision: what was searched, the outcome (PASS, REVIEW or FAIL), who ran it and when, and which list versions were in force and how current they were. A reviewer can see not only what was decided but how current the lists were when it was decided.
Sealing every record
Each record is then cryptographically sealed, using well-established, industry-standard techniques, and linked to the records before it. The log reads as one unbroken chain of evidence. Change any field of any record, even a single character, and the seal no longer verifies.
The seal relies on keys you control, held apart from the data they protect. That matters: even someone with full database access cannot quietly rebuild a valid-looking log.
The database refuses to forget
Seals make tampering visible. Eagle also makes it hard. The database itself rejects changes to audit records, with one deliberate exception: when records pass their retention period, personal data in them can be erased under Eagle's retention process, which leaves a marker in the log.
Checking it, on demand
A seal is only useful if someone can check it. Administrators can run an integrity check at any moment. It recomputes the log from the records themselves and shows whether it verified and, if not, exactly where it failed. Administrators can also export the general audit log as a CSV report.
Checking matters. An examiner does not have to take "the log is fine" on trust: the check is recomputed from the records themselves, and it fails if something was altered.
What this gives a bank
It turns the audit conversation from assurance into evidence. Instead of explaining your access-control policy, you run the check and show the result. The decision, its record and the proof that the record is intact all come from the same system, inside your own infrastructure.
You can see what a sealed chain looks like in our sample audit chain, a short PDF showing four sealed screenings and what happens the moment one is altered, or explore a full case in the Eagle Simulator.