How origination works

Origination turns a request for credit into a live loan account. It has four decisions and one transaction that does everything at once. This page follows one application from submitted to disbursed.

​

What an application binds to

---

An application binds to a product version, never to a product on its own. The version pins the currency, the rate terms, and the accrual basis, so a contract always traces back to the terms it was created under. A later version does not change a loan that already exists. The product must be active, and the version must be the one the product currently originates on. Activation requires an accounting profile on the version. The disbursement builds its posting from the profile’s legs. See Define a loan product.

​

Preview, if you want it

---

Schedule preview computes the installments and the cost disclosure for prospective terms. When it records the result as an offer, it returns the offer’s identifier. It creates no application. Use it to show a borrower what the loan looks like before anyone commits. This step is optional.

​

Submit

---

The submit call creates the application in pending_approval. It carries the product version, the borrower and the borrower kind, the requested principal, the requested monthly interest rate, the number of installments, and an expected disbursement date. Lender accepts up to 600 installments. The requested rate must fall inside the version’s rate band. The body does not carry the assigned officer. Lender takes it from the authenticated subject of the submit call. Later decisions are checked against that officer, so submit with the identity that will also approve and disburse.

​

Decide

---

Exactly one decision resolves a pending application. An approved application can still be withdrawn. rejected and withdrawn are final, and nothing moves out of them. The approved amount is a limit, not a payment. It bounds every disbursement that follows.

​

Disburse

---

Disbursement moves money, so it carries the most guards. Three things belong in the request:

• An X-Idempotency header. Lender requires it on this operation.
• The loan account identifier. It is a UUID you choose, and Lender does not mint one for you. That identifier addresses the schedule, the transactions, the charges, and the audit trail.
• The gross requested amount and the net delivered amount.

Lender checks five rules. It checks the first four before it writes anything. It checks the balance rule inside the disbursement transaction, so a failure there rolls the whole disbursement back. Under BR the withholding is IOF. Quote it before you disburse with the tax preview in the Brazil regulatory pack.

​

One transaction, four results

---

A disbursement is a single database transaction. Four things happen inside it. All four commit together, or all four roll back together. There is no half-disbursed loan. If the schedule cannot be written, or the posting does not balance, the application stays approved.

​

More than one tranche

---

You can disburse an approved application more than once. The status stays disbursed, Lender appends another disbursement event, and Lender writes a new schedule version over the cumulative principal. The new version supersedes the previous one on read. The total across tranches still cannot exceed the approved amount, and every tranche uses the same loan account identifier.

​

Two callers, one application

---

Every lifecycle write states the status it expects to find. When two callers decide the same application at the same time, one wins and the other receives 409 Conflict without changing anything. A repeated disburse that does not match the first one is refused the same way.

​

The state model

---

​

What you have at the end

---

• An application that reads disbursed, with one disbursement event per tranche.
• A loan account under the identifier you supplied, carrying its schedule, its transactions, its charges, and its audit events.
• A posting intent on the way to the ledger. That booking is asynchronous, so it lands shortly after the request returns rather than during it.
• One lifecycle event on the event backbone for each transition.

Continue in Service a loan.

​

Next steps

---