Digital Wallets & Super Apps

Compliance infrastructure built for digital wallets and super apps

Digital wallets move money at speeds and volumes that manual compliance cannot track. Fintegrity sits in-line before every debit and credit — enforcing KYC tiers, monitoring velocity patterns, catching mule behaviour, and generating regulator-ready evidence automatically. Before money moves.

The wallet compliance problem

Four fraud patterns wallets face every day

Consumer wallets are a prime target for financial crime because they combine high volume, low friction, and — often — weak transaction-layer controls. These four patterns account for the majority of AML exposure in Nigerian digital wallets.

Mule account networks

New accounts are funded and swept within hours of creation. By the time batch monitoring flags it, the funds are gone. Fintegrity's new-account velocity rule catches the pattern in the opening transaction.

How velocity monitoring works

KYC tier bypass

Customers transact beyond their verified limit — sometimes by design, sometimes because tier enforcement isn't wired into the payment handler. Fintegrity enforces tier limits at the decision layer, not in your application code.

How tier enforcement works

Velocity gaming

Fraudsters split transactions to stay under any single threshold. Fintegrity aggregates across rolling windows and counterparties — a set of ten ₦450k transfers reads the same as a single ₦4.5M transfer.

See the rule library

Rapid layering

Funds received and immediately re-sent — often in small amounts to multiple counterparties. Fintegrity's rapid in-out detection and profile anomaly rules flag this pattern before the second leg clears.

See pattern detection
Integration model

One pre-authorisation hook. Complete compliance coverage.

Fintegrity doesn't require changes to your product UX or your payment rails. One API call before each transaction executes is all it takes.

01

Customer initiates transfer

User taps Send in your wallet app. Your backend receives the transaction intent.

02

You call /v1/decide

Before your payment handler executes, you POST the transaction context to Fintegrity. This takes less than 50ms.

03

Fintegrity evaluates

Customer risk state, KYC tier limits, velocity rules, structuring patterns, and account-age logic all run in parallel.

04

Decision returned

CLEAR: proceed. FLAGGED: proceed, case opened. HELD_FOR_REVIEW: hold and open a case. BLOCKED: decline and reverse. Your handler acts on the response.

05

Evidence written

Every decision is logged to the append-only audit store with the full transaction context. Evidence is available instantly for any regulator query.

Wallet-specific rules

Rules shaped to how wallets actually move money

Generic AML tools apply the same rules to wallets, PSPs, and lenders. Fintegrity configures rules around the specific abuse patterns and regulatory exposure of your business model.

Account age

New-account monitoring window

Accounts in their first 30 days get elevated rule sensitivity. New-account velocity — the first sign of mule account abuse — is flagged before the network establishes.

Timing

Rapid in-out detection

Funds received and swept within a configurable window (default: 60 minutes) are flagged regardless of amount. Multiple hops within the window are aggregated.

Tiers

Real-time KYC tier enforcement

Every transaction is checked against the customer's verified KYC tier (T1/T2/T3) and the corresponding limit. Tier breaches get a hard BLOCK before your rails execute.

Splitting

Counterparty aggregation

Transactions to the same counterparty within a rolling window are aggregated and measured as a single economic event — defeating basic threshold-splitting strategies.

Behaviour

Profile-relative anomaly

Each transaction is compared to the customer's 90-day behavioural baseline. A ₦50,000 transaction is very different coming from a customer who typically sends ₦5,000.

Structuring

Sub-threshold structuring

Sequences of transactions that appear designed to stay below CBN/NFIU CTR thresholds are identified using configurable pattern windows.

Regulatory evidence

When the regulator asks, you have an answer

CBN's 2024 directive tied wallet transaction limits directly to BVN and NIN verification tiers. Every transaction above a tier limit is a potential compliance breach — and when a regulator asks, you need to show that your system caught it before money moved.

Fintegrity writes every decision — including every CLEAR — to an immutable evidence store. A regulator asking “how was this transaction handled?” gets a complete answer: what rules ran, what the customer's state was, what decision was made, and when.

  • Every CLEAR is evidenced

    Not just flags and blocks. Every decision is logged. Showing compliance for a clean transaction is as important as showing it for a flagged one.

  • Point-in-time state capture

    The customer's risk state, KYC tier, and rule configuration at the exact moment of decision — frozen in the evidence record.

  • On-demand evidence packs

    Any transaction or customer can produce a complete evidence pack. No reconstruction required.

What Fintegrity stores per decision
Transaction ID, amount, currency, channel
Counterparty identifier and type
Customer risk state at time of decision
KYC tier and applicable limits
Every rule evaluated and its result
Final decision: CLEAR / FLAGGED / HELD_FOR_REVIEW / BLOCKED
Required action issued to your system
Timestamp (server-side, immutable)
Rule version configuration used

See Fintegrity configured for your wallet

We'll walk through a live configuration with transaction patterns, KYC tier limits, and monitoring rules tuned to your specific product and volumes.