Component topology and trust boundaries.
The TrueSign architecture is intentionally minimal. Every component exists to enforce a specific control required by a regulated authorization workflow.
Five components, one signing path.
Each authorization passes through the same deterministic path. There are no out-of-band channels, no SMS fallbacks, and no legacy bypasses.
Customer system of record (core banking, treasury platform, ERP, custody platform). Constructs the authorization request and forwards canonical intent to the TrueSign verifier.
Validates canonical intent encoding, evaluates server-side policy, dispatches signing challenge to the bound device, verifies the returned signature, writes to the audit ledger, and returns a cryptographic receipt.
Declarative, versioned, and auditable. Evaluates limits, segregation of duties, dual control, geofencing, time windows, and external compliance hooks at sign-time.
Append-only, hash-chained store of every request, signature, decision, and receipt. Supports SOC 2 and ISO 27001 audit and regulator inspection. Optional external notarization.
iOS Secure Enclave, Android StrongBox / Keymint, Windows TPM 2.0, or FIPS-validated HSM. Holds the non-exportable private key and produces signatures over canonical intent.
No trust in the host OS.
Private key material never leaves hardware. The host operating system is treated as untrusted; the bound device exposes only the ability to sign a presented canonical intent message after user confirmation.
╭───────────────────────────╮ ╭──────────────────────────╮ │ Originating system │ │ TrueSign verifier │ │ (core banking, treasury) │──────▶│ • canonical encoder │ ╰───────────────────────────╯ │ • policy engine │ ▲ │ • signature verifier │ │ │ • audit ledger │ │ receipt + decision ╰────────────┬─────────────╯ │ │ challenge │ ▼ │ ╭──────────────────────────╮ │ │ Bound device │ ╰───────────────────────│ Secure Enclave / TPM │ signature │ / FIPS HSM │ ╰──────────────────────────╯