Support
Support and service management
How an issue with the Baobyte AML Suite gets raised, triaged and resolved — the tier model, the severity ladder, what a ticket has to contain, and the controls that apply when support needs to look inside your tenant.
Routing
Who handles what
Support for an AML platform is a shared model rather than a vendor helpdesk. The institution's own desk holds the front line, because it is the only party that can verify who is asking and what they are entitled to see.
| Tier | Operated by | Responsibility | Typical example |
|---|---|---|---|
| L1 — institution service desk | Yours | Intake, identity verification of the requester, known workarounds and status updates. | A user cannot sign in. A question about how to export a report. |
| L2 — application and compliance | Shared | Route behaviour, workflow, mapping and data-quality analysis. | An alert is stuck in a state. A CDD form rejects a valid submission. A report mapping looks wrong. |
| L2 — platform | Yours, with vendor assistance | Deployment, database, queue, storage, backup and metrics. | A readiness probe is failing. The job queue is backing up. |
| L3 — engineering and security | Baobyte | Defects, vulnerabilities, data integrity, cryptography and incidents. | Suspected cross-tenant exposure. An audit chain verification failure. |
| MLRO and legal | Yours | Regulatory interpretation, filing, retention and privacy decisions. | Correcting a submitted report. An erasure request that conflicts with a retention obligation. |
Severity
How urgency is decided
The ladder is defined around this product's specific failure modes rather than around generic outage language, because “the system is slow” and “a tenant boundary may have been crossed” need very different first hours.
| Severity | Initial response | Definition | Who is engaged |
|---|---|---|---|
| SEV-1 | Page immediately | Confirmed or likely cross-tenant access, key compromise, evidence loss, a risk to filing integrity, or a major outage. | An incident commander and the MLRO are engaged together, because these failures carry a regulatory deadline as well as a technical one. |
| SEV-2 | Page on-call | Material degradation, a provider outage, queue failure, an unauthorised access attempt, or a control that is not operating on time. | The service owner and the relevant control owner are notified. |
| SEV-3 | Business hours | A localised defect, a low-risk vulnerability, or a non-critical alert. | Handled as a ticket in the normal queue. |
| SEV-4 | Normal queue | A question, a cosmetic issue or a documentation correction. | Scheduled with other queue work. |
Severity is about impact and risk, not about how loudly it was reported. A single failed login is SEV-3; a single successful login from a credential that should have been revoked is not. Where a filing, screening, monitoring or privacy deadline is affected, that fact is recorded explicitly in the first fifteen minutes rather than discovered at the end.
Raising an issue
What a ticket must contain — and what it must not
The second list matters more than the first. A support ticket is not a lawful place for customer personal data, and an AML support ticket is the easiest place in the whole operation to leak it.
Every ticket includes
- The tenant, and the capability affected.
- The time window, with its timezone.
- The correlation identifier the platform returned. This is the single most useful field: it links the report to the exact request, job and audit records.
- A description that is safe to read — what happened, not who it happened to.
- Any business deadline the issue puts at risk, stated explicitly.
- Your assessment of severity, and the evidence link.
Never attach
- Raw customer identifiers — bank verification numbers, national identity numbers, corporate registration or tax numbers, passport numbers.
- Credentials or secrets of any kind, including a service-account key that has just been rotated.
- Full report payloads, or an export of a case.
- Screenshots containing unrelated personal data. A queue screenshot taken to show one stuck alert usually exposes twenty other people's names.
Where support genuinely needs to see the record, the answer is a masked export or an approved support session — not a paste into a ticket.
Response commitments
Service objectives
These belong in a service level agreement negotiated with the institution. Nothing on this page is a guarantee.
Placeholder — no service level agreement exists and no response or restoration time has been contractually committed — the figures below are an indicative starting point for negotiation and must not be quoted as a commitment. Replace with sourced, approved content before this page is made public.
Indicative starting point — not a commitment
A suggested opening position, from which a contractual SLA would be negotiated: immediate paging for a suspected isolation, key or evidence incident; one-hour acknowledgement for material degradation; same-business-day acknowledgement for a normal defect; and scheduled handling for questions.
None of that is agreed, resourced or contractual, and none of it should appear in a procurement document as a Baobyte commitment. Coverage hours, escalation contacts and the measurement method are equally unagreed.
Support access
What happens when support has to look inside your tenant
This is the part of a support model that a compliance function should read closely, because it is where a vendor's helpdesk becomes an access path into customer records.
Support access is not a standing privilege. A session is explicit, time-bound, tenant-scoped and reason-coded, and the record shows the support actor, the customer tenant, the start and end times, the permissions granted and the actions taken.
The tenant receives the session record and can request an audit review of it. Support cannot extract secrets, and cannot bypass an approval: a maker-checker step still needs a second, authorised human on the institution’s side.
An institution that wants to grant no support access at all can operate that way. The cost is that some classes of diagnosis become a guided exercise over a call rather than something support can do directly, which is a legitimate trade for an institution with a strict access policy.
Documentation
What documentation exists, who each document is for, and how status is recorded.
Open documentationAvailability
What is monitored, what must be alerted on, and the recovery position.
See availabilityTraining
Role-based curriculum and competency criteria, so fewer tickets are needed at all.
See trainingSecurity
Controls, testing and coordinated vulnerability disclosure.
Security detailBefore you buy
Agree the support model with the deployment, not after it
Coverage hours, escalation contacts, who holds L1, and what happens when a filing deadline is at risk. These are cheaper to settle during the evaluation than during an incident.