{
    "id": null,
    "status": "pending",
    "amount": {
        "currency": null,
        "value": null
    },
    "sourceFinancialAccount": {
        "id": null
    },
    "destinationFinancialAccount": {
        "id": null
    },
    "financialTransactionReference": null,
    "description": null,
    "failureDetail": {
        "code": "unknown",
        "message": null
    },
    "ownershipGraph": {
        "owner": {
            "id": null,
            "type": null,
            "metadata": null,
            "": null
        }
    },
    "createTime": null,
    "updateTime": null,
    "metadata": null
}
An Internal Transfer is the movement of funds between financial accounts that exist within the same Space.
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.     
{
    "id": null,
    "status": "pending",
    "amount": {
        "currency": null,
        "value": null
    },
    "sourceFinancialAccount": {
        "id": null
    },
    "destinationFinancialAccount": {
        "id": null
    },
    "financialTransactionReference": null,
    "description": null,
    "failureDetail": {
        "code": "unknown",
        "message": null
    },
    "ownershipGraph": {
        "owner": {
            "id": null,
            "type": null,
            "metadata": null,
            "": null
        }
    },
    "createTime": null,
    "updateTime": null,
    "metadata": null
}
​
📋
Properties
​
id
string
Unique identifier for this transfer object.
​
status
enum<string>
Current status of the transfer:
  • ‘pending’: Created but not yet processed.
  • ‘processing’: Currently being processed.
  • ‘failed’: Transfer failed.
  • ‘completed’: Transfer successfully completed.
Available options: pending processing failed completed
​
amount
object
Amount to be transferred from the source to the destination account.
​
sourceFinancialAccount
object
Source financial account from which the funds will be debited.
​
destinationFinancialAccount
object
Destination financial account to which the funds will be credited.
​
financialTransactionReference
string
Reference to the resulting financial transaction(s), if the transfer was completed.
​
description
string
Human-readable description of the transfer. Useful for developer context, admin UIs, or logs.
​
failureDetail
object
Failure details, populated only when the transfer status is ‘failed’.
​
ownershipGraph
object
Ownership chain that shows which object or action triggered the transfer — enabling audit traceability.
​
createTime
string
Timestamp indicating when the transfer was created.
​
updateTime
string
Timestamp of the most recent update to the transfer.
​
metadata
object
Custom metadata for tagging this transfer with additional context or identifiers.