AOne·The Enterprise Digital Experience Platform of AO Group

All products
Powered by Tazama Version 4

AO Transaction Monitoring

Detect fraud before funds leave the ecosystem.

The platform

What AO Transaction Monitoring is

AO Transaction Monitoring is a real-time fraud and financial-crime monitoring capability powered by Tazama Version 4. It combines transaction ingestion, rules, weighted typologies, instant decisioning, investigation workflows, analytics and AI-assisted optimisation with AO implementation and managed services. AO Transaction Monitoring gives financial institutions, payment switches, fintechs and payment providers a configurable way to evaluate transactions in real time. The platform uses current transaction data, historical participant behaviour, rules and weighted typologies to calculate risk and support immediate action. Depending on the operating model of the customer, a suspicious transaction may be blocked, held, flagged or passed into an investigation workflow. AO provides the implementation, integration, configuration, deployment, support and operating capability required to use Tazama within a production financial ecosystem. Tazama is open-source software. AO provides the specialist engineering and operational capability required to implement it effectively.

The challenge

Fraud moves at transaction speed

Real-time payment risk

Instant and fast-payment systems leave little time for manual intervention before funds move.

Fragmented monitoring

Fraud controls are often spread across channels, systems and providers without a complete transaction view.

Static rules

Rules that are difficult to update become less effective as fraud behaviour changes.

False positives

Poorly calibrated rules create unnecessary alerts and increase the workload of fraud and compliance teams.

Investigation gaps

Alerts without structured case management, evidence and escalation processes are difficult to resolve consistently.

Limited transparency

Closed platforms and opaque commercial models can create vendor dependency and restrict control over fraud strategy.

Tazama Version 4

A complete fraud and AML-assisted monitoring ecosystem

Real-time detection engine

Rules-based monitoring evaluates each transaction using current event data and historical participant behaviour, then combines the results into weighted typologies with configurable thresholds.

  • Real-time ingestion
  • Transaction and participant evaluation
  • Historical behaviour analysis
  • Rule processors
  • Typology scoring
  • Configurable thresholds
  • Instant decisioning
  • Interdiction or alert routing

Fast integration and low-code configuration

Connection Studio and data-enrichment services allow organisations to ingest, map and enrich transaction data from different payment formats and systems.

  • Flexible message formats
  • ISO 20022
  • Proprietary payment messages
  • Legacy formats
  • Field mapping
  • Data transformation
  • Data enrichment
  • Connection monitoring
  • Low-code configuration

AI-assisted optimisation

AI-assisted tooling supports rule recommendations, parameter calibration, threshold optimisation and alert prioritisation.

  • Rule recommendations
  • Parameter tuning
  • Threshold optimisation
  • Alert prioritisation
  • False-positive reduction support
  • Simulation and calibration

Investigation and analytics

Case management, investigation workflows and analytics provide the operational capabilities needed after an alert has been raised.

  • Alert triage
  • Case creation
  • Investigation workflows
  • Evidence management
  • Escalation
  • Operational reporting
  • Jupyter-based analysis
  • Data-science support
How it works

From transaction ingestion to action

  1. Stage 1: Ingest

    Receive a transaction or payment event through the Transaction Monitoring Service API or an approved integration channel.

    • ISO 20022 messages
    • Switch transactions
    • Wallet transactions
    • Account transfers
    • Card-related events
    • Proprietary payment formats
    • Batch or streaming events where supported
  2. Stage 2: Map and enrich

    Transform the message into the required monitoring structure and enrich it with participant, account or reference data.

    • Connection Studio
    • Data Enrichment API
    • Data Enrichment Monitoring Service
    • External reference data
    • Customer and account attributes
    • Historical transaction information
  3. Stage 3: Apply rules

    Evaluate the transaction against configured rules and behaviour conditions.

    • Transaction value
    • Velocity
    • Frequency
    • Account history
    • Participant behaviour
    • Geographic indicators
    • Device or channel indicators
    • Known conditions and watchlists where integrated
  4. Stage 4: Calculate typologies

    Combine multiple rule outcomes into weighted fraud or AML-assisted typologies.

    • Weighted rules
    • Thresholds
    • Multiple risk signals
    • Participant history
    • Current transaction context

    A single rule may not be enough to identify suspicious behaviour. Typologies must be designed, validated and calibrated for the payment environment of each customer.

  5. Stage 5: Decide

    Apply the configured transaction-level decision.

    • Allow
    • Block
    • Hold
    • Flag
    • Escalate
    • Continue with monitoring

    Available actions depend on the payment architecture and integration scope of the customer.

  6. Stage 6: Investigate

    Create and manage an alert or case where human review is required.

    • Alert triage
    • Assignment
    • Investigation
    • Evidence
    • Notes
    • Workflow
    • Escalation
    • Closure
  7. Stage 7: Learn and improve

    Use operational results, analyst decisions and analytics to improve rules, thresholds and typologies.

    • Calibration
    • Simulation
    • False-positive analysis
    • Trend analysis
    • Rule improvement
    • Typology optimisation
Core engine

Real-time, rules-based transaction evaluation

The core Tazama engine processes transactions through an event-driven monitoring pipeline. Rule processors evaluate current transaction attributes and historical information. Typology processors combine rule results into weighted risk scores, and the transaction decision layer determines whether the activity should proceed, be blocked or be referred for investigation.

Transaction Monitoring Service

Ingests transaction events into the monitoring platform.

Event Director

Routes transaction events through the relevant processing pipeline.

Rule processors

Evaluate individual risk conditions using transaction and participant data.

Typology processor

Combines rule results into configurable weighted typologies.

Event Adjudicator

Supports the interpretation and routing of monitoring results.

Transaction aggregation and decisioning

Aggregates typology outcomes and applies the configured transaction-level decision.

Administration

Supports configuration and administration of the monitoring environment.

Authentication

Provides controlled platform access and service authentication.

Architecture

A modular, event-driven monitoring platform

01

Core monitoring

The core platform processes transactions, applies fraud logic and produces real-time decisions.

  • Transaction Monitoring Service
  • Event routing
  • Rule processing
  • Typology processing
  • Decisioning
  • Authentication
  • PostgreSQL
  • NATS messaging
  • In-memory caching
02

Extensions

The extension layer supports transaction onboarding, low-code configuration, investigation and operational management.

  • Connection Studio
  • Data-enrichment services
  • Rule Studio
  • Case Management
  • Workflow
  • Search
  • Supporting configuration APIs
03

Analytics and reporting

The analytics layer supports reporting, investigation analysis and data-science use cases.

  • Data ingestion
  • Data preparation
  • Object storage
  • Search and indexing
  • Document analysis
  • Reporting and notebooks
Platform depth

Integration, rules, investigation and analytics

Connection Studio, Rule Studio, typology scoring, AI assistance, case management and analytics extend the core engine so that monitoring can be onboarded, tuned and operated without rebuilding the platform.

Connection Studio and data enrichment

  • Message-format mapping
  • ISO 20022 support
  • Proprietary-format support
  • Legacy message support
  • Field transformation
  • Schema mapping
  • Data validation
  • Participant enrichment
  • Account enrichment
  • External data enrichment
  • Integration monitoring
  • Reusable connection definitions

Rule Studio

  • Low-code rule definition
  • Rule parameters
  • Threshold management
  • Rule versioning
  • Test scenarios
  • Simulation
  • Approval workflow
  • Deployment workflow
  • Rule documentation
  • Reusable rule templates

Typology scoring

  • Rule A: transaction velocity
  • Rule B: unusual value
  • Rule C: new beneficiary
  • Rule D: abnormal participant behaviour
  • Weighted combined score
  • Typology threshold
  • Decision or alert

AI-assisted optimisation

  • Rule recommendations from observed transaction behaviour
  • Parameter calibration using historical data
  • Threshold optimisation against alert volumes
  • Alert prioritisation by risk indicator strength
  • Human review and governance remain required

Case management

  • Alert ingestion
  • Triage
  • Case creation
  • Assignment
  • Analyst queues
  • Investigation workflow
  • Evidence and attachments
  • Notes and collaboration
  • Escalation
  • Status management
  • Decision history
  • Closure
  • Audit trail

Analytics and reporting

  • Operational dashboards
  • Alert volumes
  • Typology performance
  • Rule performance
  • False-positive analysis
  • Participant risk trends
  • Investigator workload
  • Case outcomes
  • Time-to-resolution
  • Data-science exploration
  • Jupyter-based analysis
  • Custom reports

Open source and control

  • Transparent architecture
  • Community-driven development
  • No conventional proprietary software licence
  • Greater deployment flexibility
  • Ability to extend the platform
  • Reduced vendor lock-in
  • Reusable fraud-monitoring capability
  • Support for emerging-market payment ecosystems
Outcomes

What the platform is designed to improve

  • 01Evaluate transactions in real time.
  • 02Identify suspicious patterns before or during payment execution.
  • 03Combine multiple rule results into configurable fraud typologies.
  • 04Block, hold or route high-risk transactions according to policy.
  • 05Improve visibility across participants, accounts and transaction history.
  • 06Reduce unnecessary manual investigation through better calibration.
  • 07Create structured investigation and case-management workflows.
  • 08Strengthen auditability and decision traceability.
  • 09Support fraud and AML-related operational reporting.
  • 10Reduce dependency on proprietary transaction-monitoring platforms.
  • 11Create a modular foundation that can evolve over time.
Delivered by AO

From open-source platform to production monitoring capability

AO implementation services

Readiness and fraud assessment
Assess the payment ecosystem, transaction flows, current controls, data quality and fraud risks.
Solution architecture
Design the target Tazama deployment, integration, security and operational architecture.
Message and integration engineering
Connect payment switches, core systems, wallets, channels and external data sources, including ISO 20022, Mojaloop where applicable, payment-switch and core-banking integration.
Rule and typology configuration
Design and configure customer-specific monitoring rules, weightings and thresholds, supported by data enrichment, historical-data preparation and calibration.
Case-management implementation
Configure investigation workflows, queues, evidence, escalation, reporting and user training.
Deployment and operating support
Deploy, monitor, maintain and support the platform according to an agreed service model, with continuous improvement.

AO managed service

Platform and infrastructure operations
Platform monitoring, infrastructure monitoring, application support, incident management and release management.
Monitoring content management
Rule changes, typology changes and calibration support under an agreed change process.
Operational support
Technical case-management support, integration support, operational reporting and service reviews.
Platform assurance
Security patching, backup and recovery, capacity planning and upgrade planning.
Use cases

Designed for modern payment ecosystems

Instant payment systems

Evaluate real-time payments before or during settlement.

National and regional switches

Apply consistent fraud controls across participating institutions and channels.

Banks

Monitor account transfers, payment activity and participant behaviour.

Mobile money

Apply fraud controls across wallets, agents, transfers and cash-in or cash-out activity.

Fintechs

Add transaction monitoring without building a proprietary fraud platform from the ground up.

Remittance providers

Monitor cross-border and domestic transfer patterns.

Merchant and payment providers

Monitor payment flows, merchants, customers and transaction behaviour.

Digital lenders

Monitor disbursements, repayments, account behaviour and suspicious transaction patterns.

Open banking and API payments

Apply monitoring controls across API-driven payment journeys.

Central banks and regulators

Support ecosystem-level visibility where the legal and operating mandate permits.

Deployment

Deploy according to the security and operating model of the customer

Tazama provides deployment patterns for on-premise environments and major cloud platforms. The final topology depends on transaction volumes, availability requirements, security, sovereignty, integration and operational responsibility. Sandbox stacks published for demonstration and exploration are not production deployment patterns.

On-premise

Deployment inside customer data centres where sovereignty or latency requires it.

Private cloud

Dedicated tenancy with customer-controlled network and security boundaries.

Azure

Deployment onto Microsoft Azure using supported production patterns.

AWS

Deployment onto Amazon Web Services using supported production patterns.

Google Cloud

Deployment onto Google Cloud using supported production patterns.

Hybrid architecture

Split deployment across on-premise and cloud components where integration demands it.

Customer-managed deployment

The customer operates the platform with AO engineering support.

AO-managed deployment

AO deploys and operates the platform under an agreed service model.

Sandbox and proof-of-value

Non-production environments for exploration, testing and calibration only.

Proof in practice

AO and Tazama strategic partnership

Payments and financial crime

Context

Real-time fraud monitoring has been difficult to access across many African payment ecosystems because of proprietary licensing models, integration complexity and scarce specialist operating capability.

Approach

AO Group and Tazama announced a strategic partnership in 2025 to expand access to real-time fraud monitoring across African payment ecosystems, combining the open-source platform with AO integration, configuration, deployment and support capability.

Where it applies

Typical engagement profiles include national payment switches, central-bank-sponsored payment infrastructure, mobile-money ecosystems, financial-services providers and regional instant-payment programmes.

Customer identities are withheld. Engagements are described at a level agreed for public reference.

Questions

Frequently asked

AO Transaction Monitoring supports fraud detection, investigation and AML-related monitoring processes. It does not replace legal advice, sanctions-screening platforms, customer due diligence, regulatory reporting obligations or accountable compliance decision-making. Open-source software is not cost-free to implement or operate: customers must budget for infrastructure, integration, configuration, security, testing, support, maintenance and specialist operating capability. Customer fraud, compliance, legal and regulatory decision-making remains with the appropriately authorised customer teams unless a separately defined service is agreed.

A discovery session is a working conversation about scope, constraints and what a credible first release looks like.