Trust Level · 9 min read
Trust Level T0–T5 — which verification level is enough?
The SigID scale T0 to T5 decides when an action passes and when it is stopped. We explain every level, give practical examples and show typical thresholds.
Published on 10 May 2026 · 9 min read · SigID product team
The question 'how trustworthy is this identity?' rarely has a binary answer in practice. SigID therefore uses a six-step scale from T0 to T5. It turns the vague 'somehow verified' into a concrete, documented statement — per subject, per case, per point in time.
T0 — Unverified
Trust Level T0 is the default. A new supplier, a new person, a new IBAN starts at T0. SigID accepts T0 subjects for read operations and for non-critical workflows such as file uploads. Money does not flow to T0 recipients without a challenge in between.
T1 — E-mail domain confirmed
Trust Level T1 is reached via domain verification. Whoever sets the DNS TXT entry or confirms an SMTP magic link proves control over the domain. T1 is enough for invitations, newsletter subscriptions and early receipt uploads.
T2 — KYB / register check
Trust Level T2 requires a successful KYB check. Commercial register, representation authority and address are reconciled against authoritative sources. T2 is the typical entry point for actively managed suppliers. First bookings are possible, critical actions still require a challenge.
T3 — First signed payment relationship
Trust Level T3 is reached with the first signed payment. The IBAN is verified, the recipient has acknowledged the payment, and an audit event with risk-level high is on file. Repeat payments to the same T3 recipient can run without further challenge as long as the IBAN fingerprint stays unchanged.
T4 — Multi-factor identity with Trust App
Trust Level T4 requires a confirmed Trust App on the person's device. Passkey is set up, dynamic linking is possible, the key resides in the secure enclave. T4 is the standard level for active employees who release bookings or grant authorities in SigID.
T5 — Multi-signed representation with audit hash
Trust Level T5 is the highest tier. A person is not only at T4 but also holds a signed authorization-grant chain with audit hash. T5 is the prerequisite for especially sensitive cases: trust payouts, corporate registrations, single payments beyond defined thresholds.
Which level is enough for what?
There is no universal answer, but three rules of thumb help. First: read operations are uncritical from T1. Second: first payments need at least T2 plus a challenge. Third: four-eyes actions require at least T4 for the executor and T4 or T5 for the second confirmation. Concrete thresholds are configured per organization and per case type.
How trust levels can fall again
Trust levels are not static. A supplier with no activity for a year drops back to T2. A person who deactivates the Trust App falls from T4 to T2. An IBAN with a deviating fingerprint drops to T0 — until the new identity is confirmed. These downgrades are documented as audit events and reconstructible in the trail.
Trust level and risk level — two axes
Important: trust level is a property of the subject, risk level is a property of the action. An action with risk level high — such as an IBAN change — always requires a challenge with dynamic linking, regardless of the executor's trust level. Trust level reduces friction in daily work, risk level keeps the security guarantees high.
Practical example: tax advisory firm
A tax advisory firm with 40 employees typically works like this: accounting staff are T4, partners T5. Client IBANs start at T0, reach T2 via register reconciliation and T3 with the first signed booking. An IBAN change inside an active mandate runs via Trust-App challenge — typical processing time under 30 seconds.
Conclusion
Trust levels T0 to T5 turn the gut feeling 'somehow safe' into a measurable, communicable property. Once a threshold matrix is defined, you can apply it consistently for years — and hand your auditor an unambiguous statement. The next step: configure a threshold table for your own organization in SigID.
Technical depth on the hash chain is available in the audit event documentation.