Disbursement: process and options

Disbursement is the process of moving money from the lender to the borrower. The platform supports multiple providers and two operating modes — Automatic and Manual — selected by the loan product configuration.

What drives the choice

The product group the borrower applied under defines a “Disbursement option” with two values:

• Automatic — the platform integrates with an external payment provider and moves the funds itself.
• Manual — a Credit Officer confirms the disbursement was performed outside the system (cheque, wire transfer, etc.).

In addition, an environment-level setting selects which automatic provider is wired up. The combination of these two values determines the actual disbursement sub-process used.

Provider mapping

The same mapping applies to both fixed-term loans (single disbursement at activation) and credit lines (each drawdown).

Manual disbursement tasks for the Credit Officer

When the product uses the Manual option, the Credit Officer is the operator who actually moves the money outside the system and then records that fact in the platform. There are two distinct user tasks, one per loan type. They look similar but operate on different objects and have different downstream effects (see Result of a successful disbursement below).

“Disburse funds” — fixed-term loan

Who performs it: A user with the Credit Officer role. The task lands in the Credit Officer task queue.

When it appears: Right after the loan agreement is signed, the loan is created in Pending status, and the system begins its disbursement process. If the product group is configured as Manual, the system creates this task instead of calling an automatic provider. The task is titled “Disburse funds, Application #{number}” — the loan application number is part of the title, so the operator immediately knows which deal is being disbursed.

What the operator sees: The “Disburse funds” form shows the full loan application picture, all read-only:

• A header with the borrower’s full name (clickable link to the borrower’s profile), the requested amount and term, and the approved amount and term.
• A General info tab with the application’s general info card.
• A Borrower details tab with the borrower’s general info.
• A Bank info tab with bank and financial information and (if available) the bank account verification card — this is the account the funds must be sent to.
• An Attachments tab with all supporting documents collected during origination.
• A Scoring tab and a Contract tab (the signed agreement).
• A “Disburse” panel at the bottom — the only editable area on the form.

What the operator decides: In the Disburse panel:

The operator does not decide the amount or the destination account — both are determined by the application. The amount is the application’s disbursement amount (approved amount minus any product fees); the account is the verified bank account on the application.

On submission: After the operator clicks “Submit,” the system:

1. Records a successful outbound Disbursement transaction with the chosen method, document number, the operator’s name, and the timestamp.
2. Activates the loan: the loan status flips to Active, and the linked application is marked as Disbursed.
3. Fires a “Disbursement created” signal that adds a Disbursement loan event, rebuilds the loan snapshot (principal balance set to the disbursed amount), and starts the daily interest accrual and scheduled payment timers.
4. Sends a “loan disbursed” notification to the borrower.

Validations and limits: The amount field is read-only and inherited from the application — there is no operator-side override, so there is no min/max to police on this form. The application must be in the right state for the task to even appear; if it isn’t, the task does not exist.

On failure / no decision: If the operator does not complete the task within 5 days, the system unassigns it and ends the disbursement attempt with a “Disburse funds decision hasn’t been made” outcome. This bubbles up to the parent flow as a disbursement failure: the loan and application are marked as Error, and a “Disbursement failed” terminal state is reached. The deal cannot continue without manual intervention. There is no automatic retry — disbursement of a fixed-term loan is a one-shot operation.

“Confirm drawdown” — credit line

Who performs it: A user with the Credit Officer role.

When it appears: Each time the borrower initiates a drawdown from the borrower portal on a credit line configured as Manual, the system creates this task. The task title is “Confirm drawdown, Credit line #{number}”. Unlike the fixed-term loan version, this task can repeat any number of times during the life of the credit line — once per drawdown.

What the operator confirms: The “Confirm drawdown” form is short and focused on a single drawdown:

• A read-only credit line info card at the top — credit limit, available credit limit, status, borrower.
• The drawdown amount the borrower asked for (read-only — this comes from the borrower’s drawdown request and cannot be changed by the operator).

What the operator decides:

On submission, the system:

1. Records a successful outbound Disbursement transaction tied to the credit line with the chosen method, document number, the operator’s name, and the timestamp.
2. Adds a Disbursement loan event for this drawdown only (the credit line itself is already Active, and stays Active; no status flip).
3. Rebuilds the credit line snapshot: principal balance increases by the drawdown amount, available credit limit decreases by the same amount, and the current billing cycle’s interest base updates accordingly.
4. Sends a “drawdown disbursed” notification to the borrower.

On failure / no decision: Same 5-day rule as for fixed-term: if the operator does not complete the task within 5 days, it is unassigned, and the drawdown ends with a “Drawdown decision hasn’t been made” outcome. The drawdown attempt is canceled, and the credit line is unaffected — no event, no snapshot change, and the borrower’s available credit limit is not consumed. The borrower can request a new drawdown.

Validations before the task exists: Before the system even creates the “Confirm drawdown” task, the borrower’s drawdown request goes through these checks; if any fail, the task is never created, and the borrower sees an explanatory error:

• Loan must be Active — drawdowns on inactive credit lines are rejected.
• Available credit limit not exceeded — the requested amount must fit within the available credit limit (plus product fees: establishment fee and service fee).
• Drawdown freeze date not reached — once the configured freeze period before maturity starts, no new drawdowns are accepted.
• No active drawdown is already in progress — only one disbursement transaction per credit line can be in progress at a time.

Result of a successful disbursement

The end state varies by loan type:

Fixed-term loan. A Disbursement loan event is created (with date, amount, and attachments). The loan snapshot is updated — the principal balance becomes the disbursed amount, and the interest balance is zero. The loan flips from Pending to Active. The linked application is marked as Disbursed. The amortization schedule that was already calculated at contract signing becomes the live schedule from this point on — the daily interest job and the 03:00 AM scheduled-payment job both start using it. The borrower is notified.

Credit line. A Disbursement loan event is created for this drawdown only. The snapshot is updated — the principal balance grows by the drawdown amount, the available credit limit shrinks by the same amount, and the current open billing cycle now has additional principal to accrue interest on. The credit line stays Active (it was already Active before the drawdown). The borrower is notified.