MSc Artificial Intelligence β University of Liverpool
A production-grade, event-driven Digital Banking ecosystem featuring a cooperative multi-agent reinforcement learning core for end-to-end transaction monitoring and compliance.
This platform is a comprehensive AI-Native Digital Banking Backend and Core Engine built from scratch to address the industry's most critical compliance bottlenecks. Traditional AML systems rely on static rules with false-positive rates exceeding 95 %, costing billions in manual review while sophisticated laundering schemes go undetected.
This project replaces legacy rule engines with an intelligent core workflow: a fully functional, event-driven banking environment integrated with three specialised ML agents that learn to cooperate through Multi-Agent Deep Deterministic Policy Gradient (MADDPG). The result is a next-generation core banking architecture capable of producing a single, fully auditable, and explainable compliance decision for every payment in real time.
The platform is designed to be:
- Production-Grade & Scalable: Driven by event-sourcing and ultra-high-performance financial ledgering concepts.
- Adaptive: Agents learn directly from compliance officer feedback (Human-in-the-Loop) at runtime.
- Collaborative: Multi-agent framework ensures independent neural networks cover different fraud dimensions simultaneously.
- Explainable & Regulatory-Compliant: Powered by TreeSHAP and Integrated Gradients to guarantee dual-layer decision attribution.
The enterprise platform runs as 22 Docker containers β 10 Java core banking microservices, 3 Python ML agents, 1 MADDPG orchestrator, and supporting infrastructure β communicating exclusively through Apache Kafka with Avro schemas (zero synchronous coupling, high-throughput streaming architecture).
Figure 1 β High-Level System Design: 22 containers across three Docker Compose stacks implementing an autonomous Core Banking infrastructure.
Every simulated payment traverses a strict, deterministic financial workflow managed by Axon Framework's saga pattern. The core architecture enforces CQRS and Event Sourcing across the banking cluster, producing over 300,000 immutable domain events in a single simulation run, establishing a zero-tamper audit trail for financial regulators.
Figure 2 β Simulated Digital Banking Environment: 10 decoupled Java microservices connected via high-performance Kafka pipelines.
The lifecycle demonstrates how a modern Neobank processes payments alongside real-time AI intervention. Ledger state updates, account risk validations, and beneficiary checks are entirely decoupled from the heavy AI-inference pipelines.
Figure 3 β Payment Processing Lifecycle: End-to-end banking saga orchestrating microservice state transitions, MARL agent analysis, and instantaneous compliance decisioning.
Three specialised agents each analyse fraud from a different dimension:
| Agent | Model | Key Features | Port |
|---|---|---|---|
| Transaction Pattern Agent | XGBoost | 57 features (after one-hot), trained on 9.5M+ transactions | 1001 |
| Customer Risk Agent | XGBoost + SMOTE | 19 behavioural features aggregated over 30-day sliding window | 1002 |
| Network Analysis Agent | CatBoost | 11 graph-topology features (PageRank, centrality, clustering) β deliberately volume-free | 1003 |
Figure 4 β Agent Decomposition: each agent covers a distinct fraud dimension and exposes a FastAPI endpoint.
A centralised-training, decentralised-execution (CTDE) architecture: three Actor networks (one per agent) + one shared Critic (~415 K parameters total). Training uses a three-tier reward function β automated heuristics, officer review, and decision overrides β with configurable multipliers hot-reloadable at runtime.
Figure 5 β MADDPG Training Loop: centralised Critic trains on joint state-action pairs; Actors execute decentralised.
Figure 6 β Three-Tier Reward Calculation: automated heuristics β officer review β decision override.
Evaluated on 10,000 synthetic payments across five money-laundering typologies:
| Metric | Value |
|---|---|
| System Recall | 97.3 % |
| Smurfing | 99.3 % |
| Fan-out | 100 % |
| Layering | 99.6 % |
| High-value | 100 % |
| Round-trip | 76 % (hardest typology) |
| Precision | 11 % (by design β missed fraud carries regulatory risk; false alerts route to human review) |
| Training Convergence | 18 episodes, 99.5 % critic-loss reduction |
| Median Latency | 779 ms per decision |
Figure 7 β Detection Recall by Typology: five laundering patterns across 10,000 payments.
Figure 8 β Training Convergence: critic loss and reward trajectory over 18 episodes.
The React backoffice provides compliance officers with a single pane of glass over customers, accounts, payments, MARL training, and system configuration. Every screen is backed by the backoffice-gateway aggregating data from the 10 Java microservices and the MADDPG orchestrator.
Figure 9 β Home Page: landing view with quick navigation to all operational areas.
Figure 10 β Dashboard: real-time KPIs across payments, alerts, and agent performance.
Figure 11 β Customers Page: customer registry with risk profiles aggregated from the Customer Profile Service.
Figure 12 β Accounts Page: account inventory linked to customers and payment activity.
Figure 13 β Payments Page: searchable ledger of every payment with compliance decision and agent verdicts.
Figure 14 β Payment Detail (Overview): saga timeline, risk score, and MADDPG ensemble decision.
Figure 15 β Payment Detail (Agent Breakdown): per-agent scores with SHAP / Integrated Gradients attributions.
Figure 16 β Payment Detail (Officer Review): approve / override workflow that feeds the three-tier reward function.
Figure 17 β MARL Training Page: episode control, critic loss, and reward trajectories for the MADDPG orchestrator.
Figure 18 β Replay Buffer Page: inspection of stored (state, action, reward, next-state) transitions used for training.
Figure 19 β Configurations Page: hot-reloadable reward multipliers, thresholds, and feature flags served by the Configuration Service.
Figure 20 β Exchange Rate Page: multi-currency rate management used during payment normalisation.
Figure 21 β Audit Log Page: immutable event trail aggregated from all 300K+ domain events for regulatory traceability.
Every request is traced end-to-end across the Java microservices and the Python AI services, over HTTP, Kafka, and Feign hops, using OpenTelemetry. Traces are viewed in Grafana Tempo and correlated with logs in Loki. A single payment becomes one trace β from the gateway, through the payment saga and risk engine, into the MADDPG orchestrator and the three detection agents, and back.
Figure 22 β End-to-end trace of a single payment (35 spans) across the gateway, payment, risk-engine, MADDPG orchestrator, and the transaction/customer/network agents.
| Layer | Technology |
|---|---|
| Backend | Java 25, Spring Boot 4.0, Axon Framework 4.12 (saga pattern) |
| ML Agents | Python 3.11, FastAPI, XGBoost, CatBoost |
| MARL | PyTorch 2.5.1, MADDPG (custom implementation) |
| Explainability | SHAP 0.51, Integrated Gradients |
| Messaging | Apache Kafka 7.5, Confluent Schema Registry, Avro |
| Databases | PostgreSQL 16.2, Neo4j 5.26 |
| Frontend | React 18, TypeScript, Tailwind CSS, Vite |
| Infrastructure | Docker, Docker Compose |
βββ ai-services/
β βββ agents/
β β βββ transaction_pattern_agent/ # XGBoost β port 1001
β β βββ customer_risk_agent/ # XGBoost β port 1002
β β βββ network_analysis_agent/ # CatBoost β port 1003
β βββ marl_orchestrator/ # MADDPG orchestrator β port 1004
βββ bank-solution-backend/
β βββ account-service/
β βββ customer-service/
β βββ customer-profile-service/
β βββ configuration-service/
β βββ payment-service/
β βββ payment-engine-service/
β βββ payment-history-service/
β βββ risk-engine-service/
β βββ network-topology-service/
β βββ backoffice-gateway/
βββ bank-solution-backoffice/ # React backoffice UI
βββ libraries/
β βββ avro-schema-library/ # Kafka, Zookeeper, Schema Registry & Avro schemas
βββ simulation_tests/ # 10K-payment evaluation suite
βββ data/ # SAML-D dataset (9.5M+ rows)
βββ docs/design/ # Architecture diagrams
- Docker & Docker Compose
- Java 25+
- Python 3.11+
- Node.js 18+
Kafka, Zookeeper, Schema Registry, and Kafka UI live in the avro-schema-library stack. This must come up first because every other component depends on it.
cd libraries/avro-schema-library
./scripts/start-infrastructure.shOnce the Schema Registry is healthy, register the Avro schemas and create the Kafka topics:
./scripts/register-schemas.sh
./scripts/create-kafka-topics.shAlternatively, run everything in one go:
./scripts/setup-complete.sh
cd bank-solution-backend
docker compose up -dThis brings up PostgreSQL 16.2, Neo4j 5.26, all 10 Java microservices (with Liquibase migrations), and the backoffice gateway.
cd ai-services
docker compose up -dStarts the three ML agents (ports 1001β1003), the MADDPG orchestrator (port 1004), and its PostgreSQL database.
cd bank-solution-backoffice
npm install && npm run devThe React UI will be available at http://localhost:5173.
| Service | URL | Port |
|---|---|---|
| Infrastructure | ||
| PostgreSQL | localhost:5433 |
5433 |
| Neo4j Browser | http://localhost:7474 | 7474 |
| Neo4j Bolt | localhost:7687 |
7687 |
| Kafka Broker | localhost:9092 |
9092 |
| Schema Registry | http://localhost:8081 | 8081 |
| Kafka UI | http://localhost:8080 | 8080 |
| Backend Microservices | ||
| Customer Service | http://localhost:5001 | 5001 |
| Account Service | http://localhost:5002 | 5002 |
| Payment Service | http://localhost:5003 | 5003 |
| Payment Engine Service | http://localhost:5004 | 5004 |
| Payment History Service | http://localhost:5005 | 5005 |
| Risk Engine Service | http://localhost:5006 | 5006 |
| Network Topology Service | http://localhost:5007 | 5007 |
| Customer Profile Service | http://localhost:5008 | 5008 |
| Configuration Service | http://localhost:5009 | 5009 |
| Backoffice Gateway | http://localhost:3030 | 3030 |
| AI Services | ||
| Transaction Pattern Agent | http://localhost:1001 | 1001 |
| Customer Risk Agent | http://localhost:1002 | 1002 |
| Network Analysis Agent | http://localhost:1003 | 1003 |
| MADDPG Orchestrator | http://localhost:1004 | 1004 |
| MADDPG Orchestrator DB | localhost:5438 |
5438 |
| Observability | ||
| Grafana (logs + traces) | http://localhost:3009 | 3009 |
| Tempo (traces) | http://localhost:3200 | 3200 |
| Loki (logs) | http://localhost:3100 | 3100 |
| Frontend | ||
| Backoffice UI (Docker) | http://localhost:6060 | 6060 |
| Backoffice UI (dev) | http://localhost:5173 | 5173 |
This project is licensed under the MIT License. See the LICENSE file for details.
This project uses the Synthetic AML Transaction Monitoring Dataset (SAML-D) β a typology-based AML dataset containing 9.5 M+ transactions across five laundering patterns (smurfing, fan-out, layering, high-value, round-trip).
Credit to Berkan ΓztaΕ for making this dataset publicly available on Kaggle.
B. ΓztaΕ, D. Γetinkaya, F. Adedoyin, M. Budka, H. DoΔan, and G. Aksu, "Enhancing Anti-Money Laundering: Development of a Synthetic Transaction Monitoring Dataset," 2023 IEEE International Conference on e-Business Engineering (ICEBE), Sydney, Australia, 2023, pp. 47β54, doi: 10.1109/ICEBE59045.2023.00028.
This dissertation was completed as part of the MSc in Computer Science at the University of Liverpool. Sincere gratitude to Dr. Chunyan Mu for her guidance and support throughout this research.