Financial Audit & Fintech Ops — Screen Workflows
Three end-to-end screen workflows showing the Stage 1→Stage 2→action-button→record-update pattern concretely.
Screen Workflows
Every screen in this add-on follows the same shape: fill a form, run AI Analyze (Stage 2 — see Overview for why Stage 1 embedding search isn’t wired into the UI yet), save the record, then optionally take a row-level action that updates the record further. This page walks through three representative screens in full to make that pattern concrete, then notes how it generalises to all 16.
1. Bank Reconciliation (Multi-Source Audit & Reconciliation)
The user creates a new record with Statement Reference, Channel (bank / payment_gateway / pos / erp_internal), Statement Balance and Internal Book Balance. Clicking AI Analyze runs the bank reconciliation audit, which produces a variance breakdown and an optional suggested adjustment. The user saves the record.
The row action Adjust (wrench icon) opens an inline mini-form pre-filled with the variance amount. Submitting it appends a note and flips the record’s status to matched if the adjustment closes the gap within a 0.01 tolerance.
Not a real GL posting
Adjusting a variance does not post to any real general ledger — no such system exists in the app today. It only updates this record’s own status and notes fields.
The screen’s gauge is the Reconciliation Match Ratio Gauge: ≥80 green, ≥40 amber, below that red — a simple status-count ratio of matched records over total.
2. Fraud Detection & Anomaly Audit
The user creates a record with Account/Asset Reference, Anomaly Type (velocity_spike / structuring / geo_ip_mismatch), Risk Score (0–100) and Risk Level (critical / high / medium). Clicking AI Analyze runs the fraud/anomaly detection audit, producing a pattern analysis and an optional confidence score. The user saves the record.
The row action Freeze Account (lock icon) opens an inline mini-form asking for a reason. Submitting it sets the audit action to frozen and appends “Frozen: …” to the record’s notes.
Not a real account freeze
This does not lock any real account or notify any real security team — no such downstream system exists in the app today. It only updates this record’s own audit-action field and notes.
The screen’s gauge is the Portfolio Anomaly Severity Meter, which uses inverted logic (high = bad): critical+high risk record count over total — ≥60 red, ≥30 amber, below that green.
3. Financial Escrow
The user creates a record with Buyer/Beneficiary, Contract Ref, Locked Reserve Amount and Release Condition/Milestone. Clicking Run Verification runs the financial escrow audit, producing an escrow verification and an optional confidence score. The user saves the record.
The row action Execute Escrow Payout (shield icon) opens an inline mini-form asking for an Authorizing Signature. Submitting it directly updates the escrow status to released — a genuine update to the record’s own field — and appends the signature reference to notes. Once released, the button becomes disabled.
Real status update, not a real money movement
Unlike the bank-variance and account-freeze examples above, this action does genuinely update the record’s own escrow-status field — it is not a no-op placeholder. It does not, however, move any real money out of a trust account; no such funds-release system exists in the app today.
The screen’s gauge is the Trust Capital Reserve Bar, which is capital-weighted, not record-count-weighted: the sum of the locked reserve amount for still-locked (non-released) records, divided by the sum of the locked reserve amount for all records. For example, one $1.8M released escrow plus one $200K still-locked escrow yields 10% (200K / 2.0M), not 50% — because it weights by dollar amount, not by record count.
Writer engine routing applies to all 16 screens identically
The routing table below (identical to the one in Overview) applies to every one of the 3 examples above and all other 13 screens without exception:
| Selected AI engine | Where Stage 2 runs |
|---|---|
ollama / local-llm / web-llm | Runs entirely from the browser — never touches the server. |
local-cli | Routes to the server, which runs the Claude CLI. |
api | Routes to the server, which calls the Anthropic API, or the Cohere API if Cohere mode is selected. |
Every server call is logged, visible in Settings → Analytics.
Recalibrate/Reallocate — the exception to the placeholder pattern
Most row-level actions across this add-on (adjust variance, freeze account, trigger sweep, create FX hedge order, trigger routing failover, submit dispute evidence) only update the acting screen’s own record with no real downstream integration. Two functions are the explicit exception, because they own their target field directly rather than merely logging intent:
- Credit Risk & Limits — Recalibrate Credit Ceiling directly updates the record’s approved-ceiling field.
- Liquidity Buffer — Reallocate HQLA Reserves directly updates the record’s reserve-tier field.
Financial Escrow’s Execute Escrow Payout and Settlement & Clearing’s Release Settlement Hold are a related, softer case: they genuinely update the record’s own status field, just without moving any real funds.