Originate a loan

Walk a loan application through its lifecycle — preview the schedule, submit, decide, and disburse — and see the loan account it produces.

Origination is the journey from “a borrower wants credit” to “a loan account exists and the disbursement is recorded.” Lender models it as an explicit application lifecycle so every decision is recorded and every disbursement is traceable.

The application lifecycle

---

An application moves through named states. Each transition is a distinct operation, and each keeps a decision or disbursement record:

submit ─────► pending_approval ── approve ──► approved ── disburse ──► loan account
                    │       │                     │
                 reject  withdraw               withdraw

Steps

---

1. Preview the schedule (optional)

   POST /api/v1/loan-applications/preview-schedule computes the amortisation schedule for prospective terms without originating anything. Use it to show installments and disclosures before anyone commits.

2. Submit the application

   POST /api/v1/loan-applications creates the application against a product version.

3. Decide

   Resolve the application with exactly one of:

   • POST /api/v1/loan-applications/{id}/approve — accept it; a decision record is kept.
   • POST /api/v1/loan-applications/{id}/reject — decline it, with a decision record.
   • POST /api/v1/loan-applications/{id}/withdraw — retract it while pending approval or, after approval, before disbursement.
4. Disburse

   POST /api/v1/loan-applications/{id}/disburse records the funds delivered. Send an X-Idempotency key: while the idempotency store is reachable, a retry with the same key replays the first response and records no second disbursement. The middleware fails open during an idempotency-store outage, so confirm the outcome before you retry an ambiguous failure.

   One database transaction commits the disbursement event, the origination schedule, and a balanced posting intent. When the call returns, the loan is an active loan account you service from here on.

   The ledger booking is not in that transaction. When the ledger relay is configured, an outbox dispatcher relays the intent to Midaz shortly after the response, through the product’s accounting profile; otherwise the intent remains in the outbox. See the posting path.

What you get

---

Disbursement produces a loan account — the servicing view of the live contract, carrying its schedule, transactions, charges, and audit history. Continue in Service a loan.

What happens downstream

---

When streaming is enabled and a broker is configured, the lifecycle emits loan_application.submitted.v2, loan_application.approved.v2, loan_application.rejected.v2, loan_application.withdrawn.v2, and loan_application.disbursed.v2. Disbursement records a durable posting intent and relays it to the ledger only when the ledger relay is configured. Read the posting path.

Brazilian origination adds regulated steps — CET disclosure and capitalization consent — covered in the Brazil regulatory pack. The payroll-deducted consignado flow forms its own Brazilian bounded context. See Consignado privado.

Next steps

---

Service a loan

Record repayments, prepay, reschedule, and correct an active loan account.