Acceptable use policy

This policy applies to everyone who uses the Baobyte AML Suite: the institutions that subscribe to it, their personnel, their contractors, and any machine client operating under a credential issued within their tenant. It also applies to anyone who tests, probes or researches the platform.

It is intended to form part of the terms of service. The institution is responsible for the conduct of its own users and for ensuring they are aware of it.

How this policy is incorporated into the contract, and whether a breach is a suspension event, a termination event or both, has not been settled.

The platform is licensed for an institution’s own anti-money-laundering, counter-terrorist-financing and related compliance purposes: customer due diligence, transaction monitoring, sanctions and politically-exposed-person screening, investigation and case management, regulatory reporting, and the audit and record-keeping that support them.

Use it for a purpose outside that scope — commercial profiling, marketing segmentation, employment or credit decisions unrelated to financial-crime risk, or any purpose the institution’s own privacy notice does not cover — and you are outside both this policy and, in all likelihood, the lawful basis on which the data was collected.

You must not:

• use the platform in breach of any applicable law, regulation, sanctions regime or court order;
• upload or transmit material you have no right to transmit, or that infringes another party’s rights;
• upload malicious code, or attempt to introduce anything designed to interfere with the platform or the systems it connects to;
• impersonate another person or misrepresent your affiliation, including inside a case note or an approval;
• resell, sublicense or make the platform available to a third party except as your agreement permits; or
• use the platform to build or train a competing product, or to benchmark it for publication without written consent.

This section is the one that distinguishes an AML platform from ordinary software, and the obligations in it can carry criminal as well as contractual consequences.

• Do not tip off. Disclosing to a customer, or to anyone else, that they have been screened, alerted on, investigated, or made the subject of a suspicious transaction report — or that such a report is contemplated — is prohibited, and in many circumstances is a criminal offence. This includes indirect disclosure: telling someone an account is “under review” because of a match, or letting them infer it from the questions asked. The applicable statutory provisions must be identified by counsel and cited here before this policy is adopted; none is cited in this draft.
• Do not export or extract beyond your authority. Exports are separately permissioned, produce an artefact digest and are audited. Removing case, screening or report content to a personal device, a personal account, or an unapproved third-party tool is prohibited regardless of intent.
• Do not redistribute licensed reference data. Sanctions, politically-exposed-person and adverse-media data reaches the platform under a licence that generally forbids onward distribution. Extracting a list, or a substantial part of one, and passing it on is a breach of that licence as well as this policy.
• Do not query the platform about people you have no business reason to query. Every read of a sensitive identifier is recorded as an audit event with the actor, the time and the permission used, and those records are reviewed. Curiosity is a disciplinary matter and, depending on the data, a data protection breach.
• Do not put unrelated personal data into free text. Case notes are evidence and are retained. A note that names an uninvolved third party, or that records a personal opinion rather than an observed fact, becomes part of the record an examiner reads and a data subject may be entitled to see.

The institution is the controller of the personal data it processes in the platform. You must have a lawful basis for what you put into it, give the notices your own privacy policy requires, and respect data subject rights subject to the AML restrictions described in the privacy policy.

Do not load personal data into a test or demonstration tenant. Demonstrations and training must use synthetic data or an approved masked set — that is not a preference, it is the standing rule in the platform’s own training material, and a production record in a demonstration environment is a disclosure with no lawful basis behind it.

• Credentials are personal. Do not share an account, and do not use another person’s. Maker-checker is meaningless if two approvals came from one person with two logins.
• Service-account credentials are shown once. Store them in your secret manager immediately, never in a source repository, a configuration file committed to version control, a ticket, a chat message or a URL. Rotate them on the schedule your own policy sets, and revoke them when the integration is retired.
• Do not attempt to bypass a control. That includes approval workflows, permission boundaries, retention policies, legal holds, export controls and the tenant boundary. Attempting to reach another tenant’s data is the most serious breach of this policy available and will be treated as a security incident.
• Do not weaken the deployment. Where the institution operates the platform, running it with development authentication, unsigned content packs, mock identity verification or plaintext transport in a production environment is prohibited. The software refuses several of these outright; the refusal is a safety net, not a permission structure.
• Report suspected compromise immediately through your institution’s incident route. Do not investigate a suspected cross-tenant issue by attempting to reproduce it against live data.

The audit trail, the approval history and the stored evidence are what make a decision defensible. You must not attempt to alter, delete or obscure them, or to interfere with the hash chain that makes tampering detectable.

Backdating, editing a note to change what a decision looked like at the time, or recording an approval you did not make are all prohibited. Where a record is wrong, the correct action is a correction that leaves the original visible — which is how the platform is built to work.

Security research is welcome, within limits that protect other people’s data.

• Test against your own installation or a tenant you have been granted. Do not test against another institution’s deployment.
• Do not access, modify or exfiltrate data that is not yours, including to demonstrate a finding. A description of the access you could have obtained is sufficient.
• Do not run denial-of-service, load or stress testing against a production environment, and do not use automated scanning at a rate that degrades service.
• Do not use social engineering against personnel, and do not attempt physical access.
• Report through /.well-known/security.txt, and give a reasonable opportunity to remediate before disclosing publicly.

No safe-harbour commitment is offered in this draft, because none has been agreed. A researcher acting in good faith within the limits above should tell us what they are doing before they start.

The platform enforces limits on request rates, upload sizes, page sizes, screening candidate counts and query windows. These are protective controls, not challenges. Do not attempt to evade them by fragmenting requests across credentials or tenants.

Bulk operations — batch transaction ingest, watchlist imports, exports — must respect the documented bounds. A batch that exceeds them is quarantined at row level rather than silently truncated, and repeatedly submitting oversized work is a fair-use breach even though nothing appears to fail.

• Use a service-account credential scoped to the ingest permissions the integration actually needs, not a human user’s session.
• Send an idempotency key on every transaction, batch, report-generation and externally retried command. Replaying without one is how a duplicate alert becomes a duplicate filing.
• Never place customer identifiers, filenames or tokens in a URL, a query string or a log line.
• Handle the explicit unavailable, pending, quarantined and rejected outcomes. Mapping a provider timeout to “clean” or “verified” in your own system defeats a control the platform deliberately implements, and is a breach of this policy as well as a defect.
• Reconcile accepted events against your source ledger, and alert on quarantine volumes and latency rather than assuming success.

Report a suspected breach of this policy to your institution’s compliance or security function, and — where it concerns the platform itself — to Baobyte at hello@baobyteconsulting.com or through the contact page. A suspected security vulnerability should go through /.well-known/security.txt instead. Do not include raw personal data in the report.

A breach may lead to suspension of a user, a credential or an integration, and in a serious case to suspension or termination under the terms of service. Where a breach involves personal data it will also be handled as a potential incident under the data processing agreement.

The notification route, any cure period and the escalation process are not stated in this draft. Suspension of an AML platform can put a regulatory deadline at risk, so the process must be designed to preserve access to filing evidence wherever it lawfully can.

This policy will change as the platform and the regulatory environment change. Material changes will be communicated through the contractual notice route rather than by a silent edit to this page.