Artificial Intelligence and Machine Learning Platforms

Where it earns its place, and where it does not

The pressure to do something with AI arrives from outside the institution. A board paper. A competitor's announcement. A vendor demonstration that answered questions beautifully, in English, about a bank that does not exist. What follows is often a project with a technology at the centre and no business case around it.

The more useful question is narrower. Which repeated, high volume, low judgement work costs you real money and takes your people away from the work only they can do? In a Tanzanian bank, SACCO or microfinance institution that list is short and unglamorous. Answering the same twenty questions all day. Typing what is on a form into a screen. Deciding which members to tell about a product. Reading a file a credit officer still has to sign.

Where it does not earn its place is worth saying as plainly. Work you do rarely. Work where being wrong is expensive and being right is judgement rather than pattern. And anything you cannot already do by hand, because this makes existing work cheaper rather than handing you a capability you never had. For a fintech there is a further test, better applied privately: whether the intelligence is doing work in the business or in the pitch.

The four jobs worth handing over

Customer service is where most institutions see a return first. Your contact centre answers the same questions all day: what is my balance, why has that payment not arrived, what was that charge. They come in Swahili and English, often both in one sentence, and they arrive in the evening, at weekends and in salary week. Handling the routine ones without hiring to match the peak means the customer with a real problem reaches somebody instead of queueing behind twenty who did not need to.

Document handling is the least discussed and often the most valuable. Identity documents, application forms, payslips, employer letters, group meeting records. In most institutions these are read by a member of staff and typed into a system, sometimes twice. The mistakes surface later, as a file that fails review or a customer telephoned on a number that has changed hands. Taking the re-keying out gives back staff hours and improves the record you are left holding.

Segmentation changes the economics of marketing. Most institutions here promote to the whole book, or to whoever a branch manager remembers. Telling the few thousand customers who might actually want a product about it, and leaving the rest alone, alters the return on every campaign and how much contact customers will tolerate.

Decision support for credit and risk is the fourth, and the word support is doing real work there. An officer reading a hundred files makes poorer decisions at four o'clock than at nine. Ranking a queue and drawing attention to what is unusual gives that attention back. The decision, and the person answerable for it, stay where your risk function put them. None of this replaces a system you already run. It sits beside your contact centre, your lending operation and your core, as an addition rather than a replacement. Which application to begin with is decided with you.

The prerequisite nobody wants to hear

There is nothing to learn from unless your own records will bear the weight. Most institutions here hold the same customer more than once, under a name spelled several ways, with an address that describes a place rather than identifies one, and a history that starts on paper in a branch. That is not a criticism. It is the ordinary condition of an institution trading for decades, and it decides what is possible.

Put poor records to work and you get answers that are confident, plausible and wrong. The first time a manager checks one against something they know to be true, the credibility of the whole programme goes, and it rarely comes back.

So for many clients the first piece of work is the records themselves. Agreeing what you hold. Deciding which one is authoritative when two disagree. It is not the interesting part, and it is where a board's patience is tested. It also pays on its own terms, making supervisory reporting easier and giving you an honest count of your customers. If that is where you are, we would rather say so at the start.

Every decision has to be defensible

A customer refused a loan asks why. A member told they are not eligible tells the branch, and then tells the group. Your supervisor asks on what basis you treated one customer differently from another. Banking in Tanzania is supervised by the Bank of Tanzania, and Tanzania has a Personal Data Protection Act, which reaches the use of personal information to make decisions about people. The system decided is not an answer to any of them.

Explainability is therefore a commercial and regulatory requirement rather than a refinement. Your staff have to give a customer a reason they will accept and a reviewer will stand behind. You need a record of what was decided about whom and on what grounds, one that outlives the officer who was in the chair. You need a route for the customer who disagrees. And you need a settled position on what customers are told when they are dealing with an automated service at all. There is an internal cost to getting this wrong: staff who cannot see why an answer is the answer work around it, and a flag nobody trusts changes nothing.

What has to be settled on your side

Start with the data, because it is yours. What your institution holds, what it may lawfully use and for which purposes, what customers were told when it was collected, and whether that covers what you now intend. That is a question for your legal and compliance people, cheaper settled before a design than during a launch.

Then a position on what may be automated and where automation stops. Which answers a customer may receive with no person involved, which products and amounts may be decided that way, and what is referred to a person regardless. Your risk and compliance functions own this, and it shapes what gets built rather than following it. Worth writing down even where today's practice is to decide case by case, because case by case cannot be reviewed.

Then the operating process around what comes out, which most institutions underestimate. Anything that produces a list produces work. Who works that list, and what a member of staff does when they disagree with it. Somebody senior also has to look, on a schedule, at whether it still does what it was bought to do. Customers change, products change and the market changes, and none of them send a warning.

Working with us

We start with discovery: what your people spend their days doing, where the cost sits, what your records are genuinely like, and which of these applications has a case worth acting on. The scope and plan that come out are yours whether or not we build anything.

Through delivery you see working software in an environment you control, and the source code and documentation are yours from the first commit. We will argue for one narrow application, measured against whatever it replaced, before anything wider. After launch we support it and train your people. There is no lock-in, by design and by contract.