Every wallet faces the same apparent contradiction on its first day. Make onboarding strict enough to satisfy a regulator and most people abandon it before they finish — the unbanked customer you are trying to reach has no utility bill to upload and no patience for a branch visit. Make it loose enough to grow fast and you become a money-laundering vector, and the central bank that gave you a licence takes it back. Treated as a single dial between "open" and "controlled," this is a problem with no good setting.
The resolution is not to find the perfect point on that dial. It is to realise the dial is the wrong model. The right model is tiered, risk-based KYC, where access scales with verification, and where the limits are enforced by the ledger rather than promised by the app. Designed this way, open access and strong control stop being opposites.
Why "risk-based" is the phrase that matters
The regulatory frameworks that govern mobile money — and the FATF guidance most of them descend from — do not actually demand that everyone clear the same identity bar. They demand that the controls be proportionate to the risk. A wallet that can hold a few dollars and send a few dollars a day is a low-risk instrument; demanding a passport to open one is both bad business and, in inclusion-focused regulation, often explicitly discouraged. A wallet that can move large sums across borders is a high-risk instrument and warrants full verification. Risk-based KYC simply aligns the verification you require with the capability you grant.
This reframing is liberating. You are no longer trying to set one threshold that is simultaneously welcoming and safe. You are building a staircase: easy to step onto, with each higher step requiring — and unlocking — more.
Three tiers, by example
A typical, regulator-friendly structure looks like this. The exact numbers are set per market with the local regulator; the shape is what travels.
- Tier 1 — Basic. Open a wallet with nothing but a phone number, verified by SMS. Capped to low per-transaction and low daily and balance limits. This is the inclusion tier: anyone with a SIM can start in under a minute, and the tight limits are what make minimal verification acceptable to the regulator.
- Tier 2 — Verified. Add a government ID — a number, a photo of the document — to raise the ceilings to everyday-life levels. Most active customers live here.
- Tier 3 — Full. ID plus a selfie matched against the document, reviewed in-app, unlocking full limits and the higher-value services. This is the tier that supports serious volume, and it carries the verification a regulator expects of serious volume.
The customer experience this produces is the one you want: frictionless to begin, with verification requested exactly when the customer's own behaviour — wanting to send more — creates the need for it. Nobody is asked for a passport to receive their first ten dollars.
The principle that makes it real: limits live in the ledger
Here is where most KYC designs quietly fail. They define the tiers correctly and then enforce the limits in the wrong place — in the app, as a disabled button or a client-side check. That is not enforcement; it is a suggestion. Anyone who can reach the API directly, or use a modified client, can ignore it.
A limit a customer can exceed is not a limit. It is a label.
In a correctly built system, the tier ceiling is an invariant enforced by the ledger, checked inside the same atomic operation that would post the transaction. A Tier 1 customer attempting to exceed their daily cap does not get a polite refusal in the UI — the money movement is rejected at the point it would occur, on every channel, because the rule lives where the money lives. The app's job is to make the rule visible and pleasant; the ledger's job is to make it true. KYC tier becomes a property of the account that the core consults on every transaction, not a screen the customer passed once.
Above the tiers: the AML layer
Tiers govern how much a verified customer can do. They do not, by themselves, catch a verified customer behaving like a launderer. That is the job of the anti-money-laundering layer sitting above the tiers, and a regulator will ask about all of it:
- Sanctions and PEP screening. New and existing customers are screened against sanctions lists and politically-exposed-person lists, with hooks to re-screen as those lists change. A match is flagged for review, not silently blocked or silently allowed.
- Velocity and threshold rules. Patterns matter as much as amounts. A flurry of just-under-the-limit transactions, a sudden change in behaviour, structuring across accounts — these are surfaced by rules that watch the flow over time, not just the single transaction in front of them.
- Suspicious activity handling. When something trips a rule, it has to go somewhere — a queue, a reviewer, a decision, and where required, a report to the financial intelligence unit. A flag with no workflow behind it is a liability, not a control.
A worked example of tier limits
The numbers below are illustrative. Real limits are agreed with the regulator and differ by market, but the proportions are typical.
| Tier | Verification | Single transaction | Daily total | Maximum balance |
|---|---|---|---|---|
| Tier 1 — Basic | Phone number, name | Low (e.g. 10,000) | Low (e.g. 20,000) | Low (e.g. 50,000) |
| Tier 2 — Verified | Government ID | Medium (e.g. 70,000) | Medium (e.g. 150,000) | Medium (e.g. 300,000) |
| Tier 3 — Full | ID plus selfie match and review | High (e.g. 150,000) | High (e.g. 500,000) | High (e.g. 1,000,000) |
Three checks happen on every transaction: the single amount against the per-transaction limit, today's total against the daily limit, and the resulting balance against the maximum. Each check runs in the core, at the moment money would move, on every channel.
Designing the upgrade journey
Tiers only work if moving up is easy. The best moment to ask for more verification is the moment a customer hits a limit, because that is when they understand why it matters. A good upgrade journey:
- explains the limit in plain words at the point it is reached, and says what the next tier unlocks;
- lets the customer start the upgrade immediately in the app, or points them to the nearest agent;
- tells them how long review takes, and notifies them when it is done;
- keeps what they have already submitted if something needs to be redone, rather than starting over;
- records who reviewed the upgrade and on what evidence, for the audit trail.
Agent-assisted onboarding
In many markets, most wallets are opened at an agent, not in an app. Agents can capture ID details and photos, and in some frameworks they perform the verification on the provider's behalf. That makes agent onboarding powerful and risky. Controls that work: the agent's own identity is recorded on every registration they perform; the provider reviews a sample or all registrations centrally; unusual patterns, such as many registrations with similar details or immediate high-value activity, are flagged; and agents who register fraudulent accounts lose commission and, if necessary, their agency.
Common KYC design mistakes
- Asking for everything up front. Customers abandon onboarding, and the ones you most want to include are the first to leave.
- Enforcing limits in the app. Limits must live in the core, or they are suggestions.
- No re-verification. Documents expire and circumstances change. Plan for periodic reviews of higher-tier customers.
- Treating a screening match as a verdict. Most sanctions and PEP matches are false positives. They need review, not automatic rejection.
- Losing the evidence. A verification you cannot show a regulator did not happen, as far as they are concerned.
The audit trail is the deliverable
When a regulator examines you, they are not really testing whether you have rules. They are testing whether you can prove what happened — who was verified to what tier, when, on what evidence; which transactions were screened; what was flagged and what was decided. This is why the immutable, append-only ledger discussed in the engineering literature is also a compliance asset. Because history is never rewritten, every verification, every limit check, every reversal leaves a permanent, ordered, queryable record. Regulator-ready reports are then a view over that record, not a scramble to reconstruct a story after the fact.
Data residency and who owns the relationship
One more dimension a regulator increasingly cares about: where the customer data lives and who controls it. A platform that pools every operator's customers into one shared database creates a data-sovereignty problem the moment a regulator asks for it. The cleaner model — and the one regulators are more comfortable with — is per-operator deployment: each institution runs its own instance and its own database, so customer data stays with the licensed entity that owns the relationship and answers for it. Compliance is not only about controls; it is about jurisdiction, and architecture decides jurisdiction.
Compliance as an enabler, not a brake
The instinct is to treat KYC and AML as a tax on growth — friction to be minimised. Designed as a single strict gate, that is exactly what they are. Designed as risk-based tiers enforced by the ledger, with a real AML layer and an audit trail above them, they become the opposite: the thing that lets you onboard the unbanked in a minute and keep your licence as you scale. The two goals stop competing, because each tier earns the trust the next one requires.
Remote verification done well
Where the rules allow onboarding in the app, the quality of remote checks decides how far customers can go without visiting an agent. Good practice includes clear guidance on taking a photo of the document, automatic checks for blur and glare before submission, a live selfie rather than an uploaded photo, comparison of the selfie with the document photo, and a human reviewer for anything the automatic checks cannot decide. Each step should tell the customer what is happening and how long it will take. Rejections should explain what to fix, so a genuine customer can succeed on the second attempt.
Protecting identity documents
KYC creates one of the most sensitive data sets a company can hold: ID numbers, document photos and faces. Data protection laws across Africa increasingly set rules on how it is collected, stored and shared. Store documents encrypted, restrict access to the staff who need it, log every view, keep documents only as long as the law requires, and make sure customers know what you hold and why. A breach of identity data harms customers for years, because unlike a password, a face or an ID number cannot be changed.
Measuring onboarding
| Metric | What it tells you |
|---|---|
| Completion rate by step | Where customers give up during sign-up |
| Time to upgrade | How long it takes to move from Tier 1 to Tier 2 or 3 |
| Share of customers per tier | Whether limits fit how people actually use the wallet |
| Rejection rate and reasons | Whether guidance is clear, and whether fraud attempts are rising |
| Screening alerts and outcomes | How many matches are true, and how fast they are resolved |
These numbers help in conversations with regulators too. Showing that tiers are working as designed, that upgrades are reviewed and that alerts are closed on time is the best evidence that a risk-based approach is being run responsibly.
Business and agent KYC
Merchants, agents and corporate clients go through their own verification, often called know-your-business. The logic is the same risk-based staircase: a market trader can start with a personal ID and low limits, a registered shop adds business registration, and a company that pays hundreds of staff provides its registration documents, directors and beneficial owners. Agents carry extra obligations because they onboard customers and handle cash, so their checks usually include premises, trading history and a signed agency agreement. Limits and permissions for each business tier live in the core, exactly as they do for customers.
Designing tiers with the regulator, not for them
The strongest tier designs are agreed with the regulator early, not presented at the end. Share the proposed tiers, the limits, the evidence required at each level and the monitoring above them, and ask for feedback before building the onboarding journey. Show how limits are enforced in the core and how exceptions are reviewed. Regulators who understand the design are more likely to approve it, and more likely to support adjustments later, such as raising Tier 1 limits once data shows the risk is low.
Frequently asked questions
Can a customer open a wallet without any ID?
In many frameworks, yes, at the lowest tier with tight limits, verified by phone number. The regulator decides whether this is allowed and what the limits are.
What happens when a customer's ID is rejected?
They stay at their current tier and are told why, with a way to try again. The rejection, the reason and the reviewer are recorded.
Do tiers apply to agents and merchants?
Yes, in a similar way. Business accounts are usually tiered by the documents they provide, from a personal ID for a micro-merchant to company registration and beneficial-owner details for larger businesses.
How often should customers be re-verified?
Low-risk, low-tier customers rarely need it. Higher tiers are usually reviewed periodically, when documents expire, or when behaviour changes sharply. The schedule is part of the risk-based approach agreed with the regulator.
Can limits differ by channel?
They can, but it is rarely wise. If USSD or an agent channel has looser limits than the app, fraud moves to the looser channel. Keeping one set of limits per tier, enforced in the core for every channel, is simpler to explain and to defend.
PesaBridge builds compliance into the core — configurable tiers with ledger-enforced limits, screening and velocity hooks, an immutable audit trail, and per-operator data residency — so growth and control are designed together, not traded off against each other.
