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.
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.
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.
