Audit trail
Review who acted, under what role, on which operation, and with what outcome.
Audit trail lists your organisation's operations, such as publishing an obligation, approving a submission, or opening a participant's KYC record, together with who performed each one, their role at the time, and its outcome. A publish or an approval is a change; opening a KYC record changes nothing but still lands here, because the platform treats some reads as sensitive enough to record on their own. Use the entry to identify the actor and outcome. An entry names the operation by its operation identifier, and carries no per-entry timestamp on this screen, only membership in the 30-day window.
Reach for this page when you need to confirm that a specific operation happened, who performed it, and whether it succeeded, for example during an internal review or a request for attribution evidence. You will not need it to see what a record's fields used to be; it excludes request bodies by design. The recorded target keeps ordinary query parameter values and replaces credentials, such as passwords and tokens, with REDACTED. Before-and-after reconstruction belongs to the operation's own owning page instead, such as Obligations for an obligation publish or the affected asset's own detail page for a token operation.
The trail is read-only, not a configuration surface, and it changes nothing on any other page. It covers the last 30 days only, an attribution window rather than a permanent history, and it describes operations, never ledger activity. Open the affected asset's page to investigate its on-chain activity.
Opening this page, matching an entry, or scanning the list changes nothing on any other page: there is nothing here to undo. It does add to the trail itself, since reading this page is a sensitive read like any other tracked operation and creates its own entry naming you as the actor. Whether the operation an entry describes can itself be undone is a property of that operation's owning page, not of the trail. For the write model behind these entries, see the audit trail concept page.
Steps
Open Audit trail
Open "Reporting", then "Audit trail". The page requests recorded operations from the previous 30 days, oldest first.
Screen equivalent: each entry shows an operation identifier, target, reason where present, actor identifier, role at the time, and Pending, Success, or Failure outcome.
Match the operation
Scan the list, which carries no search or filter, for the recorded operation. Use the operation name to identify the request; compare its actor, historical role, and outcome with the event you are investigating. When an operator acted under delegated authorityDelegated Authority lets a signed-in operator work inside another party's account. One check decides who may enter; the party's own roles decide the rest.Read the concept on your organisation's behalf, the entry names the operator and the role they held during that session, not the party the operator was working for.
Continue the investigation
Each entry shows the operation's target, the path and redacted query string it acted on, and, for a consolidated transition, the requested destination state as its reason. A failed transition records the state it was asked to reach, not one it reached. The target can be truncated at 1,024 bytes and does not always name the affected resource. The reporting trail's resource history answers that directly, returning every actor and route that touched one resource; that is the query built for this step, so use it instead of searching Console pages by hand.
An entry's outcome leads to a different next step depending on which of three values it holds:
| Outcome | What it means | What to do |
|---|---|---|
| Success | The operation completed and its response carried no error. | Nothing further; the operation took effect as recorded. |
| Failure | The request returned an error. The entry alone does not prove that every side effect was rolled back. | Read the error and check the affected resource before retrying. Follow that operation's retry and idempotency rules. |
| Pending | The platform recorded that the operation started but never recorded that it finished. | Treat it as unresolved. Open the operation's own owning page, such as Obligations for an obligation publish, and check its current state there, since only that page knows whether the write actually finished. |
Query a different time window
The reporting trail endpoint returns timestamps and accepts a time window. Use a narrower window to locate an entry beyond the Console's first 200 rows, or an older window for an operation outside its 30-day view. The API reference defines the request and response fields.
Troubleshooting
No matching operation appears
Confirm the organisation. The page opens a bounded 30-day window, so older operations are outside this view. An organisation with more than 200 recorded operations in that window only shows the oldest 200 here, so a very recent operation can be missing even though it falls inside the 30 days. Query the reporting trail API with a narrower window to find it.
The entry has no changed values
The trail stores no request bodies. The target keeps ordinary query parameter values, with credentials redacted, but not the fields an operation changed. Use the owning operational record when you need field-level history.
An entry stays Pending long after it should have finished
Two different failures produce Pending, and the entry does not say which. A request lost to a crash before it finished still leaves this row as the evidence it was attempted. A request that ran to completion can also stay Pending if the closing write itself failed. Either way, open the operation's owning page and check its current state there; do not assume Pending means the work is still running.
Frequently asked questions
Can I change an obligation's requirements from here?
No. This page only reads. An organisation owner or platform administrator prepares or edits a draft through the Platform API, then can publish it on Obligations.
Can I get a longer window than 30 days?
The Console page itself is fixed at 30 days. A reporting obligation can include the trail in its report set, which exports the same records without the 30-day or 200-row limits the Console page and a single API call both carry.
Does opening this page put an entry on the trail itself?
Yes, and the same is true of a call to the reporting endpoints, not only the Console page. A later review of the same window will show that the trail was read, alongside whatever it was read to find.