Transaction Audit Logs

(Section: Operations and Management)

1) Purpose and principles

The audit trail is the primary source of truth about who, what, where, when and why did, with the ability to prove the records are immutable and authentic.

• Completeness: the actions of people, services and external partners are covered.
• Immutability: Records cannot be overwritten/deleted without a visible trace.
• Attribution: The action is related to the subject, role, context, artifacts.
• Repeatability - The event can be replayed in a report/dispute.
• PII minimization: only necessary, with mask and tokens.

2) Coverage areas

User actions: entry/SSO/MFA, changing roles/limits, operations with PII.
Privileged operations: JIT/PAM sessions, break-glass, admin console.
Finance: price lists/taxes/FX publications, payments/disbursements, escrow, write-offs/returns.
Configurations/releases: phicheflags, schema migrations, deploy/rollback, keys/certificates.
Integrations: webhooks, signatures, receipts, idempotency keys.
Data: reading/exporting PII, creating/deleting artifacts, changing policies.

3) Architecture and immutability

Ingest gateway with authentication, quotas and circuit validation.
WORM storage (immutable buckets/append-only): version, Retention Lock, Legal Hold.
Crypto quitances: for critical events, a 'receipt _ hash' and a DSSE signature are formed.
Merkle chains: periodically built slices (checkpoint), root hash is published.
Chain of custody: tracing the movement of artifacts (who gained access, when, on what basis).
Time Sync: NTP/PTP, 'event _ time' and 'ingest _ time' labels, 'skew' adjustment.

4) Event diagram (reference)

audit_event {
id, event_time, ingest_time, producer, subject {
id, type: human    service    partner, roles[], mfa?, device_posture?
},
action: CREATE    READ    UPDATE    DELETE    EXECUTE    PUBLISH    APPROVE    ROLLBACK,
target { type, id, version?, region?, tenant? },
context { ip/asn, user_agent, env, trace_id, request_id },
policy_version, sod_check: pass    fail, justification?, ticket_ref?,
result: success    deny    error, error_code?,
diff_hash?, payload_hash?, receipt_hash?, dsee_signature?,
pii_classification: none    aggregated    tokenized    sensitive,
retention_class, labels[]
}

Optional: for financials - 'fx _ version/tax _ rule _ version/pricelist _ version'; for webhooks - 'webhook _ id', 'idempotency _ key'.

5) Data model and zones

Hot (RAM): 7-30 days, fast requests/dashboards.
Warm (OLAP): 6-24 months, analytics/searches.
Cold (archive/WORM): up to 7-10 years (regulatory).
Retention classes: 'operational', 'financial', 'security', 'legal _ hold'.
Policy versioning - all events are marked 'policy _ version'; Policy Change - Single Audit Event.

6) Access and privacy

RBAC/ABAC/ReBAC: visibility by role/tenant/region/case.
PII masking: tokenization of identifiers, output of the primary - only through approved jobs.
No direct deletion: only 'tombstone' + Legal Hold; planned "post-cleaning" with a separate magazine.
Audit of the audit itself: who watched/unloaded the logs is also logged.

7) Quality, consistency, takes

Data contracts: strict scheme and lambda validations at the input.
Idempotency & dedup: '(event_id, producer)'; «seen-cache» + KV.
Time correction: watermarks for late events.
Completeness control: comparison of source counters and ingest metrics.

8) Dashboards and queries

Operational: privileged actions, SoD violations, JIT rights lifts, access to PII.
Financial: FX/Tax/PriceList publications, quote↔checkout discrepancies, key signatures.
Integrations: webhook receipts, lag, retrai, takes.
Releases/configs: who/when/what turned on/rolled back, connection with incidents.
Search scripts: 'trace _ id', 'subject. id`, `target. id ', time/region/tenant,' policy _ version '.
Export: batch uploads on demand with receipt (signed manifest).

9) APIs and webhooks

'POST/audit/ingest '- receiving events (authentication, limits, scheme).
'GET/audit/search '- filters, pagination, limit on the result.
'GET/audit/trace/{ trace _ id} 'is a chain of events.
'POST/audit/receipt/verify '- check bill/DSSE.
Вебхуки: `SoDViolation`, `PrivilegedSession`, `PIIAccess`, `PolicyChanged`, `FinancialArtifactPublished`.

10) SLO/Audit Quality Metrics

Ingest Availability: ≥ 99. 95%.
Freshness (RAM): lag ≤ 30 with p95.
Completeness: ≥ 99. 5% of sources sent data to the window.
Correctness: checksum discrepancy ≤ 0. 1%.
Tamper-evidence: 100% of periods are certified by Merkle-roots/signatures.
PII Hygiene: 100% of events with sensitive class - with mask/token.

11) Playbooks and incidents

Suspicion of record spoofing: immediate verification of Merkle roots, reconciliation of DSSE receipts, access isolation, Legal Hold.
PII leak: search for affected events/exports, access audit, DPO/regulator notifications by time frame.
SoD violation: Operation block, temporary role removal, investigation and policy adjustment.
Ingest failure: buffering, degradation mode, replay after recovery, duplicate control.

12) Legal exposure and compliance

Retention by Jurisdiction: Finance/Tax - 5-10 years; security - by policy; personal data - minimum required period.
Legal Hold: removal freeze on case/regulator request.
Reporting artifacts: period index, root hashes, list of signatories, inventory of sources.
Non-refundability: crypto signatures, independent timestamping (internal TSA).

13) Specificity of iGaming/fintech

Payments/payouts: full trace of authorizations, clearing, refusals, chargeback; matching with bank receipts.
RTP/limits: profile publications, changes, observed RTP and limit decisions - with signatures and version.
Affiliates: reception of webhooks, dedup conversions, objections/escrow - only for signed artifacts.
Price lists/taxes/FX: artifact version in each order; rollbacks - with receipts.

14) RACI

15) Risks and anti-patterns

Editable logs without a trace → legal non-support.
No time synchronization → non-overlapping timelines.
Shadow exports without receipts → leaks/disputes.
Secrets in the logs → compromise.
No association with SLO/incidents → "data graveyard" without benefit.

16) Implementation checklist

• Define coverage areas and policy_version.
• Deploy ingest with authentication, schemas, and quotas.
• Include WORM, Merkle slices, DSSE signatures, TSA.
• Set up Class and Legal Hold.
• Enter RBAC/ABAC/ReBAC and audit log access.
• Build dashboards: privileges, PII, finance, releases/configs.
• Enable playbooks: tamper, PII leak, ingest failure, SoD violation.
• Try out replays and dedup on a test set.
• Export with receipts and query register.
• Perform quarterly quality metrics audits (freshness/completeness/tamper).

17) FAQ

Is it possible to store everything in a regular database?
For RAM - yes, but critical logs should be duplicated in WORM/append-only with signatures and Merkle slices.

Do I need to log every data read?
PII/Finance reading is mandatory; the rest by policy and cost.

How to prove immutability?
Root hashes, DSSE signatures, independent TSA and reproducible verification procedures.

What to do with the "right to remove" (GDPR)?
Delete the primary in the processing systems; in audit logs - store tokens/hashes without recoverable PII and maintain Legal Hold if necessary.

Summary: Audit logs are not "logs in S3," but a cryptographically provable action history with clear policies, unchangeable retention, managed access, and dispute/regulatory review readiness. Build ingest on contracts, sign critical events, support Merkle cuts and dashboards - and you will have a solid foundation of trust, safety and compliance.