Skip to main content

​
Why does this matter?

Every regulation, from GDPR to LGPD, shares one principle: you use personal data only for the purpose the user agreed to. The CRM is part of the Midaz ledger. It handles transactional and non-transactional flows, so it must protect the sensitive data these flows carry. Although Lerian doesn’t offer cybersecurity services, we follow strict information security practices in all software we ship.

​
Security responsibilities

As an on-premise technology provider, Lerian does not oversee or enforce our clients’ cybersecurity policies. We respect the trust-based relationship each institution has with its end users. We assume that each client follows the LGPD and any other data protection regulation that applies to its region or industry. Still, Lerian delivers technology that follows strong, market-aligned security practices. These practices protect sensitive CRM data as follows:

​
In transit

TLS over HTTPS protects all data that you exchange with the CRM. The CRM encrypts sensitive fields before it writes them to the database. This applies to every request that creates or updates a holder or an instrument.

​
At rest

The CRM runs on-premise, so disk and volume encryption is the client’s responsibility. We strongly recommend it. It adds a robust layer of protection.

​
How we protect data

The CRM uses different protection methods. The method depends on the type of data and its intended use.
  • Encryption protects values that the system might need to read again, such as names or contact information.
  • Hashing protects values that the system never shows again but must still match, such as identifiers for filtering or lookup.
The CRM protects sensitive data as soon as the data reaches it. The CRM never stores or processes sensitive data in raw form.

​
Encryption and hashing strategies

The CRM combines several cryptographic techniques that follow industry best practices. These techniques protect sensitive data and still support the application.

​
Encryption

The system must read or show some fields again, such as personal names or emails. The CRM encrypts each of these values with strong, symmetric encryption. Even if someone reads the database directly, the original values stay unreadable without proper authorization. Encryption also adds a random component, so identical values never produce the same encrypted output.

​
Hashing

The CRM hashes certain fields to allow secure filtering without exposure of the original value. It stores these hashes in a separate internal structure for fast, secure lookups.
In some cases, the CRM hashes a field only to meet an internal database constraint, even when the field is not searchable.

​
Key management

The CRM uses encryption keys and hashing keys. The deployment team must generate, store, and manage these keys securely. Keys must follow strong cryptographic standards. Never hardcode a key or expose it in source code or version control.
Protect your keys with a dedicated secret manager or secure storage. If an attacker compromises a key, rotate it and re-encrypt or re-hash the affected data.

​
Protected fields

The CRM protects the fields listed below. You do not need to know how this protection works. Do not enter sensitive data in any field that this list does not include.
Never store sensitive information in the metadata object.

​
Holder

  • name
  • document
  • contact.primaryEmail
  • contact.secondaryEmail
  • contact.mobilePhone
  • contact.otherPhone
  • naturalPerson.motherName
  • naturalPerson.fatherName
  • legalPerson.representative.name
  • legalPerson.representative.document
  • legalPerson.representative.email

​
Instrument

  • document
  • bankingDetails.account
  • bankingDetails.iban
  • regulatoryFields.participantDocument
  • relatedParties.document

​
Best practices & recommendations

Data encryption in the CRM adds a strong security layer. Even if an attacker compromises the database, the sensitive data stays inaccessible in its original form. The CRM decrypts data only with a valid key, or through authenticated and authorized service calls. Key security is therefore critical. If a key leaks, the application cannot protect your data on its own. To keep your environment safe, we strongly recommend:
  • Do not expose the Midaz API directly on edge layers such as gateways or frontend apps.
  • Never store sensitive data in metadata fields. The CRM does not encrypt them.
  • Enforce governance over access to the production environment and related tools.
  • Use secure key managers with strict access controls to safeguard your secrets.
  • Encrypt disks or volumes to protect data at rest.
If an attacker compromises a key, or if you must rotate it, you must generate a new key and re-encrypt the affected data. Use the CRM’s available services for this.
Data security is a shared responsibility. The CRM gives you the building blocks. Make sure your deployment uses them well.