Platform architecture

MasteryHiveAI’s in-scope backends are three separate deployables that typically converge on a banking dashboard / app backend. They do not share one process, database, or auth middleware.

flowchart TB
  subgraph fraud [Fraud_TM]
    checks[fraud-detection-ai-backend]
    ml[ml_service]
    rule[rule_service]
    case[case_management_service]
  end
  subgraph kyc [KYC_KYB_AML]
    kycapi[kyc-kyb-ai-backend]
  end
  subgraph recon [Reconciliation]
    ing[bk-ingestion]
    name[bk-name-worker]
    rev[bk-reversals]
    eng[bk-recon-engine]
    worker[bk-recon-worker]
    load[bk-loader]
    dlq[bk-recon-work-dlq-replay]
    exc[exception-service]
  end
  dash[Banking_dashboard_backend]
  bq[(BigQuery)]
  pg[(Postgres)]
  checks --> dash
  ml --> checks
  rule --> checks
  kycapi --> dash
  eng --> load
  load --> dash
  ing --> bq
  eng --> bq
  checks --> pg

Cross-cutting

Concern	Fraud	KYC/KYB	Reconciliation
Primary trigger	Pub/Sub push + some HTTP	HTTP	HTTP + Pub/Sub
Tenancy header / fields	x-tenant-id	UNKNOWN on routes (open CORS)	tenant_id / partner_id in payloads
Service auth	Bidirectional JWT (ApiKey)	Not on app routes	Cloud Run identity / internal URLs
Data stores	Postgres (+ SQLite predictions locally), Pub/Sub	BigQuery audit (configured), vendor APIs	BigQuery, Redis, GCS, Pub/Sub
LLM use	Report narrative only (policy elsewhere)	Reports / screening assist	Name extract + match assist + summaries

What this diagram is not

• Not a claim of shared VPC, shared secrets, or shared CI.
• Not a product inventory of Chapel Hill, Polaris, or other side repos.
• Side projects outside Fraud / KYC-KYB / Reconciliation are out of scope for this site.