System Overview
The four core components of Minka Hub and how they coordinate secure, scalable transactions across payment networks.
System Overview

Minka Hub is designed to orchestrate secure, scalable, and interoperable transactions across diverse financial ecosystems. At its core is the Two-Phase Commit (2PC) protocol, which coordinates distributed transactions by ensuring that every step in a payment either completes fully or rolls back entirely. This guarantees consistency across systems and eliminates the risk of partial transactions.
The hub is built around four key components:
The Bridge handles the 2PC protocol logic and acts as the interface for external systems to initiate, prepare, commit, or abort transactions.
The Ledger maintains account balances using double-entry bookkeeping, providing an immutable source of truth for all transaction movements.
The CLI lets developers and operators interact programmatically with the hub for automation, troubleshooting, and operational control.
The Studio is a visual management layer where teams configure, monitor, and govern hub activity through a web interface.
This modular architecture makes Minka Hub highly adaptable — from P2P payments and disbursements to collections and cash-outs. It integrates with a wide range of payment networks (RTP, ACH, card networks, wallets) and supports transactions initiated by any entity: businesses, individuals, governments, and others. By abstracting the complexity of payment network integration and unifying the orchestration layer, Minka Hub delivers fast, reliable, and compliant payment processing across the entire financial ecosystem.
Why This Architecture
Two-phase commit over eventual consistency. In payment infrastructure, a partial transaction — funds leaving one account without arriving at the destination — is a critical failure. 2PC prevents this by requiring all participants to confirm readiness before any funds move. The latency trade-off is acceptable; the consistency guarantee is not optional.
Alias directory over account number routing. Sharing a phone number or email instead of a bank account number reduces onboarding friction and enables number portability across institutions. The alias directory is the indirection layer that makes this work — aliases point to payment credentials, not to fixed account numbers.
Bridges as the integration boundary. Rather than Minka Hub integrating directly with each participant's core banking system, each participant implements a standardized bridge interface. This keeps the hub network-agnostic, reduces coupling, and lets participants adopt the integration on their own timeline without changes to Minka Hub itself.