Tazama: Open-Source Transaction Monitoring, Explained
Transaction monitoring has traditionally been sold as a closed, expensive product, which put real-time financial-crime detection out of reach for many smaller institutions and inclusion-focused schemes. Tazama is an attempt to change that. It is an open-source platform for real-time fraud and anti-money-laundering (AML) transaction monitoring, built to run at high volume and to be inspected and operated by the teams that depend on it. This post explains what Tazama is, how it is put together at a conceptual level, and why its design choices matter.
What Tazama is
At its core, Tazama is a system that receives transaction events, evaluates them against configurable detection logic in real time, and produces alerts or interdiction signals. It is hosted as an open-source project under the Linux Foundation, which gives it neutral governance and an open contribution model rather than being controlled by a single commercial vendor.
Two ambitions shape the project. The first is real-time monitoring at scale: the design assumes that monitoring must keep pace with modern payment rails, where decisions may need to happen in the moment rather than in an overnight batch. The second is financial inclusion: by being open and self-hostable, it aims to make sophisticated monitoring available to organisations and markets that could not justify a proprietary suite, including those built on open instant-payment infrastructure.
How the design works
While implementations evolve, the conceptual architecture is worth understanding because it explains the platform's strengths.
Event-driven pipeline
Tazama is built around an event-driven, message-passing pipeline rather than a monolith. Transactions arrive as messages and flow through stages that enrich, evaluate, and score them. An event-driven approach is what allows the system to scale horizontally and to absorb bursts of traffic, since stages can be scaled independently and messages buffered.
Rules and typologies
Detection logic is expressed as rules that check specific conditions and typologies that combine rule outcomes into a judgement about whether a behaviour pattern is suspicious. Separating individual rule evaluation from the higher-level typology decision keeps logic modular: a rule such as a velocity check can be reused across several typologies. Because these are configuration rather than opaque internals, risk teams can review and tune them.
Scoring and interdiction
The output of typology evaluation is a score or determination that downstream systems can act on, whether that means raising a case for investigation or signalling that a payment should be held. Keeping the monitoring engine separate from the acting system is a clean separation of concerns: Tazama focuses on detection and leaves enforcement to the payment platform.
Why real time matters here
Batch monitoring, where transactions are reviewed hours or days after they settle, is increasingly mismatched with how payments actually work. Instant-payment rails move money in seconds and often irrevocably. If monitoring only catches a suspicious pattern after settlement, the funds may already be gone. Real-time evaluation gives a scheme the option to intervene before or during settlement, which is a materially stronger control. Tazama's whole design is oriented around meeting that timing requirement without collapsing under volume.
Interoperability and Mojaloop
One of the reasons Tazama is relevant to inclusion-focused payments is its alignment with open instant-payment systems, notably Mojaloop, the open-source platform used to build interoperable digital-payment schemes in emerging markets. Monitoring that can integrate cleanly with such a scheme lets operators add financial-crime controls without buying a proprietary bolt-on. More broadly, favouring standard interfaces makes Tazama easier to place inside a variety of payment architectures, not just one vendor's stack.
What adopting Tazama involves
Open source shifts responsibility to the adopting team, and it is honest to be clear about that. Running Tazama in production means operating an event-driven system, authoring and maintaining rules and typologies that reflect your risk assessment, feeding it good-quality transaction data, and tuning to manage false positives. These are the same disciplines any monitoring programme requires, but with an open platform your team owns them directly rather than delegating to a vendor.
The pay-off is transparency and control. You can read exactly why an alert fired, evidence that logic to auditors and regulators, and evolve detection without waiting on a product roadmap. For teams that value being able to explain their controls, that is a significant advantage.
Open monitoring does not remove the hard work of risk tuning; it makes that work visible and yours to direct.
A concrete example
At KibiPay we use Tazama to perform real-time fraud and AML screening across our payment rails. Transactions on rails such as UK payments, Mojaloop, and others are evaluated as they flow, so that risk decisions happen in the moment rather than after the fact. This is a practical illustration of the intended pattern: an open, self-operated monitoring engine sitting alongside the payment platform, applying configurable typologies to every transaction.
Where it fits in your stack
Tazama is best understood as the real-time detection engine within a wider financial-crime architecture. It pairs naturally with sanctions and watchlist screening for name-based checks, with case-management tooling for investigators, and potentially with graph analytics for network-level detection. It is not a complete compliance programme on its own, and treating it as one would be a mistake. As one well-designed, open component, though, it fills a role that used to require an expensive proprietary purchase.
Takeaway: Tazama shows that real-time, high-volume transaction monitoring can be delivered as open, inspectable software. If you value transparency, interoperability with open payment rails, and control over your own detection logic, it is worth serious evaluation as the monitoring core of your stack.