TiZNO Explained

MISCONCEPTION · ISSUE NO. 04

TiZNO does not make decisions, your team does

Regulators and internal audit rightly worry about “rogue” automation. TiZNO is built so that every write to a downstream system, freeze account, send email, open a case, restrict a client, surfaces as an Action Card that requires explicit human approval. The platform handles orchestration, retrieval, and drafting; your officers retain decision rights.

Write APIs are executed under the approver’s identity and time-stamped approvals, so accountability stays with the bank’s four-eyes culture. This is deliberate human-in-the-loop design: TiZNO absorbs operational grind (scan, retrieve, reason, draft); your team applies judgment and takes the regulatory hook where the hook belongs.

That model matches what supervisors expect in practice: a named individual on the record for material actions, supported by a machine-generated evidence pack, not an autonomous agent clicking “submit” on its own initiative.

Technically, service accounts used for read-only integration do not graduate into privileged write scopes without an officer context. Where connectors require write access, those calls are brokered through approval-gated paths so the platform cannot “sneak” a configuration that bypasses four-eyes expectations.

For committees worried about model drift: decision authority remains binary, approve or reject, while the system preserves the rationale bundle for later review. Nothing in that design prevents conservative governance; it encodes it.

Workflow example

TiZNO recommends restricting wires for a client pending EDD completion. The Action Card shows cited policy, CRM status, and suggested wording. Only after a compliance manager approves does the restriction API run, under that manager’s credentials, with the full trace retained for audit.