Unlike payouts or customer payments that cross external networks (banks, card schemes, or mobile money), an Internal Transfer happens entirely within Monimeβs ledger. It is the mechanism for shifting balances between accounts you own or manage, and it never leaves your organizationβs financial boundary.
Use Cases
-
Wallet Top-ups
A customer wallet account can be funded by moving money from your master operational account.
Example: A user adds SLE 1,000 to their app wallet. Your backend issues an Internal Transfer from your Operational Float to the userβs Wallet Account. -
Inter-Account Routing
Businesses often separate funds for accounting clarity (e.g., βCard Collections,β βMobile Money Collections,β βBank Transfersβ).
Example: At the end of each day, you route all Mobile Money collections into a central Settlement Account. -
Internal Settlements
Useful when multiple departments or sub-entities operate under one Space.
Example: Subsidiary A owes Subsidiary B SLE 50,000. Instead of moving money through the banking system, you perform an Internal Transfer inside your Monime ledger. -
Float Management
Fintechs maintain float across accounts to support disbursements.
Example: If your Disbursement Account is running low, you move funds from your Collection Account to top it up before processing payouts.
Unique identifier for this transfer object.
Current status of the transfer:
- βpendingβ: Created but not yet processed.
- βprocessingβ: Currently being processed.
- βfailedβ: Transfer failed.
- βcompletedβ: Transfer successfully completed.
pending
processing
failed
completed
Amount to be transferred from the source to the destination account.
Source financial account from which the funds will be debited.
Destination financial account to which the funds will be credited.
Reference to the resulting financial transaction(s), if the transfer was completed.
Human-readable description of the transfer. Useful for developer context, admin UIs, or logs.
Failure details, populated only when the transfer status is βfailedβ.
Ownership chain that shows which object or action triggered the transfer β enabling audit traceability.
Timestamp indicating when the transfer was created.
Timestamp of the most recent update to the transfer.
Custom metadata for tagging this transfer with additional context or identifiers.