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 on the generic XX profile.

​

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. Bind an accounting profile to that version before you disburse. The disbursement builds its posting from the profile’s legs, and a disbursement without a profile fails. See Define a loan product.

​

Preview, if you want it

---

Schedule preview computes the installments and the cost disclosure for prospective terms. It creates nothing and it changes nothing. 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, the requested principal, the requested monthly interest rate, the number of installments, and an expected disbursement date. Lender accepts up to 600 installments. One field is not in the body: 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. The schedule, the transactions, the charges, and the audit trail are all addressed by it.
• 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. The balance rule is the one that surprises integrators. Under the generic profile there are no withholdings, so net equals gross. A lower net leaves the posting unbalanced and Lender rejects the disbursement.

​

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 streaming backbone for each transition.

Continue in Service a loan.

​

Next steps

---