Skip to content

Platform Overview

This page gives a technical picture of how Regini is built, enough for your engineering team to evaluate the integration with confidence, without going into proprietary implementation detail.

Architecture summary

Regini is a multi-tenant financial technology platform. Each partner is a tenant with strict data isolation: your accounts, transactions, and treasury are never visible to or accessible by other partners at any layer of the stack.

The core of the system is a double-entry accounting ledger. Every financial operation (deposit, withdrawal, fee, yield credit) is recorded as a balanced journal entry before anything else happens. Balances are always derived from the ledger, never stored and updated in place. This design makes the system inherently auditable and prevents balance drift even under concurrent load or partial failures.

Infrastructure layers

Fiat rails: M-Pesa via Kotani Pay

KES moves in and out via M-Pesa. We use Kotani Pay as our M-Pesa infrastructure provider. Each partner tenant has a dedicated Kotani Pay fiat wallet, used exclusively for that tenant's KES collections (deposits) and payouts (withdrawals). For deposits, we trigger a STK push to the user's phone; they confirm, and KES is collected into your tenant's wallet. For withdrawals, we instruct a B2C payout directly to their M-Pesa number from the same wallet. Both legs are asynchronous; Regini reconciles the payment confirmation and then credits or debits the ledger atomically.

On-chain custody: Turnkey sub-organisations

User funds are held on-chain in USDC on the Solana blockchain. Each partner tenant is provisioned a dedicated Turnkey sub-organisation containing a Solana wallet and an EVM wallet. Regini uses these wallets for all treasury movements on your behalf: USDC in on deposits, USDC out on withdrawals, and yield operations in Phase 2. We use Turnkey for wallet infrastructure, a non-custodial signing service with hardware security module (HSM) backing, meaning no private keys are ever accessible in plaintext at rest. Sub-wallets are provisioned per account for on-chain traceability.

Conversion: live FX

KES/USDC conversion uses a live mid-market rate refreshed from our FX provider every 2 hours. Partners have a program-level spread (in basis points) applied on top of the mid-market rate. Quoted rates are locked for 10 minutes as a single-use commitment, protecting users from rate movement between quote and execution.

API and backend

The Partner API is a REST API over HTTPS, versioned at /partner/v1. It is stateless; no session state is held server-side; all calls are authenticated via API key. All financial endpoints require and enforce an Idempotency-Key header, making retries safe in the event of network failures.

Events (deposit completed, withdrawal completed, etc.) are delivered to your system via signed webhooks.

Multi-tenancy and isolation

Layer Isolation mechanism
Database Row-level security on every table; all queries are scoped by tenant_id
API API keys are tenant-scoped; a key cannot access another tenant's accounts or transactions
Fiat wallet Each tenant has a dedicated Kotani Pay wallet; KES collections and payouts are never commingled
On-chain treasury Each tenant has a dedicated Turnkey sub-organisation with its own Solana and EVM wallets
Webhooks Events are routed to the webhook URL registered for your tenant only

Financial correctness guarantees

  • Immutable ledger. Ledger entries are never updated or deleted. Reversals are recorded as new, offsetting entries. This provides a complete audit trail from day one.
  • Atomic operations. Deposits and withdrawals either complete fully or fail cleanly. There is no partial state.
  • Idempotency. Account creation is idempotent on external_user_id. Deposits and withdrawals are idempotent on Idempotency-Key. Safe to retry without risk of double-execution.
  • Float visibility. GET /summary exposes your treasury balance vs. AUM at any time, so you always know whether your treasury is adequately funded.

Event model

Regini is event-driven at the integration boundary. Your system does not need to poll for transaction status; we push signed webhook events when state changes. Webhooks are delivered with exponential-backoff retry (up to 6 attempts). Webhook delivery failures do not affect the underlying transaction or ledger state.

Roadmap

Phase 2: Yield

Accounts with yield enabled will automatically earn dollar-denominated returns on their USDC balance. Yield is sourced from on-chain lending markets and credited through the same double-entry ledger. Whether yield is available for your tenant is configured at onboarding. Accounts provisioned today with yield_enabled: true carry forward into Phase 2 automatically, no re-integration required.

Regini charges a 15% performance fee on gross yield generated, deducted before crediting user accounts. No fee is charged if no yield is generated.

Integration checklist for technical teams

Before going live, your team should have:

  • [ ] A sandbox API key and confirmed end-to-end deposit and withdrawal flow in sandbox
  • [ ] Webhook endpoint deployed and signature verification in place
  • [ ] Idempotency keys generated per-request (not reused across retries of different operations)
  • [ ] account_id stored durably against your external_user_id in your database
  • [ ] Production API key stored in a secrets manager, not in code or environment files