Digital Onboarding and eKYC Platforms

Why account opening is where growth leaks

Most institutions lose more customers before the account exists than after it. Someone starts an application, is told to come back with a document, and never comes back. The branch is open at the hours they are at work. The nearest one is in the district town. Every one of those is a person who wanted an account and does not have one, after the cost of attracting them has already been spent.

The comparison your customers make is not with the bank across the road. Mobile money set the standard years ago: an account in minutes, on the phone already in their hand, from wherever they happen to be. An institution that asks for a branch visit and a wait of several days is competing against that standard whether it means to or not.

The pressure shows up differently depending on who you are. A bank opening accounts across a branch network wants the same quality of file everywhere and fewer applications sent back for rework. A SACCO recruits through employers and groups, so onboarding has to happen where the member is. A microfinance institution signs members in the field, through officers who are not carrying a filing cabinet. A fintech or a telco is judged on the share of people who finish what they started. The platform is the same. What it is being asked to fix is not.

From application to first transaction

A customer applies from their own phone, or sitting with an agent, a field officer or a branch officer. They give their identity details, those details are verified to the standard your policy sets, they see and accept the product terms, and they come out with an account they can put money into and use. Funding on the same visit matters more than it sounds. An account that opens empty very often stays empty.

Not every application resolves cleanly. Names are recorded differently in different places, documents are worn or hard to read, details do not line up with what is on record. That is normal, and what separates a good onboarding service from a poor one is what happens next. The application goes to your review team instead of being dropped, the customer is told plainly that it is being looked at, and the officer who picks it up can see what actually needs deciding. Applications that go quiet are the ones customers abandon.

Assisted onboarding is a first-class journey here, not a fallback. Agents, field officers and branch staff sign up a large share of new customers in this market, and they need to be served as directly as the customer applying alone. So does the half-finished application. Someone who runs out of airtime, battery or patience should be able to return to where they left off rather than begin again from the top.

Tiers, and how much proof an account needs

Not every account needs the same proof of identity. A risk-based approach lets a lower-limit account open on lighter verification, with the customer stepping up to a fuller account later once more is known about them. Commercially, this is how you reach people who cannot produce every document on the first day without either turning them away or ignoring what you are obliged to do.

Which tiers exist, what each one permits, who may hold it, what it takes to move up and what limits apply are policy decisions. They belong to you, taken with your risk and compliance functions and within the framework your supervisor expects of an institution of your kind. Our job is to make sure the platform reflects the policy you set, and that revisiting it later is a business decision rather than a rebuild.

One thing worth settling early: whether the account products you have on paper are the ones you want to open remotely. Product rules written for branch onboarding often assume a document that a remote customer will never hand across a counter, or a signature nobody is there to witness. Reviewing them is far cheaper before a build than after one.

The front door to every other channel

Onboarding is not a standalone product. It is the entrance to your mobile channel, your agency network, your lending book and every other place a customer meets you. What the rest of your estate can do afterwards depends on the customer file this creates and on how much of that file you can stand behind.

A thin record limits everything downstream. A lending decision needs a customer who is properly identified and reachable. Raising a limit needs verification you are willing to defend. A customer who has already proved who they are should not be asked to prove it again to use a different channel.

This is also where duplicate customers come from. Institutions that let each channel, each branch and each campaign sign people up its own way end up holding the same person several times over, and everything after that gets harder: statements, limits, arrears management, and any honest count of how many customers you have. One front door is worth more than several convenient ones.

What launching it involves on your side

Verifying identity against the national register is an access arrangement between your institution and the National Identification Authority, with agreements and conditions attached to it. That sits with you rather than with us, and it is frequently the longest lead time in the project. Starting it while scope is still being agreed is the most useful early move you can make. Where access is not yet in place, we will scope what you can launch without it and what changes when it arrives.

Your KYC and anti-money-laundering policy sets what the service must enforce: which identification you accept, the screening obligations that apply to an institution of your type, when an application must be referred to a person, and who may approve an exception. Where those rules were written for branch onboarding only, they will need a pass for a remote journey before they can be built to.

Then the operating decisions. Applications needing human review will arrive in the evening and at weekends, so the review team, its hours and how long a customer waits for an answer are yours to set, and customers will judge you on the answer. So is what the customer is told at each step, in which language, and through which channel. And identity information, including biometric data where your policy uses it, carries obligations under Tanzania's Personal Data Protection Act. We design to meet the requirements you are subject to. The positions behind them, on consent, retention and who inside the institution may see what, are yours.

Working with us

We start with discovery: your customer segments, your account products, your policy as it actually stands, and the constraints you really operate under. That produces a scope and a plan, and the plan is yours whether or not we go on to build it.

During delivery you see working software in an environment you control rather than progress reports, and the source code and documentation are yours from the first commit. After launch we support the service and train your people to take on as much of it as they want, including the review side of the operation. There is no lock-in, by design and by contract.