Skip to main content

Business Rules — Extraordinary Amortization

This page consolidates the invariants that govern the creation, settlement and cancellation of an extraordinary amortization. Refer to it whenever the endpoint pages cite an error code, a field or a condition that needs additional context.

Reference date (reference_date)​

The reference_date is provided by the caller in the creation request and is the only temporal reference used by the service — the system never uses date.today(). All date-dependent logic (classification of overdue instalments, pro-rata Present Value discount, selection of instalments eligible for early_amortization) starts from this field.

Amortization types​

The 5 supported types and how each combines with the creation modes:

TypeModeinstallment_listDistribution ruleAllows partial payment
equal_amountMode 2 (Acquittance)Not sentProportional, overdue first and then futureNo
first_installmentsMode 2 (Acquittance)Not sentSequential across the first N instalmentsNo
present_amountMode 1 (Targeted)SentExplicit per instalment; discount orders interest → penalty → principalNo
matured_installmentsMode 1 (Targeted)SentOnly instalments already fallen dueNo
early_amortizationMode 1 (Targeted)Sent (exactly 1)A single future instalment with partial payment supportYes

Mode 1 — Targeted (with installment_list — an array of integer installment_number): uses the per-installment PV endpoint — one call per selected instalment. The service resolves each installment_number to the corresponding instalment of the security. Mode 2 — Acquittance (without installment_list): uses the bulk PV endpoint — a single call returns the PV of all instalments.

Early amortization (early_amortization)​

early_amortization is the only type that allows partial payment. All of the following conditions apply:

  • Exactly 1 instalment in installment_list — otherwise, EVC100015.
  • The target instalment must not be overdue — otherwise, EVC100016.
  • The amount must be ≤ the Present Value of the instalment — otherwise, EVC100017.
  • Partial payment is allowed. The state paid_amount > 0 AND paid_amount < expected_amount is derived from the columns; there is no new status enum value. pending_conciliation represents both "not paid" and "partially paid"; the transition to paid only occurs when total_paid_amount >= total_expected_amount - tolerance_amount.

Settlement flow​

Internal orchestration. Settlement of extraordinary events is executed by QI Tech (account-liquidation-api) upon detecting the payment — the integrator does not call any endpoint at this stage, nor receives a webhook dedicated to the status transitions. The rules below describe the internal behaviour so you understand what happens after creation.

Ordinary settlement emits the full total (rule 4). Ordinary settlement on the due_date continues to emit the instalment's full total_amount via SQS; there is no subtraction of paid_amount. The event reconciles the partially-paid state in its own early_amortization engine.

Cancellation and finalization​

Internal orchestration. Cancellation and finalization are triggered by a daily routine — the integrator does not call any endpoint to cancel or finalize an extraordinary amortization, and there is no tenant-facing webhook dedicated to these transitions. The description below is informative.

See also​