Documentação

English

Português
Español

English

Português
Español

Appearance

Disbursements ​

Access Prerequisites

  • Permission (module): creditDisburse (execute/operate disbursements).
  • License/Feature: CREDIT_INVESTMENTS enabled on the tenant license (Vault).
  • Menu container: TOKENIZATION → group Tokenized Credit

What it is / when to use ​

The Disbursements screen tracks the transfer of the net amount of a Deal to the originator (cedent) — the moment when the anticipation effectively "pays" the client. The disbursement is executed against the originator's BaaS account (generating a baasTransferId) or, in the tokenized modality, via a token transfer.

Use this screen to monitor the state of disbursements (pending, processing, completed, failed), check the amount transferred per deal, and trace the corresponding BaaS transfer.

Pre-conditions ​

  • Permission: creditDisburse (dual permission — CPM enum + dynamic module in the DB).
  • License/Feature: CREDIT_INVESTMENTS enabled. Without it the group does not appear in the menu at all.
  • Dependencies on other screens: the Deal must be approved/funded; the originator (Parties) must have an active BaaS account and a compatible status (APPROVED).

Step by step ​

  1. Go to the menu Tokenized Credit → Disbursements.
  2. Filter by Status.
  3. Monitor each row: deal, amount, status, BaaS transfer ID, and date.
  4. The execution of the disbursement is triggered by the deal flow (executeDisbursement / disbursementViaToken); this screen is for monitoring.

Filters and columns ​

Filter/ColumnWhat it showsData source
DealOperation whose net amount was transferreddisbursement.dealId
AmountAmount disbursed to the originatordisbursement.amount (BigNumber)
StatusPENDING, PROCESSING, COMPLETED, FAILED (and backend equivalents)disbursement.status (filter statusFilter)
BaaS Transfer IDBanking transfer identifier at the providerdisbursement.baasTransferId
Created atDisbursement datedisbursement.createdAt

Actions and modals ​

This screen is primarily for monitoring. Execution happens in the service flows:

  • Fiat disbursement (BaaS): executeDisbursement({ dealId, amount, idempotencyKey }) — transfers the net amount to the originator's BaaS account and records baasTransferId.
  • Token disbursement: disbursementViaToken({ dealId, originatorUserId, tokenId, amount }) — transfer represented as a token transfer (walletTransaction).

Disbursement execution is a sensitive financial action and may require step-up (password + MFA, X-Step-Up-Token, 5-minute window) depending on the environment.

Business rules / considerations ​

Attention

  • Originator must be eligible. The transfer requires the originating Party to have an active BaaS account and approved status; without this the disbursement fails (FAILED).
  • baasTransferId is the reconciliation anchor. Use it to match the disbursement against the BaaS provider statement.
  • Net amount, not gross. What is disbursed is the deal's netDisbursement (gross − discount − fees), not the face value of the receivables.

Irreversible

  • An executed disbursement has no rollback. Once the BaaS/token transfer goes out, the money is with the originator; corrections require a new financial event (reversal/buyback).
  • Financial values: amount is BigNumber in the backend; do not round when checking the transfer.
  • Idempotency: the disbursement accepts idempotencyKey and goes through FinLib — idempotent by externalId. On reprocessing, E00021 ("already processed") is success (already disbursed), not a failure. See [[reference_finlib_idempotency]].
  • APPROVED status: the target originator must be approved to receive the transfer.

Examples ​

Scenario 1 — Completed fiat disbursement
  1. Deal approved and funded; originator with active BaaS account.
  2. The flow executes executeDisbursement with the netDisbursement.
  3. The row appears as COMPLETED with baasTransferId filled — reconcile with the provider's statement.
Scenario 2 — Safe reprocessing after a crash
  1. The process crashed right after the transfer went out, but before confirming.
  2. The reprocessing uses the same idempotencyKey; FinLib responds with E00021.
  3. Treat it as success — there is no double disbursement.