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 plugins you choose. Products can be adopted on their own — that’s a feature, not a missing integration. CRM and Fees are embedded in Midaz; other products and plugins deploy separately. By design, separately deployed pieces aren’t pre-wired to each other, so connecting them is 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. Once it’s connected, you can operate from the Console or call the APIs directly — that’s 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, plugins & 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. The holders and aliases you learned about are built in, so there’s nothing separate to wire — you just enable it. → Set up Midaz · CRM in Midaz

​
Connect the pieces to the ledger

Most other pieces are standalone services (Fees Engine is the exception; it runs inside the ledger process), and they don’t all connect the same way. Here’s who calls whom at runtime — that difference is the practical part:
Runtime flow across your application, the payment plugins, the Fees Engine, Tracer, Reporter, and the Midaz ledger

Who calls whom at runtime

  • Payment plugins write to the ledger for you. Your application calls a payment plugin (TED, Pix); the plugin moves the money and records the operations in Midaz — even from its own background workers — so your app doesn’t touch the ledger for those. Its connection to Midaz is set at deploy time, invisible to your app. → TED setup
  • The Fees Engine runs inside the ledger. The Fees Engine is a licensed capability that is part of the Midaz ledger process. When a configured fee package applies, Midaz incorporates the fee calculations into the transaction you submit; no separate fee service sits between your app 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 plugin, your application writes to Midaz’s API directly.) → Connect the Fees Engine to Midaz
  • Reporter reads configured data sources. It reads those sources (read-only, one direction) to build statements and reports — 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 can connect to Midaz when configured. When TRACER_BASE_URL is set, Midaz initializes a reservation client (gRPC by default; REST with TRACER_TRANSPORT=rest). It can call reserve, confirm, and release only when tracer.mode is configured and not off. A Tracer skip is honored only when the request asks for it and the ledger enables allowTracerSkip; otherwise the request is rejected. When the base URL is unset, the integration is disabled. Your application can still integrate with Tracer independently. → Tracer integration guide
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

So the pieces work as one product (and not as separate logins), they share authentication through Access Manager: it issues the tokens each service trusts. Each piece authenticates with credentials managed there — keep the details in one place and point the pieces 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 plugins → Console The Console comes last because it needs the others already running. → Helm charts

​
Operate it from the Console

Once everything is running, the Console is your single pane of glass: enable the pieces and manage them with one login. Enabling a module in the Console turns it on in the interface and shares the login — the piece-to-ledger wiring is the deployment step above, not something the Console does for you. → Lerian Console

​
On a managed setup

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

​
Going further (optional)

A complete Lerian core banking is assembled from modular building blocks. Add Matcher (reconciliation) and Flowker (workflow automation) when their capabilities fit your operation. Both deploy as pieces of the same platform and share the Access Manager sign-in; connecting them follows the same deployment step described above.