# Configure audit logging

Wallet-as-a-Service can stream all organization activity to an **AWS Data Firehose** delivery stream for compliance reporting, incident investigation, and access review. As an owner or administrator, you configure the Firehose connection and manage audit log delivery. AWS Firehose is currently the only supported delivery target; customers on other clouds must ingest from Firehose into their own platform.

## What audit logs capture

Audit logs record every action in your organization, including:

- All API calls with request and response details
- User actions in the web console (sign-ins, setting changes, approvals)
- Transaction lifecycle events (creation, policy checks, approvals, signing, confirmation)
- Administrative actions (user management, device management, quorum operations)
- Timestamps and the identity of the user or API credential that performed each action
- Wallet lifecycle events (key provisioning and provisioning failures)


Wallet-as-a-Service captures request bodies up to 10 MB and stores them base64-encoded inside the payload. It never logs the `Authorization` header or response bodies: records carry a truncated hash of the `Authorization` value and the response body's length instead.

## How it works

Wallet-as-a-Service streams audit log events to an **AWS Data Firehose delivery stream** in your AWS account. From there, you route the logs to your preferred destination:

- **Amazon S3** — for long-term storage and compliance archiving
- **Splunk, Datadog, or another SIEM** — for real-time monitoring and alerting
- **Amazon Redshift or Elasticsearch** — for search and analysis


Wallet-as-a-Service buffers logs and delivers them approximately every 15 seconds.

## Prerequisites

Before you begin, set up the following in your AWS account:

- An **AWS Data Firehose delivery stream** configured with your preferred destination (S3, Splunk, etc.)
- An **IAM role** that Ripple can assume to write to the Firehose stream


## Configure the Firehose connection

1. Go to **Settings** > **Audit logs**.
2. Enter the **stream name** — the exact name of your Firehose delivery stream (up to 64 characters).
3. Enter the **ARN ID** — the IAM role ARN that Ripple assumes to write to Firehose.
4. Select the **AWS region** that contains your Firehose stream.
5. Select **Save**.


### IAM role setup

Create an IAM role with:

- A **trust policy** that allows Ripple's AWS account to assume the role.
- A **permission policy** that grants `firehose:PutRecordBatch` on your delivery stream and `sts:GetCallerIdentity`.


See [Firehose audit log reference](/pt-br/products/wallet/admin-guide/firehose-audit-log-reference) for the full IAM trust and permission policy JSON, including the Ripple AWS account IDs.

## Enable and disable audit logging

After you configure the Firehose connection, enable audit logging to start streaming:

1. Go to **Settings** > **Audit logs**.
2. Select **Enable**.


To temporarily stop streaming, select **Disable**. Wallet-as-a-Service preserves the configuration so you can re-enable it at any time.

If delivery keeps failing, Wallet-as-a-Service disables the configuration automatically. For example, this happens when the IAM role stops granting access or the delivery stream no longer exists. Fix the stream or IAM role, and then select **Enable** to resume streaming. When you re-enable the configuration, Wallet-as-a-Service delivers the events it recorded while the configuration was off. You can't fix one case yourself: a record that exceeds the size limit even after truncation. Re-enabling doesn't help in that case, so contact support.

## Log structure

Each audit log entry is a JSON record with a fixed envelope and a compressed payload.

The envelope carries event metadata (`id`, `type`, `source`, `receivedAt`, `createdAt`), actor information (`userId`, `deviceId`, `requestId`), and your `orgId`. The `type` field identifies the record: `1` for access events, `3` for transaction lifecycle events, and `4` for wallet lifecycle events.

The payload — request and response details for access events, or the changed entity for lifecycle events — travels in `compressedJsonData` as base64-encoded, Brotli-compressed JSON. Your consumer base64-decodes and decompresses that field to read the event.

Deprecated: jsonData
Ripple has **deprecated** the older uncompressed `jsonData` field. Wallet-as-a-Service emits it on access records only, it might be absent, and Ripple removes it after the deprecation window. Read `compressedJsonData` instead. See [Transaction and wallet audit records, compressed payloads, and `jsonData` deprecation](/pt-br/products/wallet/changelogs/firehose-audit-payload-compression).

See [Firehose audit log reference](/pt-br/products/wallet/admin-guide/firehose-audit-log-reference) for the full field reference, decode examples, and example payloads.

## Best practices

- **Route logs to a SIEM** — tools like Splunk, Datadog, or Elastic SIEM let you search, alert on, and visualize audit events in real time.
- **Set retention policies** — configure retention on your Firehose destination (S3 lifecycle rules, Splunk index policies) to meet your compliance requirements.
- **Monitor Firehose delivery** — use AWS CloudWatch metrics for your Firehose stream to detect delivery failures or throttling.
- **Use audit logs for access reviews** — periodically review who is accessing what, which credentials are active, and whether access patterns match expectations.
- **Correlate with freeze and approval events** — cross-reference audit logs with [transaction freeze](/pt-br/products/wallet/admin-guide/configure-transaction-freeze) and [approval flow](/pt-br/products/wallet/admin-guide/configure-approval-flows) activity for complete compliance reporting.
- **Separate sandbox and production** — use different Firehose streams and destinations for each environment.


## Limitations

- Wallet-as-a-Service delivers audit logs with a small buffer delay (approximately 15 seconds). They aren't suitable for real-time blocking or inline security decisions.
- Log delivery depends on your Firehose stream being available. If AWS throttles the stream or the stream becomes unavailable, Wallet-as-a-Service buffers logs and retries delivery.
- A single record must stay below 1,000,000 encoded bytes. When an access record exceeds that, Wallet-as-a-Service clears `request.body` from the payload and marks the record with `legacyJsonDataTruncated`.


## Related guides

- [Firehose audit log reference](/pt-br/products/wallet/admin-guide/firehose-audit-log-reference) — Full technical reference with IAM policies, log schema, and example payloads
- [Configure backup and recovery](/pt-br/products/wallet/admin-guide/configure-backup-and-recovery) — Set up AWS infrastructure for backups (similar IAM patterns)