Skip to main content
In Fundamentals you learned the concepts. This page is how the Lerian pieces come together into one working core banking. A complete Lerian core banking is a deliberate composition: Midaz, plus the products and interfaces you choose. You can adopt a product on its own. That is a feature, not a missing integration. Midaz embeds CRM and the Fees Engine. Other pieces deploy separately, and Lerian does not pre-wire them to each other. You connect them in a setup step. How much of this you do depends on who runs your infrastructure:
  • Managed: Lerian runs your infrastructure and wires the pieces at deploy time. You open the Console, enable the products, and use them: no environment variables, no integration calls. (You won’t need the rest of this page.)
  • Self-hosted / BYOC: you run the infrastructure, so you do the wiring. Configure each product’s URLs and environment, and deploy it. The rest of this page walks that. After you connect it, you can operate from the Console or call the APIs directly. That is a UX choice, not extra wiring.
Enterprise is a commercial tier, not a deployment model. Enterprise clients can be managed or self-hosted. See Products, platform, and plans for what’s included.

Start with the ledger


Midaz is the ledger foundation of a Lerian core banking. Stand it up first when the capabilities you adopt record to Midaz. CRM is already part of Midaz. Midaz includes the holders and aliases you learned about. You wire nothing extra. You just enable it. Set up Midaz · CRM in Midaz

Connect the pieces to the ledger


Most other pieces are standalone services. The Fees Engine is the exception, because it runs inside the ledger process. The pieces do not all connect the same way. Here is who calls whom at runtime:
Runtime flow across your application, the payment plugins, the Fees Engine, Tracer, Reporter, and the Midaz ledger

Who calls whom at runtime

  • Payment interfaces write to the ledger for you. Your application calls a payment interface such as TED or Pix. The interface moves the money and records the operations in Midaz, even from its own background workers. Your application does not touch the ledger for those movements. Partner interfaces ship as Midaz plugins: separately deployed services that extend Midaz and that Lerian licenses separately. Lerian sets the connection to Midaz at deploy time, and your application never sees it. → TED setup
  • The Fees Engine runs inside the ledger. Lerian licenses the Fees Engine as part of the Midaz ledger process. When a configured fee package applies, Midaz adds the fee calculations to the transaction you submit. No separate fee service sits between your application and the ledger. Your application can still call the fees endpoints on the same process to estimate fees before it submits. For any movement you record without a payment interface, your application writes to the Midaz API directly. → Connect the Fees Engine to Midaz
  • Reporter reads configured data sources. It reads those sources in one direction only, to build statements and reports, and it never writes back. In a managed setup, Lerian configures the agreed data sources during onboarding. In self-hosted or BYOC deployments, configure a data source before you build reports that use it. → Reporter
  • Tracer connects to Midaz through configuration. Without TRACER_BASE_URL, the integration stays off. Set that variable, and Midaz initializes a reservation client that uses gRPC by default, or REST with TRACER_TRANSPORT=rest. Midaz calls reserve, confirm, and release only when tracer.mode holds a value other than off. Midaz honors a Tracer skip only when the request asks for it and the ledger enables allowTracerSkip. Midaz rejects the request in every other case. → Tracer integration guide
Your application can also integrate with Tracer on its own.
Tracer checks your configured policies and limits, not account balances. The ledger stays the source of truth for what an account actually holds.
The exact URLs, credentials, and environment settings live in each product’s own setup docs (linked above).

One login across the pieces


The pieces share authentication through Access Manager, so they work as one product and not as separate logins. Access Manager issues the tokens each service trusts, and it holds the credentials each piece uses. Keep those details in one place, and point every piece at it. Access Manager

Deploy the stack


There’s no single “install everything” bundle. Deploy each selected component with its supported distribution artifact and bring them up in order: Midaz → Access Manager → products and interfaces → Console The Console comes last because it needs the others already running. Helm charts

Operate it from the Console


After everything runs, the Console is your single pane of glass. Enable the pieces and manage them with one login. When you enable a module in the Console, it turns on in the interface and shares the login. The piece-to-ledger wiring is the deployment step above, and the Console does not do it for you. Lerian Console

On a managed setup


If Lerian runs your infrastructure, Lerian already did all the wiring above. From your side it is simple: enable the modules in the Console and start using them. You set no environment variables, and you run no deployment. The integration journey on this page is what Lerian handles underneath.

Going further (optional)


You assemble a complete Lerian core banking from modular building blocks. Add Matcher for reconciliation and Flowker for workflow automation when their capabilities fit your operation. Both deploy as pieces of the same platform and share the Access Manager sign-in. You connect them with the same deployment step above. Matcher answers the reconciliation solution, and Flowker answers the orchestration engine solution.

Solutions


Solutions group the catalog by the problem you solve: core banking, payment rails, reconciliation, loan management, and orchestration. This page describes the core banking solution.