Trust centre
Baobyte builds AML/CFT software for regulated institutions, which means the people who evaluate it are paid to be sceptical. This section describes the controls the platform actually implements, the deployment models that determine where your data lives, and — just as plainly — the assurances that have not yet been obtained.
In this section
Each answers one thing a security or procurement review asks, and says where the answer stops.
Architecture
These are the mechanisms an AML platform has to get right, because each one maps to a way the data it holds can be misused. Full detail, including what is still pending evidence, is on the security page.
Tenant context is resolved before any handler runs. Tenant tables carry a tenant_id, PostgreSQL row-level security is FORCEd on them, and composite foreign keys stop a row in one tenant referencing a row in another. A request with no unambiguous tenant fails closed.
Authentication is delegated to the institution's OIDC provider; Baobyte performs authorisation. Every API operation declares its permission in the OpenAPI contract and the router registers the route with that permission, so a route with no declared permission fails a test rather than defaulting to open.
Identifiers such as BVN, NIN, CAC, TIN and passport numbers are encrypted under a per-subject key derived through an envelope hierarchy, and searched through an HMAC blind index rather than in clear. CDD documents are encrypted before they reach the object store, filenames included.
Sensitive actions run through maker-checker: the approval records actor, payload digest, decision and timestamps, and the same actor cannot approve their own request. Reports generated against a schema that has not been validated against an authoritative source cannot be submitted at all.
Audit events form an append-only, per-tenant hash chain with a verification endpoint. Evidence objects are write-once: the filesystem adapter commits with an atomic hard link, the S3 adapter with If-None-Match, and neither adapter has a delete operation.
Unsafe configuration refuses to boot rather than running weakened. An unavailable screening provider, metric stream or schema is represented as unavailable — never as a clean result — because a timeout silently recorded as “no match” is an undetected control failure.
Data residency
Most AML platforms answer the residency question with a region name. This one answers it with a deployment shape, because in the two shapes that have been drilled the institution — not Baobyte — operates the database and the evidence store.
| Shape | Intended for | Where tenant data sits | Storage |
|---|---|---|---|
| Single-node, institution-operated | One institution, one site — on-premise, a single VPS, or an air-gapped data centre. | Entirely within infrastructure the institution controls. Baobyte operates nothing and holds no copy of tenant data. | Evidence on a local encrypted volume; PostgreSQL operated by the institution. |
| Kubernetes, institution-operated | An institution with an existing platform team and cluster, or a multi-tenant deployment. | Within the institution's own cluster and cloud account, in the region the institution selects. | S3-compatible object storage is required above one replica or for multi-tenant. |
| Baobyte-hosted | Institutions that do not wish to operate the platform themselves. | Not confirmed. Hosting region, operating entity and the resulting subprocessor set have not been fixed. | See the subprocessor register; every row on it is currently unconfirmed. |
Coordinated disclosure
If you have found a security issue in the Baobyte AML Suite, we want it reported to us before it is reported anywhere else.
The machine-readable contact details are published at /.well-known/security.txt, in the format defined by RFC 9116. That file is the authoritative contact point; if anything on this page and anything in that file disagree, the file is correct.
When you report an issue, the most useful things you can send are the affected version or commit, the deployment shape, a reproduction that does not require access to another institution’s data, and your assessment of impact. Please do not include customer personal data in the report itself.
Testing must be against your own installation or a test tenant you have been granted. Do not attempt to access another tenant’s data, degrade a production service, or exfiltrate records to demonstrate an issue — the acceptable use policy covers this in more detail.
Placeholder — the disclosure response commitments below have not been agreed or resourced — no acknowledgement window, triage target or reward has been approved. Replace with sourced, approved content before this page is made public.
Not yet published. Acknowledgement and triage windows, the coordinated disclosure timeline and a safe-harbour statement for good-faith research have not been agreed. Until they are, this page does not state one.
Assurance pack
The platform is designed against a controlled document set. These are internal documents rather than published ones, and the process for releasing them has not been settled.
Placeholder — whether, to whom and under what agreement these documents may be released has not been decided — the list describes documents that exist internally, not documents that are available on request. Replace with sourced, approved content before this page is made public.
How the product is deployed, isolated and encrypted, described for a technical reviewer.
Platform viewWhat personal data is processed, on what basis, and for how long. Draft, pending legal review.
Read the draftSupport tiers, severity definitions, the support-access model and what is agreed in an SLA.
Support modelSensitive-access review, retention, legal holds and authority evidence inside the product.
See the capabilitySend us the questionnaire. Answers that are “no” will be answered “no”.
Bring your security team
We would rather spend the first call on your isolation, key-management and evidence questions than on a slide about them. Bring the reviewer who is going to say no.