Trust centre
Security
The Baobyte AML Suite holds the most sensitive records an institution keeps about its customers: identity documents, ownership structures, suspicion, and the reasoning behind a filing decision. This page describes the mechanisms that protect them, and is explicit about which assurances have and have not been obtained.
Threat model
What the system holds, and what protects it
Security design starts from the asset register rather than from a control checklist, because the question that matters is not “do you encrypt data” but “which key protects which record, and who can use it”.
| Asset | Classification | Primary protection |
|---|---|---|
| Customer and party profiles | Restricted personal data | Per-subject data-encryption key, HMAC blind index for search, role-based access, and an audit event on every read of a sensitive identifier. |
| CDD documents and case attachments | Restricted evidence | Encrypted before storage, written to a write-once object store, and downloadable only with an explicit permission. |
| Transactions and alerts | Confidential operational | Tenant scoping, idempotent ingest, and immutable evidence linking each alert to the rule version that raised it. |
| Screening and watchlist data | Confidential, high risk | Versioned snapshots so a decision can be replayed against the list as it stood, with source controls and least privilege. |
| Reports and filing evidence | Restricted regulatory | Payload bound to a digest, four-eyes approval before submission, and an audit record of every export. |
| Audit chain and anchors | Integrity critical | Append-only per-tenant hash chain, external anchor custody, and access restricted to the auditor role. |
| Root, tenant and subject keys | Secret | Held in an external secret manager, with rotation, escrow and a documented ceremony. Never in a values file, image, log line or repository. |
| Metrics, logs and traces | Internal | Label minimisation and redaction: identifiers, raw URLs, job arguments and error text are never metric labels. |
The trust boundaries the model works across are the browser-to-API edge, the API-to-worker boundary, the application-to-database boundary, the separation between tenant and platform database roles, the object-store boundary, and each external provider and network boundary. Every one of those has an entry in the threat register with an assigned likelihood, impact, mitigation and — importantly — a stated residual risk, several of which are open.
Isolation
Tenancy is enforced in the database, not only in the application
An application-layer tenant filter is one forgotten WHERE clause away from a cross-tenant disclosure, and that is the single worst failure this product can have.
Tenant context is resolved before a handler runs, from a fixed configuration, a subdomain or a token claim depending on how the deployment is configured. A request whose tenant cannot be resolved unambiguously fails closed rather than defaulting to any tenant.
Every tenant-scoped table carries a tenant_id and has PostgreSQL row-level security applied with FORCE, so the policy applies to the table owner too. Foreign keys between tenant-scoped tables are composite and include the tenant column, which makes a row in one tenant referencing a row in another a constraint violation rather than a logic bug.
Database privileges are split across separate credentials: a runtime role, a platform role and a migration role. In production the application refuses to start if the platform credential is unset or identical to either of the others, so a long-lived process cannot retain migration-owner rights.
Access control
Authentication is delegated; authorisation is not
Baobyte does not hold your users' passwords or second factors. It holds the permission model that decides what each of them may do once your identity provider has vouched for them.
Human users authenticate through the institution’s configured OIDC provider. The platform validates the issuer, the audience, the claims, the actor’s status, the tenant and the required permission before a handler is invoked. Multi-factor policy, password rules, recovery and deprovisioning stay with the identity provider, which is where an institution’s existing controls already live.
Authorisation is declared in the API contract itself. Every operation in the OpenAPI document carries an x-permission value and the router registers each route with the permission named there, so a route added without a declared permission fails a test rather than quietly defaulting to open. The Go server types and the TypeScript client are both generated from that same contract.
Machine clients use tenant-scoped service-account credentials rather than a user’s session. Those credentials are opaque, revealed exactly once at creation and stored only as a digest, scoped to the machine permissions assigned to them, and individually rotatable and revocable.
Cryptography
Encryption of sensitive fields, and the key hierarchy behind it
Whole-disk encryption protects data from someone who steals the disk. It does nothing about a compromised database credential, which is the realistic threat. Sensitive identifiers are therefore encrypted at the field level.
Root key material is the top of an envelope-encryption hierarchy. Every encrypted identifier — bank verification number, national identity number, corporate registration number, tax identification number, passport number — every subject data-encryption key and every encrypted document derives from it.
Encrypted fields still have to be searchable, so identifiers are additionally stored as an HMAC blind index. A lookup matches on the index without the plaintext ever being present in a query, a log line or a URL.
CDD documents are encrypted by the onboarding module before the storage adapter sees them, and the filenames are encrypted too, so they never appear in an object key or a URL. A compromised bucket credential yields unreadable bytes without the root key.
Root key material is held in an external secret manager and never in a values file, container image, ConfigMap, log line, support bundle or repository. Rotation is performed with a two-key overlap so that existing ciphertext stays readable while new writes move to the new key.
Integrity
Evidence that cannot be quietly changed
An AML record is only worth what an examiner believes about it. The controls here exist so that “this is what we knew and when we knew it” is demonstrable rather than asserted.
Append-only audit chain
Audit events form a per-tenant hash chain. Each event is bound to its predecessor, so a removed or altered event breaks verification rather than disappearing silently. Chain integrity is verifiable on demand through a dedicated endpoint and by an offline verifier run mode, and verification failure is one of the alerts the deployment is required to raise.
Write-once evidence storage
Both storage adapters are write-once. The filesystem adapter commits with an atomic hard link; the S3 adapter sends a conditional write that fails if the key already exists. An existing key is an error, never an overwrite. Neither adapter has a delete operation, and the deployment guidance is explicit that the storage credential must not be granted one.
Four-eyes on sensitive decisions
Maker-checker records the actor, a digest of the payload, the decision and the timestamps. The same actor cannot approve their own request. Risk approvals, screening hit clearance, case closure, configuration activation, watchlist publication and report submission all run through it, and the history is immutable.
Secure defaults
Unsafe configuration refuses to boot
A deployment that starts in a weakened state is the hardest kind of problem to find, because everything appears to work. This platform validates its configuration before it listens, and an unsafe value stops the process with an explicit message.
Configurations refused outright in a production environment
- A development authentication mode, whose tokens are locally signed and would grant any identity.
- Unsigned regulatory content packs — rules, risk weights and report templates must be signature-verified.
- Mock identity verification, which records a format check as a verification and must never be mistaken for a real NIBSS or NIMC response.
- Empty root key material, which would leave sensitive-field encryption with no key.
- An identity provider reached over plain HTTP, because the impersonator of such a provider supplies the token-verification keys.
- The repository's own development content-signing key, whose private half is committed to the source tree.
- A platform database credential that is unset, or identical to the runtime or migration credential — long-lived processes must not retain migration-owner rights.
- Object storage over plain HTTP, which would put evidence ciphertext and its credentials on the wire in clear.
- Filesystem evidence storage in a multi-tenant or multi-replica deployment, where pod-local evidence is unreachable from the replica that needs it.
Startup also performs active checks rather than trusting configuration: it proves the object store is writable, verifies that the platform database pool authenticates as a genuinely separate role, pings the cache when one is configured, and applies schema migrations under an advisory lock so two instances cannot race.
The same principle governs runtime behaviour. An unavailable screening provider, identity-verification provider, metric stream or schema is represented as unavailable, pending, quarantined or rejected. A timeout never becomes “verified”, “not a hit” or “clean”, and integrating systems are required to handle those outcomes explicitly.
A typo does not widen behaviour. An unrecognised value for an environment mode fails the process rather than falling back to a permissive default.
Data minimisation
Security telemetry must not become a second customer database
Observability is where personal data most often leaks out of a well-designed system, because a metric label or a log line is not where anyone looks for it.
- Raw URL paths, tenant, user, customer, request and job identifiers, job arguments and error text are never used as metric labels. Routes are normalised before they become labels.
- Metrics are exposed on a separate listener from the API, and the application refuses to start if the two are configured to the same address.
- Logs are JSON to stdout and do not contain secrets, decrypted personal data, or URLs carrying identifiers.
- Sensitive-identifier reads are audited as metadata events — who, when, which subject, under what permission — without the identifier itself entering the audit record.
- Restricted downloads are served with no-store and nosniff behaviour so a proxy or browser cache does not retain them.
- Executive analytics are counts only. Nothing on that surface resolves to a person, an account or a case, and small-cell suppression is applied inside the query rather than in the presentation layer.
Assurance
Security testing
What is automated in the build, and — separately, and importantly — what independent testing has not yet been done.
Automated and internal testing
- Cross-tenant access attempts through both the API and direct SQL, run as part of the release verification plan.
- Negative authorisation tests: a route with no declared permission fails a test rather than defaulting to open.
- Role-confusion and expired-credential cases, including a refusal of same-actor approval.
- Malformed form submissions and imports, bounded expression evaluation, and parameterised SQL throughout.
- Replay and duplicate-event tests against the idempotency contract, and quarantine behaviour on invalid input.
- Provider timeout and circuit-breaker behaviour, asserting that a timeout is never mapped to a clean result.
- Audit-tampering and backup-restore checks, and a key-rotation exercise.
- Browser end-to-end suites covering access-control visibility, the route matrix and the public surface, including a run with JavaScript disabled and an assertion that the public pages make zero cross-origin requests.
Placeholder — no independent penetration test has been commissioned, scheduled or completed — this block must not be replaced with a testing firm, date or result until one has. Replace with sourced, approved content before this page is made public.
Independent penetration testing
Not performedNo third-party penetration test has been commissioned or completed against this product. There is therefore no testing firm to name, no engagement date, no finding count and no remediation record to publish, and this page will not imply otherwise.
The threat model identifies penetration evidence as a required input for several residual risks — injection through forms, expressions and imports in particular — which are recorded as open until that evidence exists.
When something goes wrong
Incident response and continuity
The runbook's severity ladder is defined around this product's specific failure modes rather than around generic outage language.
The highest severity is reserved for confirmed or likely cross-tenant access, key compromise, evidence loss, a risk to filing integrity, or a major outage. It pages immediately and engages both an incident commander and the MLRO, because several of those failures have a regulatory deadline attached as well as a technical one.
The first fifteen minutes are prescribed: open the record and assign roles, capture detection time and correlation identifiers, preserve logs, metrics, audit exports, queue state and object metadata, stop destructive jobs, contain by revoking a credential or isolating a tenant, and decide explicitly whether any filing, screening, monitoring or privacy deadline is affected.
Closure requires containment, recovery validation, an affected-data determination, a notification decision, an evidence archive, root cause, corrective actions with owners and dates, and a review by security and the MLRO. Communications state facts and never carry raw personal data.
Reporting a vulnerability
Machine-readable contact details are published at /.well-known/security.txt in the RFC 9116 format. That file is authoritative; where it and this page disagree, follow the file.
Report against your own installation or a tenant you have been granted. Do not access another tenant’s data, degrade a production service, or exfiltrate records to demonstrate an issue — the acceptable use policy sets out what is and is not permitted.
Placeholder — no acknowledgement window, triage target, disclosure timeline or safe-harbour statement has been agreed. Replace with sourced, approved content before this page is made public.
Response commitments have not yet been published. Rather than state a target that nobody is resourced to meet, this page states that none has been agreed.
Security review
Ask the awkward questions first
Isolation, key custody, evidence immutability and what happens when a provider times out. Those are the four that decide an AML platform, and they are the four we would rather open with.