The Problem

Financial institutions must flag suspicious transactions before they are completed. Existing solutions lack a unified, end‑to‑end flow that combines real‑time transaction orchestration, entity resolution, cryptographic proof of integrity, and AI‑driven SAR generation within a single stack.

What This Does

trinity-guard-pycon-kenya-2026 delivers a four‑service pipeline that validates transaction data, resolves entities, signs the payload with a ZK‑SNARK, and produces a SAR through an LLM.

  • Go backend (services/go-backend/main.go) orchestrates the flow, exposing a REST API and calling downstream services.
  • Python NER (services/python-ner/trinity_ner/ner_service.py) runs GLINER to tag entities in the transaction text.
  • Rust ZK (services/rust-zk/src/main.rs) builds a Merkle tree and generates a Groth16 proof, exposing a gRPC endpoint defined in contracts/proto/trinity.proto.
  • LLM service (services/llm-service/trinity_llm/llm_service.py) accepts the signed payload and emits a SAR using either Ollama or OpenAI, configurable via LLM_PROVIDER.

How It Is Wired

Internal Call Graph

  1. Entry point – services/go-backend/main.go starts a Gin server on port 8080.
  2. REST endpoint – /transactions receives a JSON payload.
  3. Forward to NER – go-backend/main.go invokes services/python-ner/trinity_ner/ner_service.py via HTTP (requests.post).
  4. NER response – returns entity tags that are appended to the transaction.
  5. Sign with ZK – go-backend/main.go calls the Rust gRPC client (trinity_zk_client.go) to GenerateProof defined in services/rust-zk/src/proto/trinity.rs.
  6. Proof & payload – Go receives a base64 proof and the Merkle root, packages them with the transaction, and forwards to the LLM service (trinity_llm/llm_service.py) over HTTP.
  7. SAR generation – LLM service formats a prompt (prompts.py) and streams the result back to Go.
  8. Response – Go returns the SAR to the original caller.

What This Code Touches Outside Itself

  • PostgreSQL via DATABASE_URL (writes transaction records).
  • Redis via REDIS_URL (caches NER results, pub/sub for transaction status).
  • Prometheus (metrics.py) for service health.
  • Docker images built from services/*/Dockerfile and orchestrated by deploy/docker-compose.yml.

Responsibility Mapping

FileResponsibility
services/go-backend/main.goHTTP API, orchestration, gRPC client
services/go-backend/zk_client.gogRPC wrapper to Rust ZK
services/python-ner/trinity_ner/ner_service.pyNER endpoint, model loading
services/rust-zk/src/main.rsgRPC server, proof generation
services/llm-service/trinity_llm/llm_service.pyLLM prompt handling, SAR output

The Go backend is the primary blast radius: most paths originate here, so changes here affect NER, ZK, and LLM interactions.

How To Use It

# Clone
git clone https://github.com/moses-y/aml-open-source
cd aml-open-source

# Copy environment template
cp .env.example .env

# Build and run containers
make up

# Verify health
make demo-check

# Launch the live demo
make demo
  • Setup – make setup pulls the Ollama model and installs dependencies.
  • Configuration – environment variables in .env control LLM_PROVIDER, OLLAMA_MODEL, OPENAI_API_KEY, GLINER_MODEL, DATABASE_URL, and REDIS_URL.
  • Running – The Go backend listens on localhost:8080. Send a POST to /transactions. The demo script (demo/trinity_demo/live_demo.py) illustrates a complete round‑trip.

Real‑World Use

A compliance desk receives a transaction record, pushes it to http://localhost:8080/transactions, and receives a SAR ready for filing. The stack ensures that the SAR references a cryptographic proof (proof, root) stored in PostgreSQL, and the LLM prompt is fully auditable through the prompts.py template. The system can be scaled by spinning additional Go instances behind a load balancer; the only shared state is Redis and PostgreSQL.

Code Health & Issues

  • License – No LICENSE file present.
  • Secrets – No hard‑coded credentials; all secrets come from environment variables.
  • Tests – 7 test files (services/go-backend/main_test.go, rust-zk/tests/*.rs, llm-service/tests/test_llm_service.py).
  • CI – GitHub Actions (.github/workflows/ci.yml) run linting and tests.
  • Documentation – README and TRINITY_ARCHITECTURE.md provide high‑level guidance; individual service READMEs (services/go-backend/README.md, etc.) are thin.
  • Missing production safeguards – No rate‑limiting, no TLS configuration, and no production‑grade logging beyond Prometheus metrics.

The Bottom Line

trinity-guard-pycon-kenya-2026 is a solid, polyglot demo that shows how Go, Python, and Rust can collaborate for AML compliance. It is suitable for proof‑of‑concept or educational purposes but would need additional hardening and documentation before use in a regulated environment.