Platform
One governed operating model, from customer intake to filed report
Baobyte AML Suite is a single system for Nigerian AML/CFT obligations: it captures the customer, ingests the transaction, applies the rules an institution's own compliance function authored, screens against versioned lists, holds the investigation, generates the report, and keeps the evidence an examiner will ask for. Every decision it records carries the actor, the policy version and the evidence it used.
Nine capability pages follow. Each one states what is in the shipped build and what depends on an external provider, a licensed feed or a regulator artifact the institution has to supply. That boundary is on the page, not in the footnotes.
The spine
Six stages, one chain of evidence
The modules are not separate products stitched together at the reporting layer. A transaction arrives with an idempotency key, a rule evaluation attaches its trace, an alert becomes case evidence only if it resolves to the same subject, and a report can be marked submitted only when external delivery evidence is bound to the exact payload digest. Provenance survives every hop.
5
Independent layers of tenant isolation
Tenant column, composite foreign keys, forced row-level security, a runtime role with no bypass, and explicit predicates anyway.
774
Nigerian locations embedded
States, local government areas and FCT area councils ship with the product, so address validation needs no outbound lookup.
10
Evidence families with their own retention policy
Each governed separately against a five-year statutory floor, and reported as uncovered rather than defaulted when no policy is approved.
6
Run modes in one binary
API, worker, migrator, bootstrap, offline key generation and standalone audit verification. No broker, no mesh, no separate search engine.
Capabilities
Nine places the work actually happens
Six of these are what a compliance team touches daily. Three are what a CISO, an integration lead and a programme manager ask about before any of it goes live.
Customer and CDD
Profiles, ownership, identity evidence and risk assessment.
Learn moreTransaction monitoring
Explainable rules, tuning and retained signal provenance.
Learn moreScreening and watchlists
Sanctions, PEP and adverse media adjudication.
Learn moreInvestigation and casework
Subject-consistent case workspace with linked evidence.
Learn moreGoverned reporting
STR, CTR and goAML filing with validation evidence.
Learn moreAudit and privacy
Sensitive-access review, retention and legal holds.
Learn moreIntegrations
Core banking, switches, identity and sanctions data.
Learn moreSecurity architecture
Deployment options, data residency and tenancy model.
Learn moreImplementation
The path from discovery to go-live, week by week.
Learn moreDesign decisions
Six choices that show up in every module
These are architectural rather than cosmetic, and they are the reason the same screen behaves the same way whether an analyst, an auditor or a payment rail is looking at it.
Tenant isolation in five independent layers
A tenant identifier on every scoped table; composite foreign keys carrying it, so one tenant's approval cannot attach to another's user; PostgreSQL row-level security enabled and forced with both USING and WITH CHECK; a runtime database role that is not the table owner and holds no BYPASSRLS; and explicit tenant predicates in generated queries anyway. Any one would do. One is not the standard.“Not checked” is never a kind of “clean”
Provider results are named outcomes, never booleans — confirmed, refuted, unavailable, not configured. A boolean's zero value is false, and false reads as “no match”, which is the one sentence “nobody was asked” must never be mistaken for. Missing metric streams report unavailable rather than zero, for the same reason.Maker-checker on the decisions that matter
Configuration activation, risk model and rule versions, watchlist publication and removal, high-risk false positives, case closure, report approval and retention reduction all require a second, different actor. The checker approves an immutable digest, not a screen that can change under them.Evidence is append-only, and audit commits with the change
Audit events form a per-tenant SHA-256 hash chain, written in the same database transaction as the change they describe, with UPDATE and DELETE revoked from the application role and a trigger that raises unconditionally in case a future GRANT reopens them. Document bytes are written once; there is no application delete operation for evidence.Policy is configuration, not a release
Risk factors and bands, monitoring rules, screening thresholds and review bands, CDD form schemas, report field mappings and workflow policy are versioned, schema-validated configuration. Changing a threshold is a proposal, a preview, an approval and a new immutable version — not a deployment.Unsafe configuration refuses to start
In production the process validates its configuration before it listens: no public URL, unsafe authentication, an unsigned content pack, an empty root key or a missing dedicated platform database role all stop the boot with an explicit message. A misconfigured install fails loudly instead of running weakened.
Where the edges are
What is built, and what your programme still has to supply
Stated once here and restated on every capability page. An AML platform that blurs this line costs its buyer a remediation, so the line is drawn where the code draws it.
Shipped and running
- Customer and CDD capture, identifier storage with tenant-keyed blind index lookup, beneficial ownership, encrypted document evidence and lifecycle decisions.
- Transaction ingest with idempotency and quarantine, rule authoring in a closed typed vocabulary, simulation against history, and alerts that carry their evaluation trace.
- Internal watchlist management, bounded import with row-level quarantine, versioned publication and hit adjudication with four-eyes on the decisions that need it.
- Subject-consistent case workspace, routing queues, encrypted attachments, four-eyes closure, and report generation with validation proof and field-level traces.
- Per-tenant hash-chained audit, sensitive-access review, retention policy with legal holds, and aggregate analytics with small-cell suppression.
External dependencies you own
- Licensed sanctions, PEP and adverse-media feeds. The adapter shape and the licence declaration are implemented; the data licence and the provider contract are the institution's to procure.
- BVN, NIN and CAC verification against NIBSS, NIMC and the Corporate Affairs Commission. The adapter seam exists and refuses to answer when no provider is configured; no provider client is in the repository.
- The authoritative NFIU goAML schema, code lists and filing channel. Report generation runs against a registered schema; submission is refused for a report generated against a non-authoritative one.
- Your identity provider, PostgreSQL instance, object storage and secret manager, plus a rehearsed key-escrow procedure. A database backup without the root key is unreadable by design.
- Load-test evidence at your volumes, an independent penetration test, and the RLS, restore and key-rotation drills run against your own production-shaped environment.
See it against your own obligations
Bring your control matrix. We will walk it module by module.
A working session with a compliance specialist and an engineer: your CDD form, your rule set, your reporting obligations, and an honest answer on every line that depends on a provider you have not procured yet.