Identity events: the audit log
Every identity transition in your workspace is recorded as an immutable row in the Identity events audit log. This is the evidentiary record an auditor will ask for, and the troubleshooting surface you use when a verification does not go the way you expected.
Open Settings, then Verification, then the Posture tab, and follow View identity events for this workspace. Events from every channel appear here: voice, email, chat and WhatsApp.
Reading the table
Section titled “Reading the table”Each row has:
- Timestamp: when the event fired, to the second.
- Event: the event type, listed below.
- Contact: the contact the event is bound to, when known.
- Conversation: the conversation the event belongs to.
- Prompt version: the version of the verification prompt at the time of the event. Useful when comparing behaviour across releases.
Clicking a row expands its detail: the factor category and type, the scope, the audit reference, the prompt version and the event id.
Event types
Section titled “Event types”| Event | What it means |
|---|---|
| Verification attempt | A verification started for this conversation. |
| Factor added | A proof was accepted, such as a correct answer or a clicked link. |
| Factor failed | An attempt produced an incorrect answer or a tampered token. |
| KBV question asked | The assistant asked a question drawn from your own records. |
| KBV question passed | The answer matched. |
| KBV question failed | The answer did not match. |
| Identity locked (per-call) | The wrong-answer allowance was used up, so the assistant stopped for this conversation. |
| Identity locked (24h) | The failed-verification limit was reached, so this customer is locked out until the lockout duration elapses. |
| ANI blocked | One number has attempted verification under too many different identities, so further attempts from it are blocked. |
| Assurance level reached | The proofs held brought the customer to identified or high-assurance. |
| Verification not configured | A tool needed a verified customer and there was nothing to ask or send. |
| Verification-agent context used | oHallo read one of your tools to formulate a question. This read is bound to that specific customer and tool. |
| Operator joined the call | An operator joined a live call through the audio bridge, recorded with the assurance level at the moment they joined. |
| eid_approval_requested | A verification prompt was sent to the customer’s own MitID or BankID app. |
| eid_link_issued | A secure verification link was issued for the customer to open at their own timing. |
| eid_approval_granted | The customer approved and the scheme’s answer verified them. |
| eid_approval_denied | The customer declined in their app, or a completed approval did not match the record on file. |
| eid_approval_expired | The scheme’s window closed without an answer. |
An eID event names the scheme in its audit reference, such as eid:dk_mitid.
Filtering
Section titled “Filtering”The top of the page has one control: an event type dropdown that narrows the list to a single type.
To follow one customer’s experience, open the conversation, click into a turn, and read the Identity events section on the Inspect panel. The workspace list is for questions that cross conversations, such as how many lockouts happened last week.
Retention
Section titled “Retention”Identity events are kept for 24 months by default. The current period for your workspace is shown on the Posture tab in the Records row. A daily sweep deletes rows past the cutoff.
For a right-to-erasure request under GDPR Art. 17, contact your oHallo account team. See Data retention and erasure.