Why we built Tazama 4.0.0 in the open, and what I’m bringing to Accra.
Justus Ortlepp, Head of Product, Tazama
A first-time mobile money user in Ghana makes her first transfer over a certain size. It’s declined. The agent can’t say why. The operator’s fraud team can’t say why either, because the decision came out of a vendor’s model, trained on another market’s data, and the reasoning is the vendor’s intellectual property. She doesn’t try again.
A decline nobody can explain is the failure I keep coming back to. Mobile money and instant payments are how many people join the financial system for the first time, and anything that makes a payment harder or more expensive drives them away as surely as fraud does. We talk about fraud detection as protecting the system from bad actors, and it is, but every wrong decline pushes a person back out of the system.
An operator who can’t see why the first-time user in Ghana was declined can’t find the rule that caught her transfer, so the same rule keeps catching first-time users like her. An operator who has to ask a vendor to explain every decision pays for that dependence, and the cost ends up in the fees people pay to send money. A payment system needs fraud controls to be safe, but controls nobody can read make the system harder and more expensive to use. In inclusive payments, opacity is an exclusion problem.
Tazama exists because of a principle the Level One Project wrote down in 2015: fraud detection for inclusive payment systems should be shared infrastructure, built once and open to every institution. The Gates Foundation funds Tazama on those terms, through a grant whose stated purpose is to make sure every player in a Level One aligned payment system has access to quality fraud management tools, not just the ones who can afford a vendor contract.
Open, in that principle, has to mean more than free to run. If an operator can’t see how the software reaches a decision, the software isn’t really theirs, whatever the license says. So the test we set ourselves for Tazama 4.0.0 was whether an operator’s own people could understand how a decision was made, change the logic themselves, and show a regulator the record. If the operator can’t do all three, we’ve built a cheaper black box, and a cheaper black box does nothing for the financial inclusion the Level One Project exists to serve.
You built this with us
Tazama 4.0.0 was built with the people who implement and test it. More than 38 developers across five organizations worked on this release. Most of the code in the release’s new components was written by Paysys Labs, the partner running the COMESA rollout, working from what their deployments needed. The zero-downtime configuration reload in Core started as a proposal from an engineer at Sybrin, put to our Technical Steering Committee in public on GitHub, and what shipped is close to what he proposed. We ran the beta in public. Testers from ThitsaWorks and from institutions we had never worked with found the bugs and the rough edges in the Case & Investigation Management System (CIMS), the Connection Studio and the Rule Studio, and we fixed them in the open, with the issues on GitHub for anyone to read. Some of the CIMS features came in as discussion threads from people we had never met. Each new component started as something someone in our community told us was missing after detection, and in several cases the people running Tazama and the partners implementing it built the component alongside us.
Case & Investigation Management: the record after the alert
Operators told us their real problem began after the alert. The alert went into email, a spreadsheet or a ticketing tool never designed for it, and the record of what happened next was whatever someone remembered when the auditor asked. In Tazama 4.0.0 every alert arrives in a CIMS queue with its score and reason, becomes a case, gets worked and closed, and every decision is on the record. That record lets an investigator revisit a wrongly flagged customer and put the decision right, and it’s what you hand a regulator instead of assembling it the week they ask. Each closed case also records whether the alert was right, and those outcomes are what the calibration notebook learns from when it tunes your detection.
Connection Studio: mapping the feeds nobody could see
The flows that matter most for inclusion, such as mobile money, agent networks and disbursements, are the ones a fraud system most often can’t see, because getting a new feed in was an engineering project. Implementers told us the integration backlog was deciding which transactions got monitored. In the Connection Studio, an analyst maps a new feed on screen, tests it on a sample payload, and sends it for approval. Which feeds get monitored stops being decided by which ones were easiest to integrate.
Rule Studio: logic you can read
Fraud in Kigali does not look like fraud in Karachi, and a ruleset written for one is wrong for the other. Operators asked for a way to write their own logic without a ticket to engineering and without losing control of what went live. In the Rule Studio an analyst builds a rule on a canvas, Tazama generates the code, and the analyst can read every line of it. Before the rule goes anywhere near live traffic, the analyst replays a masked copy of past transactions through it. Building, approving and deploying are separate permissions, so a fraud team can make sure the person who writes a rule is never the one who approves it, and the whole trail has names and times on it.
Analytics: whether detection is working
The question nobody could answer was whether the detection of suspicious transactions was working: which typologies fire, which lead to confirmed fraud, and how many alerts turn out to be nothing. BIAR collects the detection stream and the case outcomes into one lakehouse and answers those questions on dashboards. The false positive rate, now measured at last, is the technical name for the exclusion rate this post began with. The calibration notebook then trains on your own history and investigations and hands back an updated typology configuration to load.
Opaque detection becomes the real lock-in
There’s a version of fraud detection where you buy a score with no way to check how it was reached, and when the score is wrong, nobody can say why, including the customer who was declined. Opaque detection soon becomes the real vendor lock-in for the operator, too: the rules, the history and the knowledge of why the system behaves as it does all sit with the vendor, so leaving means starting again. I don’t think opaque detection is good enough for the payment systems we work on, where the people most likely to be wrongly declined are the people the system was built to include.
Open source on its own doesn’t fix the problem. Publishing the code isn’t enough if an operator still needs us to explain a decision. Tazama 4.0.0 is built so that the operator’s own analysts can read the logic, change it, test it and show the record. As I said on the release call, if you build only your own thing, you’ll be supporting your own thing forever.
Accra
I’m presenting Tazama 4.0.0 at MojaCom 32 in Accra on Wednesday 30 September, and I’d rather show it running than describe it. I’ll start with one alert and follow it through the four questions every fraud team gets asked: can we investigate it, can we change the control, can we add the data we need, and can we show what happened and why. If you run a switch, a wallet or a payment system, or you supervise one, come and watch an alert go from the queue to a closed case with the record behind it.
Then find me afterwards. If you want to see Tazama on your own data, your technical team can run the full platform themselves to evaluate it, with no integrator and nothing to procure first. When you want production, Mojaloop and its implementation partners are there. Either way, what I’d most like is for you to tell me what’s still missing. Requests like those built this release, and we’re already building the next one the same way.
Everything in this post, with the screenshots and the quickstart, is on the Tazama 4.0.0 page.