> ## Documentation Index > Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt > Use this file to discover all available pages before exploring further. # Building a complete core banking > How the Lerian pieces come together into one working core banking — what connects to what, and how much you wire yourself versus what comes pre-configured. In [Fundamentals](/en/fundamentals/core-banking/what-is-core-banking) 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**: the Ledger, plus the products and plugins you choose. Each piece is its own service and can be adopted on its own — that's a feature, not a missing integration. By design, they 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](/en/products-and-plugins) for what's included. ## Start with the ledger *** Everything records in **Midaz**, the Ledger — it's the foundation the rest builds on. Stand it up first. **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. (This is different from the pieces below, which are separate services.) → [Set up Midaz](/en/midaz/midaz-setup) · [CRM in Midaz](/en/midaz/crm/crm-overview) ## Connect the pieces to the ledger *** The other pieces are **standalone services**, 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 and fees plugins, Tracer, Reporter, and the Midaz ledger * **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](/en/midaz/plugins/ted/ted-configuration) * **The Fees Engine calculates; your app records.** Your application calls the **Fees Engine** to compute the fees for a transaction; it reads Midaz to resolve the accounts and returns the result. Your app then submits the transaction — fees included — to Midaz, so the Fees Engine never writes to the ledger itself. (For any movement you record without a plugin, your application writes to Midaz's API directly.) → [Connect the Fees Engine to Midaz](/en/midaz/plugins/fees-engine/connecting-fees-to-midaz) * **Reporter comes already connected to your data.** It reads the data behind your Lerian products (read-only, one direction) to build statements and reports — it never writes back. That connection is set up for you during onboarding, so it works from day one; you build the **report templates** you need, and can add your own data sources later. → [Reporter](/en/reporter/reporter-quick-start) * **Tracer is isolated — your application orchestrates.** Tracer doesn't connect to the ledger at all. Your code calls Tracer's validation first, and only sends the transaction onward — to a plugin or to Midaz — if the decision is **ALLOW**. Tracer and Midaz never talk directly. → [Tracer integration guide](/en/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](/en/platform/access-manager/access-manager) ## Deploy the stack *** There's no single "install everything" bundle — you deploy each piece (one Helm chart per product) 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](/en/platform/helm/helm-overview) ## 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](/en/lerian-console/about-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 core banking is the composition above. When you need more, the same model extends — for example **[Matcher](/en/matcher/what-is-matcher)** (reconciliation) or **[Flowker](/en/flowker/what-is-flowker)** (workflow automation). They aren't part of core banking, but they plug into the same stack when your needs grow.