Audit and evidence

Answer who acted and what happened

An investigation may need to establish who requested a token movement, who approved it, whether it settled and how the bank recorded the result. These questions use different evidence: activity events, approval decisions, the token outcome and the bank's own records.

The activity log helps explain actions and changes. A successful activity entry alone does not prove settlement. Use the confirmed token outcome for that, and reconcile it with the bank posting.

Agree evidence access and retention with the deployment owner before an incident or offboarding. Export the records required by your bank into a controlled store. The record types, search options and technical fields below explain how the implementation team obtains that evidence.

The three records

Other records support these: approval decisions record who acted and any reassignment (GET /api/approvals/requests), and automation status changes are recorded in GET /api/automations/{automationId}/history.

Build evidence around one business instruction

Keep the bank's business reference as the starting point of an evidence record, followed by the idempotency key and platform transaction ID. Add the approval request and task decisions when applicable, the ledger hash and block when reported, and the webhook receipts used to update your application. These identifiers describe different records; do not assume one API returns the whole chain.

Use audit search to locate recorded activity, then read the full event for before-and-after values. Use the transaction resource to establish settlement and approval resources to establish sign-off. An activity outcome of SUCCESS means the recorded action succeeded; it does not, on its own, prove a related token movement settled.

Export the evidence your bank needs to a controlled store and agree retention during onboarding. The public audit API is an activity-log interface, not a general export of internal databases or every on-chain record.

Assemble evidence for one instruction

Start with the bank's business reference and use the stored identifiers to find the relevant records. These checks help operations and audit teams distinguish an action, a decision and a settled movement.

%%{init: {"theme": "neutral"}}%%
flowchart TB
    Reference["Bank business reference"] --> Activity["Match the recorded activity"]
    Activity --> Approval["Add approval evidence, if required"]
    Approval --> Outcome["Establish the token settlement outcome"]
    Outcome --> Cash["Reconcile with the bank posting"]
    Cash --> Retain["Retain evidence under bank controls"]

The bank assembles the evidence from separate resources. A successful activity entry or approval alone cannot prove settlement, and the activity log does not guarantee an event for every write. Agree retention and any operator-provided extracts for your deployment.

View in API Reference

• Search activity events
• Read approval requests
• Read the token outcome

The activity log

Search

GET /api/audit/events returns one page of your organisation's events, newest first. page defaults to 0 and size to 20, capped at 100.

Filters are optional and combine with AND:

Rows carry changedFields (names only, no values) and actor.displayName, resolved at read time.

Read one event in full

GET /api/audit/events/{eventId} returns the whole stored event, including the before and after values of every changed field. This is the only place those values are served. A value its producer withheld reads masked: true with ***. The event shows occurredAt, createdAt (when it was recorded) and recordedAt (when it was archived, null until then).

Export for evidence

GET /api/audit/events/export streams every event matching the current filter as UTF-8 CSV, with this header row:

eventId,occurredAt,action,category,source,actorType,actorId,requestId,resourceType,resourceId,outcome,summary,changedFields

The export is not paged. Cells that start with =, +, - or @ are prefixed with an apostrophe so spreadsheet software treats them as text.

Categories and outcomes

The example events in the API Reference use the categories DATA_CHANGE, SECURITY and BUSINESS_ACTION. Outcomes are SUCCESS, FAILURE and DENIED, so refused attempts are recorded as well as completed actions.

Use the action and resource values returned by the activity log and supported by its filters. The contract does not guarantee an event for every API write, so reconcile activity events with transaction and approval evidence.

The operational logs

Agree the fields and controls with your hosting owner before building log-based monitoring. Verify request/correlation IDs, caller attribution, timestamps and whether identifiers persist through asynchronous work. Confirm redaction of credentials, tokens, cookies and sensitive bodies, and the masking policy for customer/account references.

Operational logs help diagnose a workflow; they do not replace transaction reads, approval evidence or ledger reconciliation. Retain access/retention controls in the deployment assurance record rather than assuming every service produces the same log fields.

Retention and integrity

• Retention. In a client-hosted deployment, the bank applies its own retention to the logs and holds the audit history in its own database. For Quant-hosted infrastructure, agree retention and archived-event access in the operating model. Export required evidence to your bank-controlled store rather than assuming indefinite API availability.
• Integrity. The audit history is append-only. Hash-chained, tamper-evident storage of the audit history, and replication to a bank-owned write-once store, are not yet available. See Limitations.

Prepare evidence before an incident or retirement

Define what the bank must retain for each enabled workflow: business intent, original key, operation ID/state, ledger evidence, policy/approval decisions, and delivery receipt/processing records. The bank owns its evidence store and retention requirements; platform activity queries are one input, not proof that every instruction settled.

Verify export permissions and arrange access to any operator-held audit or infrastructure evidence before it is needed. Keep sensitive payloads and credentials out of general incident tickets. Preserve the relevant records before retiring identities, destinations or resources, and use Access changes and offboarding for the handover.

Worked example

List a week of events, then read one in full. There is no outcome filter; to find refused attempts, look for outcome: DENIED in the results or the export.

GET /api/audit/events?occurredFrom=2026-08-18T00:00:00Z&occurredTo=2026-08-25T00:00:00Z&size=50 HTTP/1.1
Host: api.qfp.quantnetwork.net
Authorization: Bearer <access token>
API-Version: 1.0.0

Illustrative example built from the schema. The source value names the platform component that produced the event.

HTTP/1.1 200 OK
Content-Type: application/json

{
  "data": [
    {
      "eventId": "2c7a5e91-8d43-4b6f-a012-5e8c1d9f7b34",
      "action": "APPROVED",
      "category": "BUSINESS_ACTION",
      "occurredAt": "2026-08-25T10:00:00.000Z",
      "source": "<producing component>",
      "actor": {
        "type": "USER",
        "id": "e47864d8-e0b1-70a7-59e9-50a309c66adb",
        "displayName": "Alice Whitfield"
      },
      "resource": {
        "type": "payment",
        "id": "pay_77"
      },
      "requestId": "req-5f0c-0011",
      "outcome": "SUCCESS",
      "summary": "APPROVED payment pay_77",
      "changedFields": []
    }
  ],
  "page": 0,
  "size": 50,
  "totalItems": 1,
  "totalPages": 1
}

Read it in full:

GET /api/audit/events/2c7a5e91-8d43-4b6f-a012-5e8c1d9f7b34 HTTP/1.1
Host: api.qfp.quantnetwork.net
Authorization: Bearer <access token>
API-Version: 1.0.0

Illustrative example built from the schema.

HTTP/1.1 200 OK
Content-Type: application/json

{
  "eventId": "2c7a5e91-8d43-4b6f-a012-5e8c1d9f7b34",
  "action": "APPROVED",
  "category": "BUSINESS_ACTION",
  "occurredAt": "2026-08-25T10:00:00.000Z",
  "createdAt": "2026-08-25T10:00:00.642Z",
  "recordedAt": "2026-08-26T01:00:04.310Z",
  "source": "<producing component>",
  "actor": {
    "type": "USER",
    "id": "e47864d8-e0b1-70a7-59e9-50a309c66adb",
    "displayName": "Alice Whitfield"
  },
  "resource": {
    "type": "payment",
    "id": "pay_77"
  },
  "requestId": "req-5f0c-0011",
  "outcome": "SUCCESS",
  "summary": "APPROVED payment pay_77",
  "changes": [],
  "data": {
    "reason": "month-end close"
  }
}

To hand the same set to an auditor, call GET /api/audit/events/export with the same filters.

View in API Reference

• List audit events · GET
• Read one audit event in full · GET
• Export the filtered audit events as CSV · GET

Errors and edge cases

API Reference

Open an endpoint for request fields, response examples and the interactive API console.

Related pages

• Policy, approvals and audit
• Roles and access
• Security and key management
• Reconcile against your core banking
• Limitations

Implementation resources

Audit events code recipes.

Use Implement a backend client for request handling, durable idempotency and outcome tracking. The developer integration coverage map links every public operation to its API Reference and contract-derived code recipe. Replace example identifiers with values from your assigned environment.