TiZNO does not store your client data

For a bank, the fear that a vendor will quietly accumulate client files is enough to stop a procurement before technical detail. TiZNO is architected so that ad-hoc client documents are parsed in memory for single-session use and are not written into a long-term content index for reuse across tenants.

Structured data, balances, KYC status, risk ratings, remains in your systems. TiZNO reads via read-only, audited APIs and does not copy those fields into its own database as a system of record. No client PII is placed into the policy vector index; that index is for your internal policy and procedural corpus, not for customer files you drop in for one-off review.

In GDPR terms, TiZNO is positioned to act as a data processor under your instruction, not as an independent controller aggregating depositor data for its own purposes. Your DPA and sub-processor posture still apply; the architecture is meant to align with supervisory expectations on minimization and purpose limitation.

That posture matters in diligence questionnaires: you can truthfully describe a processing model where the bank remains the system of record, TiZNO does not maintain a parallel client warehouse, and evidence of processing lives in your audit exports rather than in a vendor’s opaque datastore. Procurement still reviews subprocessors and regions; the point is that the risk profile is not “another cloud CRM holding copies of our books.”

For clarity: policy documents you deliberately upload for retrieval are your controlled corpus, distinct from transient client uploads handled session-only. The product separates those paths so indexing and retention policies can differ by design.