Skip to main content
This plugin 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.

Open-source and versioned with Midaz

The CRM plugin is open source, 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 the CRM plugin locallyYou can run the CRM plugin 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. The CRM plugin 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 plugin. 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

The CRM plugin 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 open source 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 plugin 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 plugin into your environment. Whether you’re working with Access Manager, Fee Engine, Pix, or CRM, each plugin 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 plugin 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 the CRM plugin 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 plugin 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, the CRM plugin 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.

Next steps