> ## 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.
# Lender architecture
> The parts Lender is built from: five domains, the jurisdiction profile that supplies every market rule, the request pipeline, and the outbox that carries money to the ledger.
Lender is one service. Inside it, five domains own the credit journey, a jurisdiction **profile** supplies every market-specific rule, and money reaches the ledger through a durable queue instead of an inline call.
Those three facts explain most of what follows.
## Five domains, one service
***
| Domain | What it owns | Where it stops |
| --------------- | ---------------------------------------------------------------------------------------------- | --------------------------------------------------------------- |
| **Products** | Loan products, product versions, charge templates, floating-rate tables. | A version never changes. New terms are a new version. |
| **Origination** | The application lifecycle, and the schedule that disbursement produces. | It records the intent to book. It does not write to the ledger. |
| **Servicing** | The active loan account: schedule versions, repayments, prepayments, reschedules, corrections. | It never edits history. A correction is a new transaction. |
| **Accounting** | Accounting profiles, posting rules, posting intents, accrual runs, journal references. | It builds balanced postings. The relay delivers them. |
| **Audit** | The trail of what happened to a loan account. | Append-only. Nothing rewrites an event. |
Each domain owns its own tables and its own operations. The **loan account identifier** is the key that joins them. Lender does not mint that identifier — you supply it when you disburse, and every domain addresses the loan by it from then on.
## The jurisdiction seam
***
Credit rules differ by market, so no domain names a market. Everything market-specific arrives through a jurisdiction profile, which supplies a fixed set of capabilities:
* The tax engine that computes withholdings at disbursement and revenue taxes on accrual.
* The holiday calendar and the day-count convention.
* The effective-cost method behind the cost disclosure.
* The caps registry that holds regulated rate and fee limits.
* The disclosures the market requires.
* The disbursement pipeline that runs inside the disbursement transaction.
* The product validator and the schedule-preview extension.
* The actor policies that decide who may approve and who may disburse.
Profiles are compiled into the service rather than configured at runtime. Two ship today: **BR** for Brazil, and **XX**, a generic baseline with no taxes and no caps. The jurisdictions table in the database is a projection of what the service carries, so no API call creates a jurisdiction. See [Jurisdictions](/en/lender/jurisdictions).
## How a request resolves
***
Every request passes the same three gates before a handler runs.
Lender expects a bearer JWT. The two jurisdiction-discovery reads are the only public operations.
The tenant comes from the validated identity. It is never a header, a body field, or a path parameter, so a caller cannot select a tenant.
Lender reads the tenant's jurisdiction binding and puts the matching profile in the request context. The lookup is cached for five minutes, so a rebinding takes effect within that window.
Bind every tenant to a jurisdiction before it sends traffic. Lender refuses a request from an unbound tenant.
## Money leaves through the outbox
***
Lender never posts to the ledger during your request. The path has four properties worth knowing:
1. A disbursement, an interest accrual, and a settled Brazilian prepayment quote each write a **posting intent** in the same database transaction as the business row. A crash between the two is not possible.
2. A dispatcher reads the intent from the outbox and relays it to Midaz.
3. Each intent carries a deterministic idempotency key, so a retried relay collapses onto one ledger transaction.
4. Routing fails closed. A posting books into the organization and ledger that the accounting profile resolves, and a single-tenant deployment can fall back to its configured default. When no target resolves, Lender does not post at all.
Configure the ledger endpoint and its credentials before you expect bookings. Until they resolve, intents wait in the outbox and nothing reaches the ledger.
[Lender in the platform](/en/lender/lender-in-the-platform) covers the full path, including what the accounting profile contributes to it.
## What the service exposes
***
| Surface | Purpose |
| -------------------------------- | ------------------------------------------------------------------------------------------- |
| `/api/v1/...` | The whole product API, described by one OpenAPI document. |
| `/health`, `/readyz`, `/version` | Liveness, dependency readiness, and build metadata. All three answer before authentication. |
| `/api/v1/streaming/manifest` | The catalog of events this deployment publishes. |
| `/api/v1/systemplane/...` | Runtime configuration administration. |
Read the [health and readiness reference](/en/reference/health-and-readiness) for the probe contract shared across Lerian products.
## Stores
***
| Dependency | Role |
| --------------- | ---------------------------------------------------------------------------------------------- |
| PostgreSQL | Every domain table, and the outbox. Two migration sets apply: the core set and the Brazil set. |
| Valkey or Redis | Idempotency records, and the jurisdiction cache. |
| RedPanda | Lifecycle events, when streaming is enabled. |
| Midaz | The destination of every posting. |
[Configuration and deploy](/en/lender/configuration-and-deploy) lists the settings behind each one.
## Time-driven work
***
Not everything starts with a request. The accrual run also runs as a scheduled job. Every job stays off until you enable it, and you set its schedule. See [Accounting and accrual runs](/en/lender/accounting-and-accrual-runs).
## Next steps
***
One application from submitted to disbursed, and the transaction that does the work.
The vocabulary the whole product shares.
The posting path, the event catalog, and tenant isolation.
Dependencies, the container, and the settings that shape a deployment.