Skip to main content
Request a demo
Platform

White Label

A regulator asking how one client’s data is separated from another’s wants a mechanism, not a policy document.

One transaction boundaryThree stacked elements — a record, a rule and a ledger posting — enclosed by a single boundary, indicating that all three commit together or not at all.ONE TRANSACTION BOUNDARYRecordwhat is trueRulewhat is permittedPostingwhat it did to the bookscommit together

What it changes

  1. Three independent layersEvery tenant-owned row carries its tenant; every query is rewritten to carry a tenant predicate; and row-level security enforces the same rule in the database, with context set per transaction so a pooled connection cannot carry it into the next request.
  2. Brand is configurationName, legal name, domain and palette are configuration. No package, component, contract or copy string hard-codes a name.
  3. Supervision is explicitPlatform-operator access across tenants is opt-in per transaction, read-only at the database level, and audited. Cross-tenant writes are refused regardless of application code.
Ask, agree, then actThree steps. One person requests, a different person approves, and only then does the state change. The approval binds to what was requested, so editing it afterwards invalidates the sign-off.Requestone personApprovea different oneActnow it movesThe approval binds to what was asked.Edit it afterwards and the sign-off is void.
Every irreversible act on this platform takes this shape, whatever the subject of the page: one person asks, a different one agrees, and only then does anything move.
Three independent isolation layersTenant isolation is enforced in the schema, in the query client and in the database's row-level security. Each is sufficient on its own and each fails differently.SchemaEvery owned row carries its tenantA query that forgets the column does not compileClientQueries are rewritten, not trustedtenantDb(context) is the only read pathDatabaseRow-level security, verified runningThe app role cannot read across tenants at allA defect in one layer is contained by the other two — which is the only reason to have three.
Three layers, each sufficient alone. That is the only reason to run three: a defect in one is contained by the other two.

What it includes

Tenant provisioningBranding, roles, policy and approval thresholds per tenant.
Segregation of dutiesConflicting-role detection per tenant, surfaced where the owner actually looks.
Per-tenant exportsAudit, ledger and register, scoped to the tenant.

Evidence, not assertion

Controls that have been verified running, rather than described.

  • A test reads the generated data model and fails if any table is unclassified, so a new table cannot ship without somebody deciding how it is isolated.
  • Tenant isolation is checked before permission, so a denial cannot confirm that a foreign resource exists.
What counts as evidenceThree rows. A control described in a document is unticked; a control enforced by code and one refused by the database are ticked. Only the second and third are evidence that something holds.Described in a documentEnforced by codeRefused by the database
A control written down is not a control. Only the two lower rows are evidence that something holds, and both are what the list beside this describes.

See it against something real.

Bring an instrument you are actually considering. Structuring it is the only way to judge whether the model fits.

Request Enterprise DemoBack to platform
Your instrument, against this modelAn unspecified asset on the left feeds four stages: structure, compliance policy, the offering book and the register. The asset is drawn as an outline because it is the reader's, not the platform's.Your assetwhatever it isStructurePolicyBookRegister