Financial Audit & Fintech Ops — Overview
What the add-on is, its 4 sub-groups, who uses it, and the two-stage hybrid AI engine pattern used across the module.
Module Overview
The Financial Audit & Fintech Ops add-on is a wired, purchasable package gated by a tenant entitlement and per-user FinAudit roles. It covers the full internal-audit and fintech-operations lifecycle for a finance-heavy organisation: configuring jurisdiction-aware audit rules and AML/sanctions screening, reconciling transactions across bank/gateway/POS/ERP channels and flagging fraud, monitoring treasury liquidity, FX exposure and credit risk, and executing payments clearing, chargeback resolution and escrow lifecycles.
At a glance
- Domain: FINAUDIT
- URL prefix:
/finaudit/… - Governance screens: Roles, Audit & Fintech Ops Team (staff)
- 16 operational screens across 4 sub-groups (see below)
- Default roles: Chief Audit & Fintech Ops Manager, Internal Auditor, Compliance & AML Officer, Treasury Analyst, Payments Operations Specialist
The 4 sub-groups
The add-on’s 16 operational screens are organised into four titled sub-groups, on top of the standard Administration & Access group (Roles, Staff).
| Group | Screens |
|---|---|
| Audit Rules & Compliance Setup | Audit Rules Registry, AML & Sanctions Config, Chart of Accounts Audit, Regulatory Reporting Setup |
| Transaction Audit & Reconciliation | Invoice Matching Audit, Multi-Source Audit & Reconciliation (Bank Reconciliation), Fraud Detection & Anomaly Audit, Ledger Variance Audit |
| Treasury & Liquidity Operations | Cash Flow Forecast, FX Exposure & Risk, Credit Risk & Limits, Liquidity Buffer |
| Payments & Clearing Execution | Payout Routing Rules, Chargeback & Dispute, Settlement & Clearing, Financial Escrow |
See Audit Rules & Compliance Setup, Transaction Audit & Reconciliation, Treasury & Liquidity Operations and Payments & Clearing Execution for the per-screen breakdown of each group.
Who uses it
Financial Audit & Fintech Ops targets internal auditors, compliance & AML officers, treasury analysts and payments operations specialists — the people who decide audit findings, compliance posture, treasury risk exposure, and payment operations health. A tenant activates the finaudit package, then assigns each team member one of the five default roles (or a custom role built from the same capability catalog) as a domain “hat” — see Roles & Capabilities.
Key concepts
Jurisdiction-aware audit rules
Audit Rules Registry, AML & Sanctions Config, Chart of Accounts Audit and Regulatory Reporting Setup automatically adapt their form fields and audit logic to the selected jurisdiction (Turkey/US/Default) — the same category of audit produces a different set of fields and checks depending on which jurisdiction is selected.
AML & sanctions screening
AML & Sanctions Config is the compliance layer that governs what counts as a sanctionable counterparty or suspicious pattern before any transaction-level audit runs against it.
Multi-source reconciliation
Invoice Matching, Bank Reconciliation, Fraud/Anomaly Detection and Ledger Variance Audit all reconcile records across independent channels — bank, payment gateway, POS, ERP internal — each with its own dedicated AI analysis.
Treasury risk trio
Cash Flow Forecast, FX Exposure & Risk and Credit Risk & Limits monitor forward-looking liquidity, currency and counterparty risk; Liquidity Buffer tracks the Basel III–style capital cushion behind them.
Payments clearing trio
Payout Routing Rules, Chargeback & Dispute and Settlement & Clearing run the operational side of moving money; Financial Escrow holds funds against a release condition or milestone.
Two screen generations
The 4 Audit Rules & Compliance Setup screens automatically adapt their fields to the selected jurisdiction; the other 12 screens run a dedicated AI analysis per record type — both go through the same AI-engine-aware second stage (see below).
The two-stage hybrid engine
Every screen in this add-on that does AI work follows the same two-stage pattern, and it’s worth understanding once rather than per-screen:
| Stage | What it does | Where it runs |
|---|---|---|
| Stage 1 — Embedding Engine | 11 semantic-search helpers — one per record type (ledger entries, transactions, invoices, treasury records, FX hedges, counterparties, regulatory documents, routing rules, dispute evidence, settlement batches, escrow accounts) — all built on the same shared Finding Similar Records logic used across the app. It never throws an error; if it can’t complete a search it degrades gracefully and simply returns no matches. | Always the user’s own local Ollama instance — this stage never proxies through the TotalApp server. |
| Stage 2 — AI Synthesis Layer | The older 4 screens (Audit Rules & Compliance Setup) automatically adapt their fields and logic to the selected jurisdiction (Turkey/US/Default). The newer 12 screens each run their own dedicated AI analysis (bank reconciliation, fraud/anomaly detection, invoice matching, ledger variance, cash flow forecast, FX exposure, credit risk, liquidity buffer, payout routing, chargeback/dispute, settlement/clearing, financial escrow), all following the identical AI-engine-routing pattern. | Routes through whichever engine the user picked in Settings → Agentic — Ollama/local-LLM/web-LLM run entirely in the browser and never touch the server; local-CLI/API route to the server, which calls the Anthropic or Cohere API depending on the selected mode. |
Embedding search is not wired into the UI yet
Unlike Patent & R&D Operations and Customs & Global Trade Operations, where Finding Similar Records is a mandatory first UI step (e.g. a “Find Similar Patents” or “Search Similar Rules” button), the 11 FinAudit semantic-search helpers exist purely as background infrastructure today — none of the 16 screens use them yet. Users go directly from filling the form to clicking “AI Analyze” (Stage 2); there is no “find similar records first” step anywhere in this add-on. This is infrastructure ready for a future UX, not a flaw — the underlying search logic is tested and working, just not yet surfaced on any screen.
Every server call is logged (duration, model name, success/fail, screen name) — visible in Settings → Analytics. When Ollama/local-LLM/web-LLM is selected, Stage 2 runs entirely in the browser and never hits the server at all — the Render server has no network path to a user’s local Ollama.
Pages in this section
Frequently Asked Questions
finaudit package activated, and your user must hold a FINAUDIT domain role. See Roles & Capabilities.finaudit-ops/ module folder on the server — one JSON file per screen (e.g. finaudit-audit-rules.json, finaudit-bank-reconciliations.json), plus roles/roles.json for role definitions. Curated seed copies live in server/seed/tenants/default/finaudit-ops/ for the admin Seed Data Transfer tool.recalibrateCreditLimit (Credit Risk) and reallocateLiquidityBuffer (Liquidity Buffer) directly update their own record field and are not placeholders. See Screen Workflows.