Skip to main content
A loan product is the template every loan originates from. Defining one is a small sequence: create the product, version its terms, describe how it books to the ledger, then activate the product. You originate each loan against a product version, and activation needs that version to carry an accounting profile.

​
Before you start

  • You need a Lender bearer token (a JWT issued by your Access Manager). Every operation is authenticated and tenant-scoped.
  • Decide which jurisdiction the product belongs to. Credit books under Brazil. The generic base, XX, books no credit. Brazilian products carry extra fields covered in the Brazil regulatory pack.

​
Steps

1

Create the product

POST /api/v1/loan-products registers the named product. This is the catalog entry the versions hang off. (Brazil has an alias, POST /api/v1/br/loan-products, that accepts the BR extensions.)
2

Create a version

POST /api/v1/loan-products/{id}/versions freezes a set of terms (rate configuration, term, and the schedule shape) as an immutable version. Every loan traces back to the version it used at origination. You never edit a version, you publish a new one. A version must declare its rate band and the borrower kinds it admits, or it originates nothing.
3

Attach charges

POST /api/v1/loan-products/{id}/charges applies a charge template (an origination fee, a service charge) that the loans originated from this product inherit.
4

Bind an accounting profile

POST /api/v1/loan-products/{id}/accounting-profiles declares how the product books to the . The profile carries the posting rules (which double-entry legs fire for each event) and the ledger organization and ledger they book into. Activation refuses a version that has no profile. See Accounting and accrual runs.
5

Activate the product

POST /api/v1/loan-products/{id}/activate sets the product to active and pins the version you name as its current version. Activation is a gate, not a label: until it happens, the product originates nothing. A Brazilian version also needs its carteira, normPortfolioClass, before it activates. Each application names the version it uses at origination, so existing loans keep the version they started on.

​
Promote a new version

Activation is the door the first version comes through. Promotion is the door for every version after it. It repoints a product that is already live at a different current version, without taking the product down and putting it back up. POST /api/v1/loan-products/{id}/promote names the version to pin. Brazil has an alias, POST /api/v1/br/loan-products/{id}/promote, that behaves identically. Promotion carries the same two readiness checks activation carries: an accounting profile is present, and the version is complete for its jurisdiction. It carries them because it is the same act. A second route without them would be a quiet way around the first.
Promotion changes no contract and no application. Every loan already written keeps the version it was born on. Its schedule, pricing, and charges read from that version for the life of the loan. Every application still in flight keeps its version too. Only new applications read the current version.

​
Inspecting products

A floating-rate product resolves its applicable rate from the table when the schedule needs it, rather than pinning a fixed rate at origination.

​
What happens downstream

Creating and activating products emits loan_product.created, loan_product_version.created, loan_product.activated, accounting_profile.configured, and loan_charge.applied on the event backbone (see Lender in the platform).

​
Next steps

Originate a loan

Take an active product and originate a loan against it.