Catch It. Explain It. Report It — In Real Time.
Complete installation, integration, and usage guide for bank IT and compliance teams
Sentinel AML is a CBN-compliant anti-money laundering platform purpose-built for Nigerian banks and fintechs. It ingests transactions in real time via Kafka, evaluates them against six CBN detection rules and an ML anomaly model (Isolation Forest with SHAP explainability), generates instant alerts with full reasoning explanations, supports maker-checker case management workflows, and exports NFIU goAML STR XML reports. All screening is performed internally — no personally identifiable information ever leaves your server, ensuring full NDPA compliance.
| Tier | vCPU | RAM | Storage | Use Case |
|---|---|---|---|---|
| Minimum | 4 | 8 GB | 100 GB SSD | Development, evaluation, small MFBs |
| Recommended | 8 | 16 GB | 250 GB SSD | Mid-tier banks, up to 500K txn/day |
| Production | 16+ | 32 GB+ | 500 GB+ NVMe | Tier-1 banks, high-volume processing |
The platform follows an event-driven architecture with clear separation of concerns:
CBS (Core Banking) --> Kafka --> Rule Engine --> Alerts --> Dashboard
|
ML Engine (Isolation Forest + SHAP)
|
XAI Reasoning Card
|
Case Management (Maker-Checker)
|
NFIU goAML STR XML Export
| Component | Port | Technology |
|---|---|---|
| Backend API | 8000 | FastAPI, SQLAlchemy (async), aiokafka |
| Frontend Dashboard | 3000 | Next.js 15, React 18, Zustand, Radix UI |
| PostgreSQL / TimescaleDB | 5432 | Append-only audit, time-series transactions |
| Redis | 6379 | Alert cache, screening cache, sessions |
| Kafka (KRaft mode) | 9092 | Transaction ingestion (internal only) |
This step-by-step tutorial walks compliance officers and bank IT staff through the first-time experience after installation. By the end, you will have ingested test transactions, reviewed an alert, opened a case, and exported an STR report.
After installation, open your Sentinel URL in a browser and sign in with the admin credentials created during setup.
https://sentinel.yourbank.ng. You will see the login screen.The dashboard is your command centre. Here is what each section shows:
| Section | Purpose |
|---|---|
| Alert Feed | Live stream of triggered alerts, colour-coded by severity (critical, high, medium, low) |
| Transaction Volume | Real-time chart of ingested transactions per hour/day |
| Rule Breakdown | Which CBN rules are firing most frequently |
| ML Anomaly Score | Distribution of anomaly scores from the Isolation Forest model |
| Case Pipeline | Cases by stage: open, under review, escalated, closed |
Use the built-in MockCBS to generate realistic test data and see the system in action:
# Start MockCBS service
docker compose --profile testing up -d mockcbs
# Generate 200 transactions over 2 minutes (includes suspicious patterns)
curl -X POST http://localhost:9500/generate \
-H "Content-Type: application/json" \
-d '{"count": 200, "duration_seconds": 120, "include_suspicious": true}'
Within seconds, you should see transactions appearing in the dashboard and alerts beginning to fire.
When an alert warrants investigation, escalate it to a case:
For cases that must be reported to the NFIU:
Navigate to Settings → Users to invite team members. Sentinel supports four roles:
| Role | Permissions |
|---|---|
| Viewer | Read-only access to dashboard, alerts, and cases |
| Analyst | Review alerts, manage cases, run screening (Maker) |
| Compliance Officer | Approve cases, generate STRs, manage watchlists (Checker) |
| Admin | Full access including user management, integrations, and system configuration |
Sentinel performs internal screening against local watchlists (no PII leaves your server):
When you are ready to connect your live Core Banking System, follow the CBS Integration section below. The key steps are: register your CBS in Settings → Integrations, obtain your API key, and configure your CBS to push transactions to the ingest endpoint.
The fastest way to deploy Sentinel. A single command downloads the release tarball, runs pre-flight checks, and launches the interactive setup wizard.
curl -sL https://sentinel.sjultra.ng/install.sh | bash
The interactive wizard guides you through nine configuration stages:
.env with restricted permissions.sentinel.yourbank.ng). Used for SSL certificate provisioning and webhook callbacks.After installation completes, verify all services are healthy:
# Check service status
docker compose ps
# Verify API health
curl -s https://your-sentinel.ng/api/health | jq .
# Expected response:
# {
# "status": "healthy",
# "services": {
# "database": "connected",
# "redis": "connected",
# "kafka": "connected",
# "ml_engine": "loaded"
# }
# }
# View recent logs
docker compose logs --tail=50 backend
Sentinel supports zero-downtime rolling updates. The update process backs up your current configuration before applying changes.
# Pull latest release and apply migrations
curl -sL https://sentinel.sjultra.ng/install.sh | bash -s -- --update
# Or manually:
cd /opt/sentinel
docker compose pull
docker compose up -d --remove-orphans
docker compose exec backend alembic upgrade head
The --update flag preserves your .env, SSL certificates, and database. Only container images and static assets are replaced.
# Database dump (includes TimescaleDB hypertables)
docker compose exec postgres pg_dump -U sentinel -Fc sentinel_db \
> backup_$(date +%Y%m%d_%H%M%S).dump
# Full configuration backup
tar czf sentinel-config-$(date +%Y%m%d).tar.gz \
.env docker-compose.yml ssl/ config/
# Stop services
docker compose down
# Restore database
docker compose up -d postgres
docker compose exec -T postgres pg_restore -U sentinel -d sentinel_db \
--clean --if-exists < backup_20260715_120000.dump
# Restart all services
docker compose up -d
For production deployments requiring high availability, auto-scaling, and managed infrastructure, deploy Sentinel using our official Helm chart.
kubectl configured with cluster access# Add the Sentinel Helm repository
helm repo add sentinel https://charts.sentinel.sjultra.ng
helm repo update
# Install with custom values
helm install sentinel sentinel/sentinel \
--namespace sentinel \
--create-namespace \
-f values.yaml
global:
domain: sentinel.yourbank.ng
backend:
image:
tag: "1.4.0"
replicas: 2
frontend:
replicas: 2
secrets:
jwtSecret: "your-256-bit-secret"
databaseUrl: "postgresql+asyncpg://sentinel:password@postgres:5432/sentinel_db"
redisUrl: "redis://redis:6379/0"
ingress:
enabled: true
className: nginx
tls:
- secretName: sentinel-tls
hosts:
- sentinel.yourbank.ng
postgresql:
enabled: true
persistence:
size: 100Gi
redis:
enabled: true
kafka:
enabled: true
persistence:
size: 50Gi
aws-load-balancer-controller for ingress with ACM certificates| Transaction Volume | Backend Replicas | Kafka Partitions | DB Pool Size |
|---|---|---|---|
| Up to 100K txn/day | 2 | 3 | 20 |
| 100K - 1M txn/day | 4 | 6 | 50 |
| 1M - 10M txn/day | 8 | 12 | 100 |
| 10M+ txn/day | 12+ | 24+ | 200+ |
Horizontal Pod Autoscaler (HPA) is pre-configured in the Helm chart. Default scaling triggers at 70% CPU utilisation or 80% memory utilisation. Kafka consumer lag is also available as a custom metric for scaling.
# Check current scaling status
kubectl get hpa -n sentinel
# Manually scale backend
kubectl scale deployment sentinel-backend --replicas=6 -n sentinel
Sentinel ingests transactions from your Core Banking System (CBS) via a simple REST endpoint. The integration takes four steps and can be tested with our MockCBS utility before connecting to production.
POST https://your-sentinel.ng/api/v1/ingest/transactions with the API key in the Authorization header.Push transactions to POST /api/v1/ingest/transactions with the following JSON body:
{
"entity_id": "ENT-001-2024-00482",
"timestamp": "2026-07-20T14:32:00Z",
"amount": 4850000.00,
"currency": "NGN",
"channel": "branch",
"direction": "credit",
"counterparty_token": "CP-TOKEN-8a3f2e",
"counterparty_name": "Adewale Trading Ltd",
"reference": "FT26201ABCDE",
"transaction_type": "transfer"
}
| Field | Type | Required | Description |
|---|---|---|---|
entity_id |
string | Yes | Unique customer/entity identifier in your CBS |
timestamp |
ISO 8601 | Yes | Transaction timestamp in UTC |
amount |
number | Yes | Transaction amount (positive value) |
currency |
string | Yes | ISO 4217 currency code (e.g., NGN, USD) |
channel |
string | Yes | Transaction channel: branch, mobile, internet, atm, pos |
direction |
string | Yes | credit or debit |
counterparty_token |
string | No | Tokenized counterparty reference (preserves privacy) |
counterparty_name |
string | No | Counterparty display name |
reference |
string | Yes | Unique transaction reference from CBS |
transaction_type |
string | Yes | transfer, deposit, withdrawal, payment, forex |
Sentinel ships with a MockCBS service for integration testing. It simulates realistic transaction patterns including structuring attempts, dormant activations, and rapid fund movements.
# Start MockCBS (available on port 9500)
docker compose --profile testing up mockcbs
# Generate 1000 test transactions over 5 minutes
curl -X POST http://localhost:9500/generate \
-H "Content-Type: application/json" \
-d '{"count": 1000, "duration_seconds": 300, "include_suspicious": true}'
# Check MockCBS status
curl http://localhost:9500/status
MockCBS pushes transactions directly to the Sentinel ingest endpoint, so alerts will appear in your dashboard in real time during testing.
Sentinel integrates with major Nigerian identity verification providers for automated onboarding (KYC/KYB). Configure your preferred provider to enable real-time identity checks and risk scoring during entity onboarding.
| Provider | KYC | KYB | Provider Code |
|---|---|---|---|
| YouVerify | Yes | Yes | youverify |
| Smile ID | Yes | Yes | smileid |
| Prembly (Identitypass) | Yes | Yes | prembly |
| VerifyMe | Yes | No | verifyme |
After completing setup in your provider's dashboard, register the following webhook URL to receive verification results:
https://your-sentinel.ng/api/v1/onboarding/webhook/{provider}
# Examples:
# https://sentinel.yourbank.ng/api/v1/onboarding/webhook/youverify
# https://sentinel.yourbank.ng/api/v1/onboarding/webhook/smileid
# https://sentinel.yourbank.ng/api/v1/onboarding/webhook/prembly
# https://sentinel.yourbank.ng/api/v1/onboarding/webhook/verifyme
All webhook requests from providers must include these headers for verification:
| Header | Description | Example |
|---|---|---|
X-Bank-Id |
Your bank's unique identifier in Sentinel | bank_001 |
X-Signature |
HMAC-SHA256 signature of the request body | sha256=a1b2c3d4e5... |
Use the Sentinel API to submit a test onboarding request and verify the end-to-end flow:
# Submit a test KYC verification request
curl -X POST https://your-sentinel.ng/api/v1/onboarding \
-H "Authorization: Bearer YOUR_JWT_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"entity_type": "individual",
"provider": "youverify",
"document_type": "nin",
"document_number": "12345678901",
"first_name": "Test",
"last_name": "User",
"date_of_birth": "1990-01-15"
}'
# Check verification status
curl https://your-sentinel.ng/api/v1/onboarding/status/REQ-ID-HERE \
-H "Authorization: Bearer YOUR_JWT_TOKEN"
Most providers offer sandbox/test modes. Configure sandbox API keys in your .env for testing before switching to production credentials.
Core endpoints for programmatic integration. All endpoints require authentication via Bearer JWT token unless otherwise noted.
# Obtain a JWT token
curl -X POST https://your-sentinel.ng/api/v1/auth/login \
-H "Content-Type: application/json" \
-d '{"email": "admin@yourbank.ng", "password": "your-password"}'
# Use token in subsequent requests
curl https://your-sentinel.ng/api/v1/alerts \
-H "Authorization: Bearer eyJhbGciOiJIUzI1NiIs..."
| Method | Endpoint | Description | Auth |
|---|---|---|---|
| POST | /api/v1/ingest/transactions |
Push transactions from CBS. Triggers rule engine evaluation and ML scoring. | API Key |
| POST | /api/v1/screening/entity/{id} |
Screen an entity against internal watchlists (PEP, sanctions, adverse media). | Bearer JWT |
| POST | /api/v1/onboarding |
Submit KYC/KYB verification request via configured provider. | Bearer JWT |
| GET | /api/v1/alerts |
List alerts with filtering by severity, rule, status, and date range. | Bearer JWT |
| GET | /api/v1/cases |
List cases with maker-checker status, assigned analyst, and resolution. | Bearer JWT |
| GET | /api/v1/health |
System health check. Returns status of all connected services. | None |
All API responses use a standard envelope format:
{
"success": true,
"data": [ ... ],
"meta": {
"page": 1,
"per_page": 25,
"total": 142,
"total_pages": 6
}
}
// Error response:
{
"success": false,
"error": {
"code": "VALIDATION_ERROR",
"message": "entity_id is required",
"details": { ... }
}
}
| Endpoint Category | Limit | Window |
|---|---|---|
| Transaction Ingest | 10,000 requests | Per minute |
| Screening | 500 requests | Per minute |
| General API | 1,000 requests | Per minute |
| Authentication | 20 requests | Per minute |
Rate limit headers (X-RateLimit-Remaining, X-RateLimit-Reset) are included in all responses.
SJULTRA provides dedicated support for all Sentinel deployments. Our team includes compliance engineers familiar with CBN regulations and technical staff experienced with Nigerian banking infrastructure.
| Channel | Contact | Response Time |
|---|---|---|
| Partnerships / General | partners@sjultra.ng | Within 24 hours |
| Technical Support | support@sjultra.ng | Within 4 hours (business days) |
| Sales / Licensing | sales@sjultra.ng | Within 24 hours |