Tenancy and isolation

A tenant is one institution. Every row the platform stores belongs to exactly one, every request resolves to exactly one, and no query path exists that spans them. The isolation is not a filter applied by application code that remembers to apply it — it is enforced in five independent layers, any one of which would be sufficient on its own.

How a tenant is resolvedPermalink to this section

In the hosted deployment the tenant comes from the subdomain: a request to acme.aml.baobyteconsulting.com resolves to the acme tenant before any handler runs. The resolved tenant is set on the database session, which is what row-level security reads. A request that resolves to no tenant is refused rather than defaulted.

The default storage shape is a shared schema with row-level security. Schema-per-tenant is available where an institution's own policy requires physical separation, and the application code is identical in both — the difference is a deployment decision, not a fork.

What crosses a boundaryPermalink to this section

• Nothing in the AML domain. Customers, transactions, alerts, cases, reports and audit records are tenant-scoped without exception.
• Regulatory content packs are shared, signed and versioned — they carry no institution's data, and a tenant records which version it has adopted.
• Platform-level operational telemetry, which carries tenant identifiers but no subject data.

The audit trail is chained per tenant rather than globally, so one institution's write rate never couples to another's and a tenant can be handed its own chain export for independent verification.