Demiton Logo
Demiton

Security Architecture & Data Sovereignty

A transparent overview of how Demiton protects high-value financial credentials and transaction data.

The Zero Trust Philosophy

Demiton is designed to operate in a "Hostile Environment." We assume that any network can be compromised, so we protect data at the object level.

1. Encryption Standards

  • At Rest: All database volumes are encrypted using AES-256.
  • In Transit: All data transmission occurs over TLS 1.3. We do not support legacy SSL protocols.
  • Field-Level: Highly sensitive fields (like your CommBiz Private Key or Client Secret) are encrypted again at the application layer using Fernet (Symmetric Encryption) before being written to the database. Even a database administrator cannot read your keys.

2. Australian Data Sovereignty

For our ANZ clients, we enforce strict location pinning:

  • Compute: Google Cloud Platform (Sydney Region - australia-southeast1).
  • Database: Cloud SQL (Sydney).
  • Failover: Melbourne (australia-southeast2).

Your financial data never leaves Australian legal jurisdiction.

3. The "Ephemeral" Runtime

When Demiton processes a Payment Run (e.g., generating an ABA file):

  1. The data is fetched from D365 into secure memory.
  2. The file is generated in a temporary, isolated container.
  3. The file is pushed to the Bank via SFTP.
  4. The container is destroyed.

We do not "store" your ABA files. We process them. This minimizes the surface area for data leakage.

4. Audit & Immutable Logs

Every single action—whether performed by a human (clicking "Approve" in Teams) or a system (the daily scheduler)—is recorded in an Immutable Ledger.

  • Who: User ID / System Agent.
  • What: The Universal Verb (e.g., PUSH_DATASET).
  • Where: The target resource (e.g., sftp://commbiz/inbox).
  • Result: Success/Fail hash.

This log cannot be edited or deleted, ensuring you always have a forensic trail for your auditors.