Skip to main content
CRM does not belong to the ledger’s transactional domain. Instead, it enriches ledger accounts with business-relevant attributes without interfering with the ledger’s logic, consistency, or performance. CRM is where user metadata lives. It’s not about balances, transfers, or fees—it’s about who’s behind the account and what you need to know to operate your business.

​
Source-available and versioned with Midaz

CRM is source available, does not require a license, and is maintained in the same repository as Midaz. Its version always matches the Midaz Core version (for example, Midaz v3.5.0 → CRM v3.5.0). Although versioned together, CRM is deployed independently and can be enabled or omitted depending on your use case.
Test CRM locallyYou can run CRM locally without deploying to Kubernetes using our plugins-docker-compose repository.

​
Why use the CRM?

Midaz ledger accounts are generic by design, built to be transaction-first and domain-agnostic. CRM steps in to add meaning to those accounts, linking each one to detailed user profiles and business contexts. Because it is optional and independently deployable, CRM can be adopted incrementally—only when your use case requires customer or business metadata beyond the ledger.

​
Example use cases

  • Banking (individuals and businesses): CRM stores identifiers like CPF or CNPJ, address, contact details, or account numbers, while Midaz handles the exact same transaction logic for either customer type.
  • Supply chains (supplier, factory, retailer): CRM tracks metadata like supplier IDs, warehouse locations, or contractual information. This data does not belong in the transaction itself, but is essential for business decisions.
CRM is an optional component. You may deploy it only if your product or regulatory context requires customer or business metadata.

​
Entities

CRM revolves around two core entities:
  • Holder – The core entity in CRM, representing the persona associated with a ledger account on Midaz. It stores identity-related attributes and individual characteristics.
  • Alias Account – Defines the business context associated with a Ledger Account in Midaz Ledger, including financial details such as bank account information.
In Figure 1, you can find an illustration of how the CRM entities are connected to Midaz.

​
Design principles

CRM is built for:
  • Separation of concerns: Keeps user profile data out of transactional logic.
  • System performance: No user-level orchestration inside Midaz core services.
  • Deployment flexibility: Can be enabled, scaled, or omitted independently from the ledger.
  • Clear domain boundaries: Evolves alongside Midaz without coupling to ledger internals.
CRM doesn’t validate ledger-level rules or compliance processes like KYC. It’s a neutral, persistent data layer designed for maximum interoperability.

​
API behavior

CRM is implemented as a standalone registry API. It provides persistence and structured access to non-transactional data linked to accounts on Midaz.
  • 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 ensures consistent access to holder metadata without polluting the transactional layer.

​
Security & compliance

Lerian provides Midaz and its plugins as on-premise components—meaning you stay in control of your infrastructure, compliance policies, and user data lifecycle. Even though CRM is source available and license-free, it follows the same security standards as the rest of the Midaz platform:
  • Data in transit is encrypted using industry-standard protocols.
  • Data at rest is protected through encryption and fine-grained access controls.
Encryption key management is the customer’s responsibility. We strongly recommend using secret management services to store, rotate, and control access to keys.
We trust our clients to define and enforce their own policies around LGPD, GDPR, and other regional data protection regulations — the CRM simply provides the structure. However, to make the most of that structure—and ensure your data handling practices align with a secure and compliant environment— it’s essential to review the Security recommendations before deploying any component into your environment. Whether you’re working with Access Manager, Fee Engine, Pix, or CRM, each component should be implemented in alignment with security best practices — including securing network boundaries, managing secrets, applying patch management, and enforcing strict access controls. By following these guidelines, you help ensure every component runs securely, integrates smoothly with your infrastructure, and maintains compliance, data integrity, and user trust.

​
Data deletion strategies

At Lerian, we treat data ownership seriously. That’s why CRM gives you full control over how information is removed, with two built-in options:
  • Soft delete (default): The record stays in the database but is flagged as deleted. This is useful if you need to keep an audit trail or recover information later.
  • Hard delete: If your internal policy requires complete removal, you can use a specific command to delete the data permanently—no recovery.
Your policies define the behavior. CRM adapts to your compliance requirements without imposing constraints.

​
Access control

Need to restrict who can access your CRM data? You can enable our Access Manager to help you restrict who has access to the data.

​
Enabling Access Manager

To enable access control, first make sure Access Manager is installed. Then, open the .env file located in the root of the CRM folder using any text editor, and set the following environment variables: 
## AUTH
---

PLUGIN_AUTH_ADDRESS=http://plugin-auth:4000
PLUGIN_AUTH_ENABLED=true
Once enabled, CRM enforces access permissions based on your authentication setup.
Access Manager is available under the Enterprise model. If you’d like to evaluate it, get in touch with our team.
Ready to start? See Getting started with CRM for a step-by-step walkthrough.

​
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.