Compliance & Audit
Every Trustline decision is backed by tamper-evident audit evidence, public-safe reasons, signature verification, and exportable compliance records.
Every Trustline decision produces compliance-grade, tamper-evident audit evidence. When an agent's payment is approved or declined, an institution eventually has to show why. Trustline records that evidence at decision time and makes it independently verifiable afterward: you can confirm the audit chain is complete and untampered, see which evidence sources were used, read a public-safe explanation, and export a redacted case packet — without trusting a screenshot or asking Trustline to vouch for itself.
This page is written for institutions running agents and their compliance teams. It applies equally when an agent developer needs to defend a decision to a counterparty, but the surfaces below are governed by role, and the most sensitive of them are scoped to the owner and compliance roles.
What Trustline Records
Each underwriting decision is backed by an audit trace: a hash-chained sequence of audit events with a head hash that commits to the full history. The chain is what makes the record tamper-evident — each event carries a sequence number, the previous event's hash, its own hash, and signature material, so any later modification breaks the link.
Behind one decision, Trustline records and exposes the following in summary form.
| Element | What it captures |
|---|---|
| Audit trace and event chain | An ordered, hash-linked event history per decision, with a head hash and a terminal lifecycle event when the trace is complete. |
| Event-chain verification | Re-checks sequence order, every previous-hash link, every recomputed event hash, and that the stored head hash matches the recomputed one. |
| Signature summary | Signed and unsigned event counts, the key ids, and the algorithms used to sign audit events, validator ballots, and the finalizer output. |
| Evidence manifest summaries | The manifest hash, source count, verified-source count, and whether all sources verified — never the raw evidence itself. |
| Finalizer summary | The decision, risk level, confidence, selected reason codes, and the finalizer input and output hashes, so the decision step is checkable. |
| Policy refs | The policy snapshot versions the decision was made under. |
| Retention summary | The retention state of preserved artifacts, in summary form, including states such as legal_hold, retained_hash_only, applied, scheduled, and active. |
| Export eligibility | Whether an export is currently possible, stated explicitly with a blocking reason when it is not. |
| Decision explanations | Two redacted, audited explanation views — support-safe and agent-facing — built from the same record. |
The decision recorded by the finalizer is either APPROVE or DECLINE. Where a transaction needs more information, escalation, or a recorded-only outcome, that posture surfaces through the reason brief, the challenge state, and the product layer rather than as a separate decision value. See Async underwriting for the per-transaction reason lineage and Risk Engine for how reason codes are produced.
The Compliance View
The portal exposes these records on a Compliance page at portal.t54.ai, visible to members with the owner or compliance role. The same data is available through the portal API under /api/v1/developer-portal/*. Portal requests are authenticated by a signed-in session, not an API key; API keys (tl_sandbox_ and tl_production_) authenticate workload calls to the underwriting API and are never accepted on management or compliance endpoints.
The Compliance page supports four things.
| Capability | What it does |
|---|---|
| Trace verification lookup | Look up a trace by its trace id and confirm the audit chain verifies — chain validity, event count, head hash, signature summary, evidence manifests, finalizer summary, retention summary, and export eligibility. The same result is available per transaction. |
| Support-safe explanation | A redacted explanation for your operations and support teams: per-reason support summaries, remediation text, permitted actions, and an escalation flag. |
| Agent-facing explanation | A redacted explanation suitable to relay to the submitting agent or counterparty: a grounded message, public-safe reason codes, and remediation steps, with a flag marking whether each reason is safe to return externally. |
| Evidence export requests | Request a redacted export — a support-safe export or a case packet for a dispute, regulator exam, or legal review — and download a compliance PDF report. |
A verification lookup against the audit chain looks like this.
curl https://portal.t54.ai/api/v1/developer-portal/organizations/{developer_org_id}/compliance/traces/{trace_id}/verification \ -H "Authorization: Bearer <portal_session_token>"
{ "trace_id": "trc_...", "transaction_id": "txn_...", "verification_available": true, "trace_complete": true, "terminal_event_present": true, "event_chain_valid": true, "event_count": 14, "head_hash": "sha256:...", "computed_head_hash": "sha256:...", "signature_summary": { "signed": 14, "unsigned": 0, "key_ids": ["underwriting-signing-key-2026-06"], "algorithms": ["HMAC-SHA256"] }, "finalizer_summary": { "decision": "APPROVE", "risk_level": "low", "confidence": 0.91 }, "evidence_manifests": [ { "manifest_hash": "sha256:...", "source_count": 3, "all_sources_verified": true } ], "retention_summary": { "active": 12, "retained_hash_only": 2 }, "export_eligibility": { "exportable": true }, "errors": [] }
Underwriting audit events, validator ballots, and consensus finalizer outputs are signed with a key-management-compatible envelope. Each envelope records the key_id that signed it, so a verifier holding historical keys can still verify records signed before a key rotation. Signing uses HMAC-SHA256 today behind a signer interface designed to accept external key management providers.
{ "schema_version": "underwriting_signature.v1", "key_id": "underwriting-signing-key-2026-06", "algorithm": "HMAC-SHA256", "payload_hash": "sha256:...", "signed_at": "2026-06-05T20:00:00Z", "signature": "..." }
An export request is pinned to the trace it verifies. Before accepting a request, Trustline re-verifies the event chain and trace completeness; unverifiable or incomplete traces are rejected, and the verification view reports the same conditions ahead of time in its export-eligibility summary. Accepted requests record the trace head hash, computed head hash, and event count at request time, so exported material provably matches what you verified. A case packet additionally takes a case type — dispute, regulator_exam, or legal_review — and a recipient type, one of internal_legal, external_regulator, dispute_reviewer, or authorized_auditor.
curl -X POST https://portal.t54.ai/api/v1/developer-portal/organizations/{developer_org_id}/transactions/{transaction_id}/export-requests \ -H "Authorization: Bearer <portal_session_token>" \ -H "Content-Type: application/json" \ -d '{ "export_type": "case_packet", "purpose": "Cardholder dispute, ref 2026-0042", "case_type": "dispute", "recipient_type": "dispute_reviewer" }'
Every export request is itself written to the audit log, and the downloadable compliance PDF report draws on the same pinned, verified record.
Public-Safe by Design
Compliance views are deliberately built to show what was recorded and whether it verifies, not to reconstruct the internals of a decision. They never expose raw validator prompts, raw tool outputs, restricted evidence payloads, internal artifact or storage URIs, private policy material, privileged legal review material, or another tenant's data. Where the underlying decision used material that cannot be shown, the view exposes a hash and a redaction class instead of the content.
Explanations stay safe by construction. Reason codes come from a fixed, reviewable allowlist, and each maps to a principal reason suitable for a customer-facing notice. An explanation can state which public-safe reason codes were selected, which evidence categories contributed, whether a challenge response was considered, whether the audit chain verifies, and why certain material is redacted — without inventing detail to feel more complete. The agent-facing view additionally marks each reason with whether it is approved for external return.
Redaction is explicit rather than silent. Flexible fields pass through a recursive key filter at the response boundary that drops any key named raw, starting with raw_, or containing a _raw segment; keys carrying internal markers such as prompt, tool_output, artifact_uri, finalizer_input, and finalizer_output; and idempotency-key fields. Tenant isolation is applied before redaction is even considered: every query filters on the organization, and a resource owned by another tenant is invisible rather than merely forbidden.
Audit Log
Separate from the per-decision audit traces, the portal keeps an organization audit log of management actions. Every sensitive action appends a hash-chained record carrying a stable payload hash and redacted metadata only.
| Action category | Examples |
|---|---|
| Authentication | Sign-ins and password resets. |
| Team | Member invitations, role changes, and status updates. |
| Organization | Settings changes and KYB submission and decision recording. |
| API keys | Key creation, rotation, and revocation, recorded by key prefix only. |
| Webhooks | Endpoint creation and updates, signing-secret rotation, and test sends. |
| Compliance | Export requests. |
Each record stores an event_payload_hash computed over redacted, stable fields — organization, user, and member ids, action, resource type and id, result and reason code, environment, and the actor's IP and user-agent hashes. Trustline never stores raw API keys, invitation tokens, password reset tokens, raw IP addresses, or raw user agents in the log. The audit log is readable in the portal by members with the owner, admin, or compliance role; export requests within it can be created and read by the owner and compliance roles. See Webhooks and monitoring for the delivery and signature events that appear here.
What This Enables for Institutions
The point of this evidence is operational, not decorative. With it, an institution can:
- Defend an underwriting decision in an internal or external audit by re-verifying the chain rather than relying on a Trustline assertion.
- Respond to a regulator inquiry with a redacted, purpose-recorded export pinned to a verified trace.
- Produce a case packet for a dispute, regulator exam, or legal review, routed to the appropriate recipient type.
- Give a user or counterparty a clear, public-safe record of how a transaction was evaluated, drawn from the same audited reason lineage that drove the decision.
This is what separates using agents as opaque automation from using them as controlled financial actors whose actions can be measured, reviewed, and limited — the underwriting record described in Underwriting, made independently checkable after the fact.
A note on maturity. The portal and the compliance surfaces described here — trace verification, support-safe and agent-facing explanations, exports, the compliance PDF, and the audit log — are available now. Production go-live and any fair-lending notice language are tied to tested behavior and the Trustline launch review: approved KYB alone does not unlock production, which also requires Trustline-team production enablement after that review. Treat these surfaces as a working, governed evidence model rather than a fully certified compliance program; align the principal-reason language to your own regulatory posture before it reaches an end user.