Deals / Credit Operations

Access Prerequisites

• Permission (module): viewCredits (access to the listing). Approve/reject requires creditDealApprove / creditDealReject; cancelling uses creditDealReject.
• License/Feature: CREDIT_INVESTMENTS enabled on the tenant license (Vault).
• Menu container: TOKENIZATION → group Tokenized Credit

What it is / when to use

The Deals screen is the heart of the credit operation: each deal is a receivables anticipation/assignment operation that brings together an originator (cedent), one or more receivables, an investor (or pool of investors in fractional mode), a pricing template, and a settlement waterfall. This is where the operator monitors the lifecycle of the operation — from draft to settled — and carries out approval, rejection, and cancellation decisions.

Use this screen daily to approve operations that have passed risk assessment, reject those that should not proceed, and cancel operations already in progress (with a recorded reason). Typical creation is done by the originator in the Midas-Web; the BackOffice provides a Create button for manual cases.

Pre-conditions

• Permission: viewCredits to see the list; creditDealApprove/creditDealReject for actions (dual permission — static CPM enum on the backend + dynamic module in the DB that controls the *ngIf/*appHasPermission on the buttons; both must be active).
• License/Feature: CREDIT_INVESTMENTS enabled. Without it, the Tokenized Credit group does not appear in the menu at all.
• Dependencies on other screens: the originator and investor must exist as approved Parties; Receivables must be registered/approved; ideally Pricing Templates, Waterfall, and Funding Sources already exist.

Step by step

1. Go to the menu Tokenized Credit → Deals.
2. Use the search to locate by deal number/originator/investor.
3. Click a row (or the ⋮ → View menu) to open the deal details.
4. For operations in PENDING status, use ⋮ → Approve or ⋮ → Reject.
5. For operations already in progress (not DRAFT/CANCELLED/SETTLED), use ⋮ → Cancel and fill in the reason/cancellation type in the dialog.

Filters and columns

Column	What it shows	Data source
Deal Number	Identifier code of the operation (dealNumber)	Deal.dealNumber
Originator	Operation cedent (ID/name, truncated to 8 chars in the list)	Deal.originatorId (resolved to name when available)
Investor	Lead investor; — if still in fractional fundraising	Deal.investorId
Status	Lifecycle stage: DRAFT, PENDING, APPROVED, FUNDED, DISBURSED, PARTIALLY_SETTLED, SETTLED, CANCELLED, FULLY_FUNDED, OPEN_FOR_INVESTMENT	Deal.status
Gross Amount	Face value of the receivables	Deal.grossAmount (BigNumber in the backend)
Net Amount	Net disbursement to the originator (gross − discount − fees)	Deal.netDisbursement
Tokenization	Whether the operation was tokenized and how many units issued	Deal.tokenizationStatus / tokenizedUnits
Created at	Creation date/time	Deal.createdAt

The search filters the list; there is no status dropdown in this screen — use the search and the Status column for triage.

Actions and modals

• View: opens the complete deal details (credit-deals/view/:id), including receivables, pricing, contract, tokenization, and related tabs.
• Edit: available only in DRAFT (credit-deals/edit/:id). Already-submitted operations are not editable from the list.
• Approve: runs approveDeal(id) after confirmation (bottom-sheet). Moves the deal from PENDING to APPROVED, triggering the evaluation of Policies scoped to DEAL. Only visible with creditDealApprove.
• Reject: runs rejectDeal(id) after confirmation. Ends the operation as rejected. Only visible with creditDealReject.
• Cancel: opens the cancellation dialog (reason + cancellation type), then confirms via bottom-sheet and calls cancelDeal(id, userId, reason, type). The logged-in operator's userId is recorded as responsible. Available for any status except DRAFT, CANCELLED, and SETTLED.

As these are sensitive financial decisions, approve/reject/cancel may trigger step-up (password + MFA re-authentication, X-Step-Up-Token header, 5-minute window) depending on the environment configuration. Step-up is not 4-eyes approval — it only reconfirms the operator's identity.

Business rules / considerations

Attention

• Approval triggers risk assessment. Upon approval, DEAL-scope Policies are evaluated; a policy with a REJECT action that fails can block the operation or force a review.
• Edit only in DRAFT. Once submitted, the operation cannot be edited from the list — fix it via cancellation + new operation if necessary.
• Cancellation requires reason and type. The dialog forces cancellationReason and cancellationType to be filled; this feeds the eventual refund flow (refundAmount/refundStatus).
• Fractional mode. In deals with targetAmount/raisedAmount, the investor may be empty until fundraising closes (FULLY_FUNDED); the Investor column shows — during that period.

Irreversible

• Approval triggers the downstream financial flow (funding → disbursement → tokenization). There is no "unapprove"; reverting requires cancellation with a refund, which is a new audited financial event.

• Financial values: grossAmount, netDisbursement, discountAmount, feesAmount are handled as BigNumber in the backend — the docs and UI display them formatted, but never round when reconciling; verify the decimal places of the tenant's currency.
• APPROVED status of participants: disbursement to the originator requires a Party with approved status; see Parties.

Examples

Scenario 1 — Approve a simple single-investor operation

1. The originator created the deal in the Midas-Web; it arrives as PENDING.
2. The operator locates it via search, opens View, reviews receivables and pricing.
3. ⋮ → Approve → confirms. DEAL Policies run; if they pass, the deal goes to APPROVED and proceeds to funding/disbursement.

Scenario 2 — Cancel an already-disbursed operation

1. Deal is in DISBURSED; fraud in the receivable has been discovered.
2. ⋮ → Cancel → fill in reason "invalid receivable" and cancellation type.
3. Confirm; the system records cancelledBy (operator), cancellationReason/cancellationType and prepares a refund (refundStatus). Consider also opening a Buyback.

Scenario 3 — Fractional deal during fundraising

1. Deal is in OPEN_FOR_INVESTMENT with targetAmount set; Investor column shows —.
2. As investors contribute, raisedAmount grows; when the target is reached, the status becomes FULLY_FUNDED.
3. Only then is the disbursement flow unlocked.

Related screens

• Parties (drawee/cedent/investor)
• Receivables
• Disbursements
• Settlements
• Buybacks
• Credit Tokenization
• Tokenized Credit (group index)