Everything you need to evaluate Kupinga.

Kupinga is a real-time fraud detection and anti-money-laundering platform for banks, microfinance institutions and fintechs. It evaluates every transaction as it happens, applies rules, machine-learning models and sanctions / adverse-media screening in parallel, and returns an approve, review, decline or step-up decision in under 100 milliseconds.

Three audiences inside a financial institution:

• Fraud and compliance analysts who investigate alerts, work cases, file SARs and respond to disputes.
• Compliance officers and risk leadership who need maker-checker on every destructive action, a full audit trail and dashboards by branch or business unit.
• Engineering and operations teams who integrate the platform with the core banking system, switch processors and channel back-ends.

Traditional fraud monitoring runs after the fact. By the time an alert is investigated, the money has already moved. Kupinga is built around the opposite assumption: the decision is made before the core banking system commits the transaction. Investigations, SAR filings and customer outreach become exceptions, not the daily workflow.

Three differences, in plain terms:

• Inline, not after-the-fact. Decisions are returned in the response to the authorisation call.
• Bank-owned data, bank-owned credentials. Kupinga does not act as a broker between the bank and NIBSS, and does not stage the bank's customer data on a vendor cloud.
• Audit-grade by default. Every decision, every change and every operator action is recorded in a tamper-evident hash chain. Maker-checker is enforced on destructive actions, and the role templates ship with the product rather than being assembled by the customer.

Account takeover, social-engineering and authorised push-payment fraud, card-present and card-not-present fraud, agent-banking abuse, mule networks, sanctions and PEP exposure, structuring, smurfing, layering, and other money-laundering typologies. The platform ships with detection scenarios for each, all of which can be tuned per institution.

POS, ATM, NIP, RTGS, intra-bank, mobile app, internet banking, USSD and agent banking. Each channel has its own latency SLO and its own step-up dispatcher (OTP, push, SMS, in-app proof, biometric liveness).

Every transaction is scored by six parallel signal stages inside a single per-request budget: compiled rules, velocity counters, list membership, machine-learning models, sanctions / PEP screening, and adverse-media classification. The first hard-deny short-circuits the rest. A unified decision-maker combines the signals into one of four outcomes: approve, review, decline or challenge.

Yes. Rules are authored through a domain-specific language with a wizard in the admin console. Every rule can be deployed in shadow mode first, so analysts see what it would have done on real traffic before it is ever enforced. Rule changes go through maker-checker.

Yes, all three, and each has its own dashboard, disposition workflow and audit trail. The screening sources are pluggable so a bank can use its existing list provider, the consortium feed or a combination.

Yes, for NIP Name Enquiry, BVN Validation, the Industry Fraud Database and the IPS Settlement Switch. The platform uses the bank's own institutional NIBSS credentials rather than acting as a regulatory broker. A NIBSS sandbox adapter is included for pilots and evaluations.

Through a dedicated, multi-protocol ingestion gateway. The bank's existing switch or message bus is pointed at the gateway. We do not expect the core banking system to call a single REST endpoint on the open network. Supported protocols include inbound webhooks, ISO 8583 (POS and ATM), ISO 20022 (RTGS, SWIFT, NIBSS Instant Payments), native Kafka consumption, REST polling, read-only SQL tail-ingestion and SFTP file drops.

No. On-premises deployments are outbound-only by default, with the firewall whitelist restricted to NIBSS endpoints and NTP. Inbound traffic from the bank's core systems uses the existing private network.

A typical bank pilot takes four to eight weeks. Week 1: infrastructure stand-up and Vault seeding. Weeks 2 to 3: ingestion-adapter configuration and shadow-mode traffic. Weeks 4 to 6: rule tuning, analyst training, sandbox sign-off. Weeks 7 to 8: production cutover with monitored rollout. Banks with mature CBA integrations have gone live in as little as three weeks.

Two channels, neither of which lets Kupinga write directly to the bank's ledger:

• Synchronous. When the CBA calls the evaluate endpoint, the response carries the decision (approve, review, decline, challenge). The CBA enforces it locally.
• Asynchronous. When a compliance officer issues a Post-No-Debit, the platform publishes a signed event through a transactional outbox. The CBA subscribes and applies the lien on its side. Both sides write to an audit trail.

Yes. The native Kafka consumer adapter binds to your existing topics, and the outbound event stream can publish back to your bus. No new bus is required.

The per-channel service-level objectives are ≤100 ms p99 on POS, ATM, NIP, RTGS, intra-bank, mobile app and internet banking, and ≤200 ms p99 on USSD and agent banking. We commit only to figures we can hold under genuine peak load, and we report them in writing every quarter.

The detection tier scales horizontally on commodity virtual machines, so capacity is a question of how many VMs the bank wants to run, not whether the platform can keep up. The database is the only stateful tier and is sized to the bank's transaction-history retention policy. Sizing is part of every pilot scope.

That is a policy decision the bank makes. The CBA can be configured to fail open on Kupinga unavailability and queue the transaction for asynchronous review, or to fail closed for high-risk channels. The platform itself is designed for high availability with a warm-standby replica option; the specific availability target is set in the contract.

Yes, and on-premises is the default for commercial banks. The platform runs entirely inside the bank's firewall on standard Ubuntu virtual machines, with no Docker and no Kubernetes. A typical single-bank footprint is four virtual machines, plus a dedicated PostgreSQL host.

Yes. A managed multi-tenant service runs from a sovereign Lagos region, primarily for microfinance institutions and fintechs that prefer not to operate the infrastructure themselves. It is the same product as the on-premises build; only the tenant-resolver middleware differs.

No. Every service is a static Go binary supervised by systemd. We made this choice for three reasons: a smaller attack surface, simpler operator hand-off, and removal of the orchestration tier from the on-premises bring-up.

On-premises deployments store data on the bank's own infrastructure, never on a vendor cloud. The managed SaaS tier stores data exclusively in our Lagos sovereign region with cross-border egress disabled by default.

Yes. The on-premises mode keeps all personal and transactional data inside the bank's environment. The managed tier keeps data inside Nigeria. All credentials and PII peppers are held in HashiCorp Vault, with quarterly rotation. The platform never appears as a data controller for the bank's customer records.

From a bare virtual machine to a validated platform takes a few hours. The bring-up is fully scripted: cloud-init hardens the VM, the signed bundle installs every service, the bootstrap script initialises Postgres, Redis, Kafka, Vault and Nginx, and a validation script asserts every boot invariant before declaring the platform ready.

All credentials, JWT signing keys, NIBSS API keys and the BVN pepper are held in HashiCorp Vault. No secret ever appears in a configuration file, in an environment variable that survives a process restart, or in source control. Vault reachability is a boot invariant: the platform refuses to start if Vault is not reachable.

Yes. Every decision, every administrative action and every operator action writes a row into a tamper-evident audit chain: HMAC-SHA-256 over the canonical record, with quarterly secret rotation. A broken link is detectable, a missing row is detectable, reordering is detectable.

Yes. The platform ships with six seeded role templates and approximately sixty fine-grained permissions across ten namespaces. The seeded roles are Administrator, Senior Analyst, Analyst, Compliance Officer, Viewer and a machine-to-machine API User. Banks customise the role templates freely after install.

Yes, that is the default seeded posture. The standard Analyst role has full read access to alerts, cases, transactions and rules, but carries none of the administrative permissions. The administrative navigation is not rendered for an analyst session. The restriction is enforced at three independent layers: the HTTP edge, the UI render, and the database query scope.

Yes, on every destructive administrative action: granting a role, lifting a regulatory block, changing a webhook destination, replaying an outbox row. The action requires a different user with the approver permission to confirm it. Both identities are captured in the audit chain.

Encryption in transit is TLS 1.3 between every service. Encryption at rest covers raw ingested events (AES-256-GCM with a Vault-managed key) and the database (Postgres-native disk encryption on supported storage). PII peppers are quarterly-rotated through Vault with dual-hashing for the rotation windows.

The alert-detail page shows the triggering transaction, the rule explanation tree, screening matches and related alerts. One click opens the Customer 360 workspace: a thirteen-tab unified view that aggregates the customer's historical transactions, alerts, cases, screening hits, adverse-media mentions, blocks, counterparty network, behavioural baselines and a full event timeline. The analyst never runs a secondary query to assemble baseline context.

The aggregate endpoint returns in under 80 milliseconds at the 99th percentile, even for customers with millions of historical transactions.

No. Kupinga is a desktop-first web console built for the Security Operations Centre. There is no companion iOS or Android application for analysts to install.

Yes. Cases support free-text notes with mentions, structured handovers with a checklist, and an end-of-shift form that summarises open items for the incoming shift. All notes are immutable and audit-chained.

Yes. The underlying organisational-unit record accepts any type label (branch, department, business unit, agency, service centre) without code changes. A per-deployment terminology configuration also renames the UI labels globally, so "Branch" reads as "Department" everywhere: sidebar, filters, exports, audit messages and regulatory reports.

Yes. The branding service supplies a display name, legal name, logo, primary colour and terminology map per deployment. The same mechanism is used today to localise "Customer" to "Member" in credit-union deployments.

Yes. The model registry supports importing externally-trained models alongside our shipped baselines. Imported models go through the same shadow-mode, monitoring and explainability pipeline as in-platform models.

Pricing scales with monitored transaction volume rather than per-user, so adding more analysts never inflates the bill. On-premises is sold as an annual licence with optional support tiers; the managed tier is a flat monthly fee per institution with volume bands. There is no separate mobile module to opt into or out of. Contact us for a quote.

Yes. Every evaluating institution receives access to a hosted sandbox with a NIBSS sandbox adapter, seeded test data and a transaction simulator. Evaluators can submit realistic payloads and watch the engine decide in real time before any production integration begins.

A standard pilot is four to eight weeks: bring-up, shadow-mode ingestion, rule tuning, analyst training, sandbox sign-off, then a monitored production cutover. Faster timelines are possible when the bank's CBA integration is mature.

Every licence includes 24×7 incident response with a one-hour SLA on Severity 1, business-hours support for Severity 2 and 3, quarterly release upgrades and on-call assistance for migrations. Banks with strict change-control requirements can defer upgrades and stay on a long-term-support release.

Yes. Every deployment includes role-based onboarding sessions for analysts, senior analysts, compliance officers and administrators. A written operator manual ships with the platform; we keep it updated release by release at /manual.

Book a meeting through the form on the home page, or email us directly. A 30-minute technical walk-through is the usual starting point; from there we run a structured evaluation against a checklist your team supplies.