TotalApp Docs

Payments & Clearing Execution

The 4 screens that manage smart payout routing, chargeback and dispute defense, settlement and clearing, and financial escrow.

What this group does

Payments & Clearing Execution is the final group in the Financial Audit & Fintech Ops add-on, covering smart payment routing, chargeback/dispute management, acquirer settlement batches, and contractual escrow. With this group, all 16 operational screens across the add-on are implemented. All 4 screens use the identical direct-per-record two-stage hybrid engine (Stage 1 embedding infrastructure, unwired to the UI; Stage 2 AI-engine-routed synthesis) described on the Overview page.

Payout Routing Rules
Chargeback & Dispute
Settlement & Clearing
Financial Escrow

1. Payout Routing Rules

Purpose: A smart-routing ledger tracking a payment routing rule’s target gateway/rail (Stripe, Adyen, FAST/EFT, SWIFT, etc.), priority tier, fee overhead, and success rate — lets payment teams watch overall gateway approval-rate health and trigger an emergency PSP failover when a rail’s failure rate spikes.

Ledger columns / key fields

  • ID format PRR-YYYY-XXXX
  • ruleId, targetGatewayOrRails, priorityTier, feeOverheadPct, successRatePct, maxSingleTicket, currency
  • routingStatus (active_route / failover_active / disabled), countryCode, lastRunDate, aiRoutingDiagnostic, notes

Gauge

Routing Efficiency Gauge — the average success rate across records that are not disabled only — disabled routes are excluded from the average entirely, not counted as zero. Returns 0 with no records.

Key actions

  • New Record, AI Analyze (runs the payout routing audit, producing a routing diagnostic plus confidence score; disabled while target gateway/rail is blank).
  • Force Gateway Failover Switch / Trigger Failover (row action, inline mini-form: fallback gateway) — updates the target gateway to the new fallback gateway, sets the routing status to failover active, and appends the change (old gateway → new gateway) to the notes — a real, direct update to this record’s own fields.
  • Delete — permanent, with inline confirmation.

Known limitation

Trigger Failover does not redirect real live transaction traffic. There is no payment-gateway orchestration/execution system anywhere in the app today. The action does genuinely update this record’s target-gateway and routing-status fields as the system of record for the failover decision, but no real cutover of live traffic occurs.

2. Chargeback & Dispute

Purpose: A chargeback ledger tracking a card-scheme dispute case (fraud, unrecognized charge, item not received, other) against its disputed amount, defense due date, and resolution status — tracks the portfolio-wide representment win rate and ensures evidence packs are prepared before the defense deadline.

Ledger columns / key fields

  • ID format CBD-YYYY-XXXX
  • disputeId, cardSchemeRef, merchantOrAccount, disputedAmount, currency
  • reasonCode (fraud / unrecognized_charge / item_not_received / other), aiWinProbabilityPct, defenseDueDate
  • disputeStatus (needs_evidence / representment_submitted / won / lost), countryCode, lastRunDate, aiDisputeDiagnostic, notes

Gauge

Portfolio Dispute Win Ratio MeterExcludes unresolved disputes from both numerator and denominator: cases still needing evidence or already submitted for representment are not counted at all. The formula is strictly won cases divided by (won + lost) cases, times 100. Returns 0 if there are no resolved (won+lost) records. This is a deliberate design choice: counting cases that haven’t been decided yet would dilute the true representment performance with cases still in flight.

Key actions

  • New Record, AI Analyze (runs the chargeback/dispute audit, producing a dispute diagnostic plus win-probability score; disabled while card scheme reference or merchant/account is blank).
  • Submit Representment Pack (row action, inline mini-form: evidence summary + document references) — sets the dispute status to representment submitted and logs the evidence summary to the notes.
  • Delete — permanent.

Known limitation

Submit Representment Pack does not transmit any document to a real acquirer or card network. There is no acquirer/gateway integration or document-dispatch system anywhere in the app today. The action does genuinely update the dispute status to representment submitted and log the evidence summary as the system of record, but no real file transmission occurs.

3. Settlement & Clearing

Purpose: A clearing ledger tracking a settlement batch from an acquirer or card network (Stripe, Visa Direct, Mastercard Send, etc.) against gross volume, reserve deductions, and processing fees — tracks the portfolio-wide reconciliation index and enables releasing audit holds for payout.

Ledger columns / key fields

  • ID format SET-YYYY-XXXX
  • Batch ID, acquirer/network, gross volume, reserve deductions, processing fees, currency, clearing cutoff date
  • Settlement status (cleared and paid / fee variance hold / pending clearing), country code, last-run date, AI settlement diagnostic, notes. Net Payout is derived: gross volume minus reserve deductions minus processing fees, shown in red when negative.

Gauge

Settlement Reconciliation Index — Standard status-count pattern: the percentage of records marked cleared and paid out of the total, rounded. Returns 0 with no records.

Key actions

  • New Record, AI Analyze (runs the settlement/clearing audit, producing a settlement diagnostic plus confidence score; disabled while acquirer/network is blank).
  • Release Settlement Hold (row action, inline Yes/No confirmation) — directly updates the settlement status to cleared and paid and appends “Settlement hold released — cleared for payout.” to the notes; disabled once already cleared and paid.
  • Delete — permanent.

Known limitation, with a real-update exception

Release Settlement Hold does not trigger a real bank transfer — there is no funds-disbursement/payout-execution service anywhere in the app today. However, this action is a genuine, direct update to the record’s own settlement-status field, just as with Recalibrate Credit Ceiling and Reallocate HQLA Reserves in the Treasury & Liquidity Operations group — the status field itself is real, only the underlying bank transfer is not implemented.

4. Financial Escrow

Purpose: The final screen in this group and in the add-on. An escrow ledger tracking funds held in trust for a buyer/beneficiary against a contractual release condition or milestone — tracks the portfolio-wide trust capital reserve and enables executing escrow payouts once conditions are verified.

Ledger columns / key fields

  • ID format ESC-YYYY-XXXX
  • Escrow ID, buyer/beneficiary, contract reference, locked reserve amount, currency, release condition, expiry date
  • Escrow status (locked in trust / milestone verified / disputed hold / released), country code, last-run date, AI escrow verification, notes

Gauge

Trust Capital Reserve BarCapital-weighted, explicitly not a record-count ratio: the sum of the locked reserve amount across records that are still locked (not yet released), divided by the sum of the locked reserve amount across all records, times 100. Returns 0 with no records or zero total locked amount.

Why capital-weighted?

Escrow accounts vary enormously in size, so a naive record-count ratio would mislead. Concrete example from the QA source: a portfolio with one $1.8M released escrow and one $200K escrow still locked in trust is 2 records — a naive count-based ratio would read as 50% still locked. The real, capital-weighted formula instead yields 10% ($200K / $2.0M total), correctly reflecting that the large majority of capital has already been released — weighted by the dollar amount still held in escrow, not by how many accounts are still locked, so one large still-locked account matters more than several small released ones.

Key actions

  • New Record, Run Verification / AI Doğrulama (runs the financial escrow audit, producing an escrow verification plus confidence score; disabled while buyer/beneficiary or contract reference is blank).
  • Execute Escrow Payout (row action, inline mini-form: authorizing signature) — directly updates the escrow status to released and logs the authorizing signature reference to the notes; disabled once already released.
  • Delete — permanent.

Known limitation, with a real-update exception

Execute Escrow Payout does not move real money out of a trust account — there is no trust-account/banking-rail funds-release system anywhere in the app today (same category of gap as Release Settlement Hold, Execute Liquidity Sweep, and Auto-Generate FX Hedge Order in their respective domains). As with Release Settlement Hold, this action is a genuine, direct update to the record’s own escrow-status field — only the underlying fund transfer is not implemented.

Gauge diversity across this group

This group intentionally uses four different gauge formulas, none of which share the other’s pattern: Routing Efficiency is a plain average (excluding disabled records); Dispute Win Ratio excludes unresolved cases from both numerator and denominator; Settlement Reconciliation Index is the add-on’s standard status-count ratio; Trust Capital Reserve is capital-weighted. This mirrors a broader lesson across the whole add-on — Transaction Audit gauges are mostly status-count, the Treasury group’s LCR gauge is intentionally unclamped above 100%, and its Concentration Meter is weighted toward the single largest position. No gauge in this add-on can be assumed to follow a “default” pattern — always check what each gauge actually measures.

Frequently Asked Questions

Does adding an unresolved dispute change the Win Ratio?
No — disputes still needing evidence or already submitted for representment are excluded from both the numerator and denominator. Only won and lost records count.
Is the Trust Capital Reserve Bar based on the number of escrow records?
No — it is weighted by dollar amount. A large released escrow and a small still-locked escrow can produce a low percentage even though the record count looks 50/50, because the formula sums locked amounts, not record counts.
Does Trigger Failover actually redirect live payment traffic?
No — there is no payment-gateway orchestration system in the app today. It does genuinely update this record’s target gateway and status fields, but no real traffic cutover happens.
Do Release Settlement Hold and Execute Escrow Payout actually move money?
No — neither triggers a real bank transfer or trust-account fund movement, since no funds-disbursement service exists in the app today. Both do, however, genuinely update their own record’s status field, which is the honest, real part of the action.
Why does Routing Efficiency exclude disabled routes instead of counting them as 0%?
Because a disabled route isn’t contributing a meaningful success rate at all — including it as 0% would understate the real efficiency of the routes actually in use. It averages only active and failover-active records.