The enterprise user manual for the Kupinga anti-fraud platform.

Sign-in page

The sign-in page is the only unauthenticated surface in the application. Every other URL redirects here when no session is present, preserving the deep-link as a ?next= parameter so the user is sent back to the requested page after authentication.

Key fields

How to sign in

1. Open the URL provided by your administrator. The address may differ between staging and production environments.
2. Enter your work email and password, or click Continue with SSO if your institution uses single sign-on.
3. If your account is provisioned with multi-factor authentication, complete the MFA challenge.
4. You will land on your role-appropriate home page — analysts on the Unified Inbox, executives on the My Dashboard, compliance officers on the Compliance Dashboard.

Common issues

• Account is locked. Five consecutive failed sign-ins lock the account. An administrator must unlock it from Users & RBAC; the manual procedure is documented in that section.
• SSO button does not appear. OIDC is disabled for your environment. Use the password form.
• You are redirected back to /login after submitting. Your session expired before the redirect completed. Sign in again — the deep link is preserved.

Forgot password

If you have forgotten your password, request a reset link. The platform issues the same generic response whether the email is registered or not, so attackers cannot enumerate accounts by status code.

1. From the sign-in page, click Forgot password?.
2. Enter your work email and submit.
3. Check the email account for the reset link. The link expires after the duration configured in SLA policy (default 30 minutes).
4. Follow the link to set a new password.

Sessions, shifts and timeouts

Your session has two clocks. The first is the security clock: the access token rotates silently every few minutes and expires after the maximum lifetime configured in the SLA policy. The second is the operational clock: the active shift. Analysts work in shift windows so the institution has a clear chain of custody and the system can route alerts to whoever is actually on duty.

You will see a banner across the top of every page when your shift is within ten minutes of ending. The banner links to the End-of-shift form so you can complete your handover before you sign out.

My Dashboard

Purpose

One personal landing page that adapts to the user's role and shows what matters most to that audience without a configuration step.

Audience

Every signed-in user. No permission gate at the link itself.

When to use

First page of the day. Quick reset between deep investigations. The place to go when an alert tab has been open for too long.

My Dashboard is the institution's standard personal home page. Rather than presenting one generic dashboard to everyone, it picks one of four curated variants based on the signed-in user's role and permission set, so a compliance officer never has to skip past analyst counters and an analyst never has to scroll past board-level KPIs.

How the variant is chosen

The page reads /api/v1/me on mount and applies the following resolution order — the first matching rule wins:

Variant 1 — Executive (admin)

For users with system:admin or the admin role. Renders the same content as /dashboard — portfolio-level KPIs across every channel: Agency, Internet, Mobile, ATM, POS, USSD & NIP. Captured below with a logged-in admin so every band is populated with real data; the distinguishing feature from the standalone Executive Dashboard is that the left navigation highlights My Dashboard (not Executive Dashboard) — confirming the user landed on their personal home page.

Variant 2 — Compliance

For users with the compliance_officer role or audit_log:read. Renders the same content as /compliance — the SAR/STR pipeline, the regulator schedule and the compliance calendar.

Variant 3 — Analyst

For users holding alerts:read or cases:read but not the elevated permissions above. The page answers a single question: "what is on my plate right now?"

Variant 4 — Viewer welcome

For accounts that hold no analyst, compliance or admin permission — API integration accounts, observers, partner read-only users. Instead of rendering an empty dashboard, the page shows a welcome card and only the quick links the user's permissions actually let them open.

Common chrome on every variant

• Shift-end banner. The orange banner at the top of every page appears when the analyst's shift has less than ten minutes remaining and links straight to End-of-shift. It is dismissable per page but the shift clock keeps ticking and the banner returns on the next navigation.
• Active navigation marker. "My Dashboard" in the left rail is highlighted in Kupinga blue while the user is on this page.
• Real-time updates. Analyst counters refresh on the WebSocket alert/case events; the executive and compliance variants refresh on their own polling intervals (default 30s).
• Empty states. Every tile that has nothing to show explains why. Empty is never the same shape as broken.

How to use it well

1. Land here first. Treat it as the homepage — the shape of what you see tells you what kind of day you have ahead.
2. Trust the chips. The on shift / analyst chips top-right of the analyst variant reflect your current state, not what you logged in as — if you handed shift but did not sign out, this is how you confirm.
3. Open one thing. Don't bounce between the Quick triage shortcuts. Open the inbox or pull the next alert and finish it before coming back.
4. Use the personal SLA tile as your priority signal. A 0% personal SLA in the analyst variant is the loudest warning the platform makes about you personally.

Permissions reference

Operational notes

• The route itself is gated by the same outer permission group as the rest of the Insights/Operations rollup. A principal who somehow has no permission in that family will see an "Access denied" card rather than the dashboard.
• The analyst variant's "My open alerts" list shows your assigned alerts only — not everything in the queue. Use the Alerts queue to pull from the queue.
• Counters can lag behind the real database by up to one polling cycle (30 seconds) during high-traffic periods. If two counters disagree, refresh the page.
• "Personal SLA = 0%" with breaches > 0 means every one of your assigned items has missed its SLA. This is a coaching signal — talk to your team lead before continuing.

Unified Inbox

Purpose

One queue that aggregates alerts, pending blocks, SAR reviews, handovers and notifications.

Audience

Any role with inbox:read. Analysts especially.

When to use

The first thing you open. Triage everything that needs your attention without switching pages.

Why this exists

Without the Inbox, an analyst would have to check four separate queues every morning — alerts, block approvals, SAR reviews waiting for sign-off and overnight notifications. The Inbox merges all of them into one ranked list so nothing is forgotten. Items are sorted by SLA proximity and severity.

Key actions

• Click an item in the left column to focus it. The middle pane shows the workspace; the right pane shows context (history, related cases, similar items).
• Press j / k to walk through items without taking your hands off the keyboard.
• Decide, escalate or hand off from the action bar. Every decision lands in the Audit log immediately.

Permissions

Visibility of an item is gated by the underlying resource permission — an analyst without sars:read will not see SAR review items in the Inbox even if they otherwise have inbox:read.

Alerts queue

Purpose

Stream of all fraud alerts awaiting triage, with filters, queues, and SLA bands.

Audience

Anyone with alerts:read.

When to use

Every shift — this is where alerts that have not yet been picked up live.

Key columns

How to triage an alert

1. Filter the list to My Queue or to the queue you are working today.
2. Click the alert ID to open the Alert detail page.
3. Review the rationale strip and the underlying transaction.
4. Pivot to Customer 360 for context if the alert is not self-evident.
5. Decide: Approve, Decline, Escalate to case, Step-up customer, or Block.

Filters

Business rules

• Alerts are deduplicated by the platform — repeated firings against the same underlying activity within a configurable window are folded into one row to keep the queue scannable.
• SLA budgets come from the SLA policy — critical alerts default to 15 minutes; lower priorities have longer budgets.
• Decisions are append-only — the audit trail records every state change with the analyst's identity, the timestamp, and the rationale, and cannot be edited.

Alert detail & review

The alert workspace is where most of the daily decisions are made. It surfaces the underlying transaction, the rule rationale, the customer profile, the device and channel signals, and the buttons that record the decision.

Decisions available

Common mistakes

• Approving an alert without leaving a rationale in the comment thread. Future audits cannot reconstruct why the decision was made.
• Escalating to case when a step-up challenge would have resolved the suspicion in two minutes.
• Decline-then-undo loops. The platform tracks these and the analyst's quality score drops — repeated occurrences trigger a coaching review from the team lead.

Cases list

A case is the durable container for an investigation. It holds alerts, transactions, customers, evidence, comments, decisions, and any SAR or block raised from it. The Cases list is the queue of investigations that are not yet closed.

Case lifecycle

Cases progress through a fixed state machine: New → In review → Awaiting customer → Pending closure → Closed. The state machine is rendered visually on the State machine view page.

Filters

• Owner — your cases vs the team's vs unassigned.
• State — only New, only In review, etc.
• Scenario — group by the originating rule or model.
• SLA — surface cases that are about to breach.

Case detail

The case workspace is where an investigation is built. It has tabs for the summary, the linked alerts, the transactions of interest, the customer profile, the evidence locker, and the activity timeline.

Key actions

• Link items. Drag alerts and transactions into the case to build the evidence pack.
• Comment. Every comment is timestamped and signed; comments cannot be edited or deleted (only flagged).
• File a SAR. Open the SAR wizard pre-populated with the case data — the regulator's narrative is the case timeline.
• Place a block. Opens the block request form pre-filled with the case context.
• Hand over. Park the case for the next shift with a structured note — see Handovers.
• Close. Confirmed fraud, not fraud, or insufficient evidence. Closure is irreversible by analysts — reopening requires a team lead.

Customers search

A search-first hub for finding a customer by name, customer number, BVN, email or phone. The page intentionally renders no rows until the user has searched — the customer base is too large to list and a fishing expedition is not a valid use case.

Result columns

• Customer — display name and email; click to open Customer 360.
• Customer number — institution identifier.
• BVN — masked unless the analyst has elevated PII access.
• KYC tier — Tier 1, 2, or 3.
• Risk — composite score with risk-tier badge.
• Status — Active, Restricted, PND, Closed.

Customer 360

The single most-loaded page in the platform during an active investigation. Every fact the platform knows about the customer — identity, KYC, accounts, transactions, alerts, cases, challenges, screening hits, adverse-media verdicts, blocks, network neighbours and behaviour over time — is gathered here under one set of tabs.

Tabs

Common actions

• Export dossier. Top-right button. Produces a regulator-ready PDF of the entire 360 view.
• Ad-hoc screen. Run the customer against sanctions / PEP / adverse-media on demand.
• Trigger challenge. Step the customer up with OTP, callback or video proof of life.
• Request a block. Pre-populates the block form with this customer and the case context.

Transactions

The cross-customer transaction explorer. Used when the question is "show me every transaction matching X" rather than "show me what this customer did". Filters span channel, amount, time, currency, counterparty and decision outcome.

Filters

Filters are persistent for the session — switching pages does not lose them. Channels (POS, NIP, RTGS, USSD, mobile, internet, agent, ATM) colour-code the results so a scan reveals channel concentration at a glance.

Transaction detail

Purpose

Single, printable, regulator-ready view of one transaction across every dimension that matters during an investigation.

Audience

Anyone with transactions:read — analysts during triage, compliance during SAR drafting, audit during a regulator visit.

When to use

Whenever a single transaction is the unit of work — confirming an alert rationale, attaching to a case, exporting as evidence.

The Transaction detail page is reached three ways: by clicking a row in the Transactions list, by following the underlying-transaction link from an alert, or by pasting a transaction reference into the global search bar. The same page is rendered for every channel — POS, NIP, RTGS, USSD, mobile, internet, agent, ATM — and adapts its content to whichever signals the channel produces, instead of duplicating the layout per channel.

Layout

The page is a sticky-header workspace above a Radix-style accordion. Every accordion section is open by default so the analyst sees the whole transaction in one scroll; sections can be collapsed individually to skim, and the print stylesheet forces all sections open regardless of state so the printable evidence pack is always complete.

Header — the at-a-glance row

The header strip is sticky on long-scroll so the transaction reference, status and amount remain visible while the analyst reads through the rest of the page.

The seven accordion sections

How to use

1. Read the Overview first. For a NIP transfer, check the Name Enquiry result; for POS, check the auth code and the entry mode; for RTGS, read the narration.
2. Confirm the Source belongs to the customer on the alert. A mismatch here is itself a finding.
3. Look at the Destination. Click the destination customer link if it is internal; check the counterparty bank if it is external.
4. Open Linked entities to see which alerts fired on this transaction and the analyst decisions already recorded.
5. Decide. From this page you can pivot to the alert, the case, the source customer or the destination customer; you can attach the transaction to a case; or you can print the evidence pack.

Actions

Permissions & PII

The page requires transactions:read. NUBAN and BVN fields are masked by default; analysts with customers:read_pii see the unmasked value and every unmask is recorded in the Audit log. Raw-payload PII follows the same rule — sensitive fields inside the JSON are masked in the rendered preview but the unmasked value is available in the copied clipboard text only when the elevated permission is held.

Operational notes

• One canonical record per transaction. A reversal does not produce a second transaction — the platform reuses the same record and updates the status. The Balances section flips to show the reversed direction.
• NIP session ID is the high-signal join key. When an analyst pivots between this page, the Network Explorer and the consortium feed, NIP session ID is the field most likely to match.
• Print is the regulator-ready export path. The PDF produced by the browser print dialog is the format the platform commits to for evidence packs. Custom downloads or screenshot exports are not equivalent.
• Linked entities is the back-pointer. If an alert was raised on a transaction but the analyst opened the transaction first, this is where they find the alert. There is no "no alerts" empty state — the section is hidden entirely when there are none.

Common pitfalls

• Quoting the database id in a SAR instead of the transaction_reference. The reference is institution-issued and customer-recognisable; the database id is not.
• Copying the masked NUBAN out of the rendered text. Use the copy widget — it copies the unmasked value (subject to PII permission) so downstream attachments are usable.
• Closing the Raw payload accordion before printing. The print stylesheet re-opens it automatically, but on-screen review may miss it if collapsed.
• Treating "No additional channel or device metadata" as a bug. For NIP, RTGS and most server-to-server channels this is the normal state.

Network Explorer

A force-directed graph that lays out the customer, the counterparties they have transacted with, the devices used and the accounts touched. The right tool when the investigation is about a ring rather than a single customer.

How to use

1. Seed the graph by typing a customer number, account, BVN, device hash or phone number.
2. Click a node to expand its first-degree neighbours. Repeat to broaden the picture.
3. Use the legend toggles to hide weak edges or filter to a single channel.
4. Copy a node's identifier into the clipboard with the small inline button beside it — useful when pivoting back to Customer 360.

Consortium Intelligence

The shared intelligence feed — typologies, suspicious counterparty wallets, compromised device hashes and emerging tactics — contributed by every Kupinga tenant in anonymised form. Used to spot fraud that another bank already saw, before it spreads.

Compliance dashboard

Purpose

One screen for the SAR/STR pipeline, the regulatory return schedule and the compliance calendar.

Audience

Compliance officers; anyone with audit:read.

When to use

First page of the compliance officer's day. Also useful before regulator visits.

What it tells you

• How many SARs are in each pipeline stage — drafted, reviewed, approved, filed.
• Whether any regulatory return is at risk of being filed late.
• How blocks and challenges are landing this period.
• Upcoming compliance events on the calendar.

SAR / STR filings

The SAR / STR workspace. Drafts are prepared from a case, reviewed by a second pair of eyes, approved by a third, and filed with the regulator. Each step is gated by a separate permission — the standard separation-of-duties pattern that auditors expect.

Lifecycle

1. Prepare (sars:prepare) — Open a case and click File SAR. The wizard pre-fills subject, narrative and attached evidence from the case.
2. Review (sars:review) — A reviewer (not the preparer) reads the draft and either returns it for amendment or moves it to approval.
3. Approve (sars:approve) — An approver (not the preparer, not the reviewer) gives the final sign-off.
4. File — The platform submits the SAR to the regulator's filing endpoint and stores the acknowledgement.

Blocks & freezes

Blocks are restrictive actions placed on a customer's account — Post-No-Debit, transaction freeze, partial restriction or full freeze. Every block goes through a maker-checker flow so no single user can freeze an account on their own (with the exception of explicit emergency-block permissions held by a small group of leads).

Requesting a block

Approval queue

Permissions

Reports catalogue

The catalogue of every report the platform can produce — standing regulatory returns, internal MI, scheduled email-outs and ad-hoc exports. Each report tile shows the last-run timestamp and links to the detail page where you can run it again or schedule it.

Report scheduling

Where regulatory and MI reports are scheduled to run. Schedule by cron, set recipients, choose the delivery channel (email, SFTP, secure download) and the retention policy.

Handovers

Shift work demands explicit handover. At the end of every shift, the analyst documents the open work, blocks the incoming shift will pick up, and any context that did not make it into the case or alert comments. The Handovers page is the durable record of those notes — searchable across shifts and never deleted.

End-of-shift form

The structured form that an analyst fills in before signing out. The platform reminds the analyst to file it in the last ten minutes of the shift.

Screening dashboard

Headline metrics for the screening platform — match volume, hit precision, source freshness, model and matcher status.

Screening console

Operator workspace for the screening engine — engine status, list catalogue, real-time activity. The page folds in what used to be a separate "Sources" tab; it now shows every list source the platform consumes, its last-refresh timestamp, and its current matcher status.

What you can do here

• Force-refresh a list source (where allowed by the source provider).
• Inspect a matcher's behaviour against a sample subject.
• Run an ad-hoc screen by typing a name, BVN or organisation.

Screening history

Searchable history of every screening run — who ran it, against what subject, against which lists, what matched, what was overridden. The regulator-facing audit trail.

Adverse-media dashboard

Feeds

Catalogue of every news and watchdog feed the platform ingests. New feeds can be enabled only through an attestation gate — the operator confirms the feed is licensed for the institution's jurisdiction before traffic flows.

Classifications

Per-mention LLM verdicts. Each row shows the subject, the verdict, the source, the prompt version that produced it, and the citation trail. Verdicts can be challenged — a challenged classification opens a review workflow and is excluded from the subject's profile aggregation while the challenge is open.

Risk profiles

The durable per-subject view. The profile aggregates every classification across time, weighs them by recency and severity, and assigns a risk tier (Low, Medium, High, Critical) used by downstream Customer 360.

Eval set

The labelled corpus that the compliance team owns. New prompt versions are evaluated against the eval set before they are promoted to production. If the eval-set scores drop, the deployment is blocked.

Prompt registry

The hash-pinned prompt registry. Every prompt is stored with its SHA, the model it targets, the eval-set score at promotion, the operator who promoted it and the timestamp. Production traffic always runs against a pinned version — never against a freshly-edited draft.

Executive Dashboard

Purpose

One-screen, regulator-presentable view of the institution's fraud posture across every channel.

Audience

Executives (CRO, COO, Head of Fraud), system administrators, and anyone granted system:admin. Doubles as the My Dashboard landing for these roles.

When to use

Daily review at the start of the morning standup. Before board meetings. When an incident report cites a fraud volume number that needs checking.

The Executive Dashboard is the institution's at-a-glance picture of fraud across every channel the platform monitors — Agency, Internet, Mobile, ATM, POS, USSD & NIP. It pulls live aggregates from the analytics service and renders six bands of cards: Outcome Split, KPI strip, Decision Volume, Channel Mix, Top Rules by Volume and Active Models. The time window is operator-controlled with one click.

Six bands, top-to-bottom

The period selector

Five chips top-right control every band on the page except Top Rules (always 7d) and Active Models (always current). Switching a chip re-fetches the snapshot and trend endpoints in parallel; the existing render stays on screen until the new data lands so the page never flashes blank.

How to read the page

1. Decline rate. Glance at the Outcome Split first. A decline rate above 5% triggers the inline guardrail; an analyst should already be investigating, but the executive needs to know.
2. Movement. Look at the KPI deltas. A +24% week is interesting; a −20% week may signal a broken integration upstream.
3. Where. Read the Channel Mix bars. Concentration on one channel can either be a normal pattern (NIP dominates most days) or a campaign — a sudden shift requires a follow-up.
4. Why. Read the Top Rules card. The rule producing the most hits is the institution's current dominant typology — for the captured snapshot, the velocity-NIP-burst rule (FRD-003) at 18,342 hits is the loudest signal.
5. What's scoring. Confirm the Active Models row. If a model that should be in production is missing, scoring is degraded; if a SHADOW model is producing better numbers than its PRODUCTION counterpart, schedule a promotion.

Permissions & access

• The route is gated by system:admin on the sidebar entry. The underlying /analytics/* endpoints all check audit:read, which is granted by the admin tier and a few other senior tiers; an executive who is not also an admin will see the dashboard through the My Dashboard shortcut.
• Print-ready: the page passes through the platform's print stylesheet so File → Print produces a PDF suitable for board packs without bespoke formatting.
• No PII is rendered. Every figure is an aggregate; no row drills down to a customer. The page is safe to screen-share inside the institution.

Operational notes

• Freshness. The "Updated HH:MM" stamp is the window_end from the snapshot, not the page render time. If the stamp lags by more than a minute, the daily aggregator job may be stuck — check System status.
• Sparkline scale. The Decision Volume chart auto-scales to the data — comparing two windows visually can mislead. Read the headline numbers above the chart for the actual values.
• Top Rules is fixed to 7 days. Changing the period chip does not change the rule window. This is deliberate so the executive always sees the recent typology rather than a stale quarter average.
• Latency tile. P95 latency is decision-pipeline latency end-to-end — not just the model. A sudden P95 spike is usually a databus or rules-service incident; cross-reference Operations health.
• No customer drill-down. By design — this is the portfolio view. To investigate a specific signal, pivot to the Alerts queue filtered by the dominant rule, or the Trend analytics page for deeper time-series.

Trend analytics

Operations health

Risk heatmap

HQ rollup

Role workspaces

Dashboard library

Scenarios

Scenarios are the institution's library of typologies — FRD-001 (profile change followed by high-value transfer), FRD-003 (NIP velocity), FRD-009 (cross-border to high-risk corridor) and so on. Each scenario binds to one or more rules and one or more models; the platform ships ten standard scenarios that cover the common Nigerian patterns out of the box.

Rules

Why rules are versioned, not edited in place

Editing a live rule in place silently breaks every alert that fired against the previous version of the rule — the audit log loses the link between cause and effect. Kupinga therefore versions every rule. Changing logic creates a new version; the previous version is preserved and the active rule pointer is moved.

Create-rule wizard

Purpose

Author a brand-new detection rule through a five-step guided wizard with per-step validation.

Audience

Fraud engineers (system:admin or rules:write).

When to use

When a new typology needs a rule, a new channel needs a tailored detector, or a hard-coded threshold has been validated for production.

The wizard is built so the operator cannot publish a half-finished rule — each step has its own validation gate, and Next stays disabled until the gate passes. The five steps map exactly to what the rules-service stores: basic identity, channel filter, detection logic, risk & routing, and the final back-test gate.

The five steps

How to use

1. Name and describe the rule on Step 1. Tag it with the scenario family (FRD-001, FRD-003 …) so the rule library stays searchable.
2. Pick the channels on Step 2. Channels not selected here are exempt from the rule even if their transactions match the predicate.
3. Build the predicate on Step 3. Use the inline "How to configure a deterministic rule" disclosure for the field catalogue.
4. Set the score, priority, action and reason code on Step 4. The reason code is stamped on every alert the rule fires.
5. On Step 5, run the Historical Test (30 days) and read the projected match volume. If the projection is wildly higher than expected, walk Step 3 back and tighten the predicate.
6. Submit. The rule lands in maker-checker pending approval — a second engineer reviews and promotes.

Manage existing rule

Purpose

Find, inspect and version-edit any rule already in the catalogue. Editing reuses the 5-step wizard so the engineer changes the rule through the same validation gates as the original author.

Audience

Fraud engineers; team leads who promote shadow rules to active.

When to use

Tightening a threshold; adding a channel; pausing a rule that is producing noise; promoting a shadow rule to production; reviewing a rule's version history before a regulator visit.

Rules are versioned, not edited in place. Every save publishes a new rule_versions row; the previous version is preserved and the rule's current_version_id pointer is moved atomically. Every alert produced by a rule remembers exactly which version fired it, so the audit trail never loses the cause-and-effect link.

Entry — the Rules Library

The edit flow — same 5-step wizard, populated

Clicking the Edit affordance on any rule opens /admin/rules/<id>. The page reuses the Stepper from the create wizard, but every step is pre-populated from the rule's current version, and every step in the Stepper is marked complete so the engineer can jump directly to any step they need to change.

Common workflows

Versioning & audit

• Every save publishes a new rule_versions row with change_notes, reason_code and wizard_payload snapshot. The wizard payload makes future edits round-trip cleanly — the structured condition tree is restored verbatim, bypassing the lossy DSL parser.
• Every promotion is recorded in the Audit log as rule.version_promoted, with the actor's email and the from/to version numbers.
• Every rule remembers which alerts it produced and at which version, so the alert detail page can always answer "which exact logic fired this?".

Model registry

Every model that has ever been registered with the platform — production, shadow, candidate, retired — with the version, training metadata, AUC, drift status and the operator who promoted it.

Model monitoring

Explainable AI

Per-decision feature attribution. The regulator-facing view that proves any individual decision can be explained.

Closed-loop feedback

The store of analyst decisions that feed the next training cycle. Every approve/decline lands here with the analyst's identity, the timestamp, the rationale and the underlying features.

Maker-checker

The central record of every change that needed a second approver — rule edits, scenario toggles, model promotions, integration changes, role grants and more. Pending items appear at the top of the page for the relevant approvers.

Fraud → AML

The bridge between confirmed fraud and the AML pipeline. Configures which case outcomes promote into AML monitoring and how the AML team is notified.

Communications

Outbound customer communication templates and the workflows that send them — block notifications, SAR-related outreach, challenge messages. Each template has a localised version per supported language and a per-channel variant (SMS, email, in-app).

Users & RBAC

The user directory — every account, the role tier it belongs to, its status (active, locked, disabled), its last sign-in and its branch/team membership. Administrators provision new users here, unlock accounts after lockouts, and disable users who leave the institution.

Common procedures

• Provision a new user. Click New user, enter their work email, choose role tier, branch and team, save. The platform emails the user an activation link.
• Unlock an account. Find the user, click Unlock. The unlock is recorded in the audit log.
• Disable a user. Disabled users cannot sign in; existing sessions are revoked immediately.
• Grant elevated access. Use Access requests to grant temporary just-in-time permissions; do not assign permissions ad hoc.

Role tiers

Role tiers are bundles of permissions — Junior Analyst, Senior Analyst, Team Lead, Compliance Officer, Compliance Reviewer, Compliance Approver, Risk Officer, Fraud Engineer, System Administrator, Platform SRE. Each tier maps to a fixed permission set; institutions can clone a tier and adjust the permissions for their own policy.

Branches

Teams

Access requests

Just-in-time access. A user requests an elevated permission with a reason, an approver reviews it, and the grant is time-bound — it expires automatically when the window closes. Used for break-glass scenarios, after-hours support, and tightly-scoped audit access.

My access requests

SLA policy

The institution's service-level policy — how long an alert at each priority is allowed to wait, when a case is overdue, when a block must be reviewed. Every SLA band in the platform reads from here.

Bank configuration

Identity of the institution — display name, CBN code, branding, default currency, default timezone, supported channels. Tenants in a multi-bank deployment have one bank-configuration record each.

Scheduled jobs

Customer challenges

Step-up records — OTP, callback and video proof-of-life challenges issued to customers. Used by analysts to confirm a transaction is genuine before approving a high-risk decision.

Challenge plane settings

API keys

Programmatic credentials. Every integration that calls the platform's API does so with a scoped API key — never with a user's session token. Keys are rotated on a schedule and revoked the moment an integration stops being used.

Integrations registry

The single place where every third-party system the platform talks to is registered — sanctions lists, KYC providers, NIBSS, OFAC, NIMC, GDelt, MaxMind, Apicurio Schema Registry, MinIO, comms providers and more. New integrations are added here so the platform always has one place that answers "what are we depending on".

Tenant onboarding wizard

The guided onboarding flow — picks a template, creates the tenant, attaches an adapter, generates a mapping, and validates against a sample payload, in one pass.

Databus ops dashboard

Tenants & adapters

Mapping editor

Per-tenant field mapping from the source-of-record format into the canonical schema. The editor renders the source payload on the left and the canonical schema on the right; the operator draws lines between fields.

Schema registry

Dead-letter queue

Events that failed to parse, validate or process land in the dead-letter queue with the failure reason. Operators inspect, fix the upstream cause, and replay individual events or batches.

Reconciliation

Lineage explorer

For a chosen event, the platform shows where it came from, every transformation it underwent, every decision it informed and every downstream artifact (alert, case, SAR, block) it produced. The auditor's chain of custody.

Databus settings

Simulator runs

Simulator scenarios

Chaos rehearsal

Simulator allowlist

Simulator services

System status

Services control

Start, stop and restart any platform service. Wraps scripts/services.sh on the host. Refuses to run in production environments — production work goes through the institution's change-management process.

Ingestion engine

Batch processing

Workflow queues

Per-queue depth and ageing view. Used by team leads to balance load across shifts and by SREs to spot bottlenecks.

State machine

A visual diagram of the case state machine — useful for training and for explaining the workflow to auditors.

Audit log

Per-entity audit trail. Every change to every entity in the platform — by whom, when, from where, why — is written here append-only. The regulator-facing record.

Access log

Demo data

Seed or reset the demo personas defined in config/demo/personas/personas.yaml. Used to set up the platform for a sales demo, a customer training session or an integration rehearsal.

Notification centre

Inbox of platform-issued notifications — assignments, mentions, SLA warnings, system advisories. Always reachable from the bell icon in the top bar.

Notification preferences

Settings hub

The user's personal settings — name, language, timezone, default landing page, keyboard preferences, two-factor enrolment. Permission-gated tiles for administrative settings appear here only for administrators.

Permissions reference

A non-exhaustive listing of the most commonly assigned permissions and what they enable. The canonical source of truth is Role tiers, where the institution-specific bundles live.

Glossary

Support & escalation

If you hit a problem you cannot resolve from this manual, escalate in this order:

1. Your team lead. Day-to-day operational questions (workload, queue routing, decisions you are unsure about).
2. Your institution's system administrator. Access problems (locked account, missing permission), bank-configuration questions, role-tier questions.
3. Platform / SRE. Health questions, service status, ingestion lag, DLQ growth, suspicious behaviour.
4. Kupinga support. Bugs, feature questions, integration help. Reach out through the channel agreed in your support contract.

Always include in any support request:

• The URL of the page you were on.
• The exact error message, if any.
• What you were trying to do, in one sentence.
• The time the issue happened, with timezone.
• Your user identifier (visible in the top-right user menu).

For incidents that affect customer service, follow your institution's incident-management procedure rather than this manual.