Skip to main content
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

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.

​
How a request resolves

Every request passes the same three gates before a handler runs.
1

Authentication

Lender expects a bearer JWT. The two jurisdiction-discovery reads are the only public operations.
2

Tenant resolution

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.
3

Jurisdiction resolution

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 covers the full path, including what the accounting profile contributes to it.

​
What the service exposes

Read the health and readiness reference for the probe contract shared across Lerian products.

​
Stores

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.

​
Next steps

How origination works

One application from submitted to disbursed, and the transaction that does the work.

Core concepts

The vocabulary the whole product shares.

Lender in the platform

The posting path, the event catalog, and tenant isolation.

Configuration and deploy

Dependencies, the container, and the settings that shape a deployment.