Skip to main content
CRM is not part of the ledger’s transactional domain. It adds business attributes to ledger accounts. It does not change the ledger’s logic, consistency, or performance. CRM is where user metadata lives. It does not hold balances, transfers, or fees. It records who is behind an account and what you need to run your business.

​
Versioned with Midaz

CRM ships inside the Midaz ledger and needs no separate license. Midaz is source-available. CRM shares the Midaz version. For example, Midaz v3.5.0 uses CRM v3.5.0. CRM runs in the same binary as the ledger. It is always available. You choose whether to store holder data and call its endpoints.
Test CRM locallyYou can run CRM with the Midaz stack locally, without Kubernetes, using our plugins-docker-compose repository.

​
Why use the CRM?

Midaz ledger accounts are generic by design. They are transaction-first and domain-agnostic. CRM adds meaning to those accounts and links each one to a user profile and a business context. You do not have to use CRM. You can adopt it later, only when your use case needs customer or business metadata beyond the ledger.

​
Example use cases

  • Banking (individuals and businesses): CRM stores identifiers like CPF or CNPJ, an address, contact details, or account numbers. Midaz runs the same transaction logic for both customer types.
  • Supply chains (supplier, factory, retailer): CRM tracks metadata like supplier IDs, warehouse locations, or contract details. This data does not belong in the transaction, but it drives business decisions.
CRM ships inside the Midaz ledger, so there is no separate service to deploy. Use it only if your product or regulatory context needs customer or business metadata.

​
Entities

CRM has two core entities:
  • Holder – The main entity in CRM. It represents the persona for a Midaz ledger account. It stores identity attributes and individual traits.
  • Alias Account – The business context for a Ledger Account in Midaz Ledger. It holds financial details such as bank account information.
Figure 1 shows how the CRM entities connect to Midaz.
How CRM entities, the Holder and the Alias Account, connect to accounts in the Midaz ledger

Figure 1. An illustration of how CRM entities connect to Midaz

​
Design principles

CRM focuses on:
  • Separation of concerns: It keeps user profile data out of transaction logic.
  • System performance: It adds no user-level orchestration inside Midaz core services.
  • Simpler deployment: CRM ships inside the ledger binary, with no separate service to run.
  • Clear domain boundaries: It evolves with Midaz without coupling to ledger internals.
CRM does not validate ledger-level rules or compliance processes such as KYC. It is a neutral, persistent data layer.

​
API behavior

CRM runs inside the Midaz ledger binary. It exposes a registry API for non-transactional data linked to Midaz accounts.
  • It does not enforce validations such as user status, risk profile, or document verification.
  • It is agnostic to the asset, ledger, or grouping logic used in Midaz accounts.
  • It gives consistent access to holder metadata without loading the transaction layer.

​
Security & compliance

Lerian ships Midaz and its components for on-premise deployment. You keep control of your infrastructure, compliance policies, and user-data lifecycle. CRM ships with Midaz and follows the same security standards as the rest of the platform:
  • Data in transit: Midaz encrypts it with industry-standard protocols.
  • Data at rest: Midaz protects it with encryption and fine-grained access control.
You own encryption key management. Use a secret-management service to store, rotate, and control access to keys.
You define and enforce your own policies for LGPD, GDPR, and other regional data-protection rules. CRM provides the structure. Review the Security recommendations before you deploy any component into your environment. Apply security best practices to every component — Access Manager, Fees Engine, Pix, and CRM. Secure network boundaries, manage secrets, apply patches, and enforce strict access control.

​
Data deletion strategies

CRM gives you full control over how it removes data. It offers two options:
  • Soft delete (default): CRM flags the record as deleted but keeps it in the database. Use it to keep an audit trail or to recover data later.
  • Hard delete: Where your policy permits removal, you can request deletion of the data. Physical removal depends on your retention, compliance, and legal-hold configuration.
Your policies define the behavior. CRM adapts to your compliance requirements.

​
Access control

To restrict who can access your CRM data, enable our Access Manager.

​
Enabling Access Manager

First, install Access Manager. Then open the Midaz ledger .env file and set these environment variables:
After you enable it, CRM enforces access permissions from your authentication setup.
Access Manager is available under the Enterprise model. To evaluate it, contact our team.
Ready to start? See Getting started with CRM for a step-by-step guide.

​
Next steps

Core concepts

Understand the key entities managed by CRM: Holders and Alias Accounts.

Explore the CRM API

Browse endpoints for holders, alias accounts, and related parties.

Using CRM

Learn how to register holders and link them to ledger accounts.