Corebank
Financial infrastructure
In development · working prototypeFinancial infrastructure for recording and moving money: a double-entry ledger, provider integrations, and spending policy enforced server-side before funds ever leave.
Corebank in one picture
What it is
Corebank is being developed as the financial infrastructure layer for the businesses Odusipe Enterprise intends to operate. Its job is unglamorous and absolute: every movement of money is recorded as a balanced entry, balances are derived rather than stored, and a retried request can never move money twice.
It is self-hosted against the operator's own payment credentials. Corebank does not hold funds, does not take deposits and is not a licensed payment service; the deployment, the provider relationship and the regulatory obligations belong to whoever runs it.
The mechanism, not the pitch
| Account | Debit | Credit |
|---|---|---|
| agent:ops-runner-3 · wallet | 125,000.00 | — |
| payee:qt-logistics · settlement | — | 125,000.00 |
| Sum | 125,000.00 | 125,000.00 |
- Balance check
- sums to 0.00 · accepted
- Idempotency key
- pay_2026_10_28_7f3a · unique
- Posting state
- immutable · corrections reverse
Development status
Built means written, tested and running. Intended means exactly that.
Built and tested today
A double-entry general ledger
Postings inside an entry sum to exactly zero or the entry is rejected. Postings are immutable, and corrections are new reversing entries, so history is append-only and auditable.
Balances that cannot drift
Balance is the sum of postings and available is balance minus active holds. Neither is ever stored. Money is integer minor units throughout; no float touches a balance.
Deny-by-default spending policy
Per-transaction ceilings, rolling daily and monthly caps, a daily payout-count ceiling, timezone-correct resets, payee allowlists, approval thresholds and freezes, all evaluated server-side before funds are held. With no limits set, every payout is refused.
Idempotency enforced by the database
One idempotency key produces at most one entry, ever, by a UNIQUE constraint rather than an application check.
Payout lifecycle with holds
Money committed to an in-flight payout is held, so it cannot be withdrawn twice; webhook settlement captures the hold, and reconciliation re-queries the provider when a notice never arrives.
Verified provider webhooks
Inbound notices are authenticated by HMAC over the raw body with a constant-time comparison, and fail closed without a valid signature.
An operations dashboard and a typed tool surface
A dashboard for the human who sets the limits, and an MCP server so an agent spends through typed tools instead of hand-rolled HTTP.
Zero third-party dependencies
Python standard library only, by design: fewer moving parts to audit, patch and trust.
Intended, not yet built
Inbound collections
Virtual-account callbacks are not implemented; the deposit path is operator-gated and stands in for them.
Live money movement, proven end to end
Provider reads are confirmed against a live key. The paths that move money wait on provider approval and a real settlement notice before they can be trusted with money.
Multi-process deployment
Correctness currently assumes one process owns the database file. Horizontal deployment needs a different storage engine behind the same interface, not a second worker.
Operational observability
Health and a reconciliation exit code exist; metrics and structured logging do not yet.
Independent review
No external security audit has been performed.
Intended use cases
- Recording transactions for a business that cannot tolerate a wrong balance.
- Holding spending authority for automated systems and staff accounts under limits a human sets.
- Reconciling provider notices against an internal ledger.
- Serving as the shared financial layer for several businesses, subject to the necessary provider approvals and applicable regulation.
What an operator sees
POST /v1/webhooks/provider content-length=412
signature header present ................ yes
hmac-sha256 over raw body .............. compare_digest
verdict ................................ accepted
event id ............................... evt_8c1d2f (first delivery)
payout reference ....................... PO-91D4 (status: successful)
hold captured .......................... 125,000.00 NGN
ledger entry ........................... LE-4F82C1 (sums to 0.00)
POST /v1/webhooks/provider content-length=412
signature header present ................ yes
hmac-sha256 over raw body .............. mismatch
verdict ................................ 401 rejected, body never parsed
POST /v1/webhooks/provider content-length=412 (replay of evt_8c1d2f)
signature header present ................ yes
verdict ................................ accepted, claim already held
effect ................................. none · no second captureFails closed: an unsigned or mis-signed notice is rejected before the JSON is parsed, and a replay changes nothing.
Reconciliation, and knowing when to stop
Automatic correction of a ledger is how money disappears. Corebank re-queries the provider, records what it found, and asks for a human when the two sides disagree.
| Payout | Amount | Provider | Books | State |
|---|---|---|---|---|
| PO-91D4 | ₦125,000.00 | successful | LE-4F82C1 | matched |
| PO-91D5 | ₦18,400.00 | successful | LE-4F82C4 | matched |
| PO-91D6 | ₦72,500.00 | pending | hold active | re-query due |
| PO-91D7 | ₦9,000.00 | failed | LE-4F82C9 reversal | returned |
Exit code 2 when a human is needed. Nothing is auto-corrected on the books.
Context
Talk to us about it
Corebank is in development and not generally available. Integration conversations, provider discussions and technical review are all welcome now, and they are what shapes what gets built next.
Tell us what you are building.
We answer every serious message.
Expect a reply within two business days, from a person.
- hello@odusipe.tech
- Base
- Lagos, Nigeria
- Working with
- Businesses, providers, partners, engineers