Monite account structure

Overview

The Monite API uses different layers to secure access to any stored data within the platform:

Partner

A partner is a company that implements Monite API in its app or platform. This is a mandatory layer.

The development teams of the partners connect to Monite API with admin-level access tokens. These admin tokens enable partners to create and configure entities and access all resources of all entities they develop software for.

Entity

A customer of a partner – an entity – is either an organization or an individual. Each partner develops for one or more entities. With the ID of an entity is possible to obtain root access to all resources related to this specific entity only.

For example, Beispiel GmbH and Example Inc are both customers of NeobankA. Tokens issued for Beispiel GmbH only give access to the resources associated with Beispiel GmbH. Access to Example Inc. is not possible.

Entity user

The employees who work for an entity - this optional entity user access layer is for partners who want to use Monite security for rapid development rather than build their own custom access control logic.

Using Monite API, partners create customizable entity-level roles and permissions. Monite automatically monitors access policies for each API call.

For example, Maria is an accountant at Beispiel GmbH. Maria's access token gives access to resources within Beispiel GmbH according to Maria's permissions.

Connect entities

Partners must map each customer as an entity into Monite before they can execute any business operations. This prevents any data incidents between entities and ensures that each entity can access only its own data.

Each entity registers its operations and stores financial documents such as payables or bank transactions in an interface developed by the Partner. These documents are stored and processed by Monite in a dedicated and secure space.

Connect entity users

Partners may need to implement Role-Based Access Control (RBAC) to meet the needs of entities and entity users. The main purposes of user roles are:

Restrict access to sensitive data and actions: Secure different levels of company information from different roles or prevent specific roles from completing tasks such as executing payments in the name of the entity.
Delegate tasks among coworkers: These tasks automatically respect information and role security.
Monitor system changes: Check who added information or changed entity data in Monite.

For more information on existing roles, refer to Authentication

It's up to partners to thoroughly review their user flows and use cases and define specific roles and permissions.

Accounts Payable example roles

Below are some examples how these roles might look like for Accounts Payable:

Administrator: Superuser for financial processes. Administrators are also involved in user management.
Power user: Superuser for financial processes.
Approver: Sends payables and participates in approval policies.
Sender: Submits payables to Monite.
Accountant: Reconciles transactions with payables and exports files for accounting.

The following table describes the user rights that partners can parameterize and the recommended access level for each role:

Access right	Administrator	Power user	Sender	Approver	Accountant
User management	View, modify, add, or delete any user roles or user accounts	No rights	No rights	No rights	No rights
Payable management	View, modify, add, or delete any payable in any status or approval step	View, modify, add, or delete any payable in any status or approval step	Add payables to Monite and follow their lifecycle as observers. A sender can only follow the lifecycle. They cannot update a payable once it is uploaded to Monite	Add payables to Monite, then follow their lifecycle as observers. Approvers take part in approval policies and approve payables	No rights
Comment payables	View or add any comment on any payable	View or add any comment on any payable	Comment on payables that are not validated yet	Comment on payables after validation in the approval policies they were selected for	No rights
Create a To Do task	View, modify, add, or delete any task for payables in any status	View, modify, add, or delete any task for payables in any status	No rights	No rights	No rights
Mute a To Do task	Mute any task for any payable	Mute any task for any payable	No rights	Mute their own tasks	No rights
Transactions	View, or execute any payment operation	View, or execute any payment operation	No rights	No rights	No rights
Reconcile payables	Link any file to any transaction	Link any file to any transaction	No rights	No rights	Link any file to any transaction
Export payables	Export any file from the system	Export any file from the system	No rights	No rights	Export any file from the system

Accounts Receivable example roles

Below are some examples how these roles might look like for Accounts Receivable:

Administrator: Superuser for financial processes. Administrators are also involved in user management.
Power user: Superuser for financial processes.
Sender: Creates and issues any document.
Accountant: Reconciles transactions with receivables and exports files for accounting.

The following table describes the corresponding user rights:

Access right	Administrator	Power-user	Sender	Accountant
User management	View, modify, add, or delete any user roles or user accounts	No rights	No rights	No rights
Receivable management	View, modify, add, or delete any receivable in any status	View, modify, add, or delete any receivable in any status	Create receivables and send them to counterparts	No rights
Payment reminder config	Manage and initiate payment reminders	Manage and initiate payment reminders	Manage and initiate payment reminders	No rights
Payment terms config	Manage payment terms	Manage payment terms	No rights	No rights
Reconcile receivables	Link any file to any transaction	Link any file to any transaction	No rights	Link any file to any transaction
Export receivables/accounting sync	Export any file from the system	Export any file from the system	No rights	Export any file from the system