About Ledgers

Audience: Decision Makers, Technical Leaders · Read time: 4 min

Every organization that moves money faces the same problem. Payment systems are built from disconnected pieces — a core banking system here, a payment gateway there, a reconciliation process running overnight, and a team of people stitching it all together with spreadsheets, batch files, and hope.

The result is predictable. Balances don't match until someone reconciles them. Settlement takes hours or days. Adding a new participant means building another integration from scratch. Business rules live scattered across middleware, fraud engines, and gateway configurations — and changing any of them requires a code deployment.

A Minka ledger replaces this fragmented architecture with a single coordination layer. It's a shared, programmable record of financial positions that tracks who holds what, enforces rules on how balances move, and coordinates changes across multiple participants in real time.

What makes the ledger different

Traditional payment switches route messages between systems. They know where to send a payment, but not how much is available, what rules apply, or what happened after delivery. They are essentially sophisticated mail carriers — they deliver the envelope but have no idea what's inside or whether the recipient actually received the value.

The ledger knows all three. Every participant, every account, and every business rule is represented inside the ledger with real balances, real-time limits, and automatic coordination. When a payment moves through the ledger, it doesn't just route a message — it checks available funds, applies business rules, coordinates both sides of the transaction atomically, and updates all balances before confirming anything.

This is the difference between routing payments and actually understanding money.

Real-time settlement without reconciliation

Every time money moves through the ledger, both sides of the transaction update atomically. If a payment completes, the sender and receiver balances are already correct. If a payment fails, both balances are already rolled back. There is no separate reconciliation process, no batch job running overnight, no spreadsheet someone has to check in the morning.

This holds true even when a payment crosses institutional boundaries — a bank's settlement account in the ledger stays in sync with the actual movement in the bank's core system because the ledger coordinates both sides before confirming anything. For organizations running payment operations, this eliminates an entire category of work. Reconciliation becomes a continuous, automatic process instead of a daily headache.

Business rules as configuration, not code

The ledger doesn't just hold balances — it enforces behavior. Minimum and maximum balance limits, currency restrictions, automatic payment forwarding, accept/reject rules based on amount or pattern — all of these are defined as configuration on the ledger itself, not as custom code in a middleware layer.

Adding a new rule doesn't require a code deployment. It requires updating a configuration. This means the people who understand the business logic — operations teams, product managers, compliance officers — can express rules directly, without waiting for an engineering sprint.

Multi-party coordination with cryptographic guarantees

The ledger is designed for environments where multiple institutions need to coordinate but don't fully trust each other. Every record in the ledger is cryptographically signed and independently verifiable. Anyone with a record and the signer's public key can confirm who created it and that nothing has been altered.

This tamper-evidence property makes multi-party settlement trustworthy without requiring a central authority that everyone must trust. A consortium of banks, a payment network connecting fintechs, or a government-operated clearing system — all of these can use the same ledger knowing that no single participant can alter records undetected.

Scales from simple to complex

A fintech connecting to three banks and a mobile money provider traditionally needs four separate integrations, four reconciliation processes, and custom routing logic to tie them together. With the ledger, each bank and the mobile money provider is a participant with its own accounts. Payment routing is configuration. Reconciliation is automatic. Adding a fifth bank means adding one more participant and one more connection — the existing rules and balances keep working exactly as before.

The ledger grows with the use case. Start with a simple two-party settlement and expand to a full payment network without re-architecting the foundation.

Building blocks

The ledger organizes everything around a small set of records that work together:

• Signers prove who is authorizing an operation — every action requires a cryptographic signature. See About Signers for how key management and authorization work.
• Symbols define what is being counted — currencies, loyalty points, tokenized assets, or any other unit of value
• Wallets hold balances and carry business rules — from bank settlement accounts to individual customer positions
• Intents move balances between wallets — the ledger's equivalent of a payment instruction, with built-in coordination across systems

Beyond these, bridges connect external systems to the ledger, policies control access and authorization, and effects trigger notifications when data changes. Together, these building blocks cover identity, currency, accounts, transactions, integration, and security.

What's next

See About Wallets to understand how wallets represent accounts, enforce rules, and connect to external systems. Or jump to Send a Payment to try the ledger hands-on.