Core concepts

Every resource you create in Monime lives inside a Space, is acted on by a Monimeer, moves money through a Financial Account, and can be traced back to its origin through the Ownership Graph.

How they fit together

A Monimeer can belong to several Spaces. Everything a Space does with money flows through its Financial Accounts, and every resource records where it came from in its Ownership Graph.

Space

A Space is the foundational unit of isolation in Monime. It represents an organizational entity — a business, company, merchant, platform, government institution or NGO — and everything associated with its payment operations and financial identity.

Monimeer

A Monimeer is a personal user account — a developer, operator or member of a finance team. Unlike Spaces, Monimeers are personal and global across Monime.

Role-scoped authorization

Monime uses a dual-layer permission system to control what a Monimeer can do within a Space:

1. Dashboard access is determined solely by the roles (permission sets) assigned to the Monimeer in that Space.
2. API access is determined by the intersection of the Monimeer's roles in the Space and the roles assigned to the access token they create.

API access tokens can never exceed the permissions of their creator, but they can be scoped down for security. For example, a Monimeer with full transfer management rights in the dashboard can create a token with read-only transfer access, but cannot create a token with webhook management if they lack that dashboard role.

Financial Account

A Financial Account is an internal ledger abstraction that represents where money is held, routed or reconciled. It is the heart of money management in a Space: every financial operation — payment, disbursement, internal transfer and so on — is scoped to a financial account.

Ownership Graph

The Ownership Graph captures the complete lineage of any object in Monime. Every financial resource carries an immutable chain of relationships that traces back to the object that created it, answering questions like:

• What triggered this transaction?
• Who initiated the original action?
• What was the business context?
• How did we get here?

Each node names its owner, so the chain can be followed from a payment back to the API request that started it:

{
  "ownershipGraph": {
    "owner": {
      "id": "pmt-k6Em1Aap25VZ8oWg7ajhxHX3JqF",
      "type": "payment",
      "metadata": {
        "channel": "momo",
        "provider": "m17"
      },
      "owner": {
        "id": "sps-k6Em1aAap254VXg6fhxk9HX3JqF",
        "type": "checkout_session",
        "metadata": {
          "orderId": "ord-3n4o5p6q7r8s"
        },
        "owner": {
          "id": "arq-k6Em12r5VZ8oW9r9Xh7xsH3J4qF",
          "type": "api_request",
          "metadata": {
            "endpoint": "/v1/checkout-sessions",
            "subjectId": "acc-k6Em15VsZ8go5W9lX2h7dxsJ4qF",
            "ipAddress": "192.168.1.100"
          }
        }
      }
    }
  }
}

The same idea applies to every chain of resources, for example a payment code:

Payment Code
└── Payment (when someone pays)
    └── Financial Transaction (when the payment is processed)
        └── Fee Transaction (when your service fee is taken)

Next steps