Audit Rules & Compliance Setup
The 4 screens that hold jurisdiction-specific audit rules, AML/sanctions configuration, chart-of-accounts compliance, and regulatory reporting cadence.
What this group does
Audit Rules & Compliance Setup is the regulatory foundation layer of the Financial Audit & Fintech Ops add-on. It is architecturally the older of the add-on's two generations of screens: instead of the direct-per-record AI analysis used by the 12 newer screens across Transaction Audit & Reconciliation, Treasury & Liquidity Operations, and Payments & Clearing Execution, these 4 screens automatically adapt their generated rule sets and schemas to the selected legal jurisdiction (Turkey / US / Default). Every other sub-group in the add-on ultimately operates against the categories and rule definitions established here.
1. Audit Rules Registry
Purpose: The master ledger of jurisdiction-specific audit rule definitions — the base rule set that every downstream audit and compliance screen in the add-on ultimately checks against.
Ledger columns / key fields
- Rule code, rule category (one of the 4 jurisdiction-schema categories:
audit_rules,aml_sanctions,chart_of_accounts,regulatory_reporting) - Jurisdiction (TÜRKPATENT-style country/regulator code — TR / US / Default jurisdiction strategy)
- Severity level (the weight a violation of this rule carries in downstream audits)
- Active / inactive status
Key actions
- Create/edit a rule definition; toggle active/inactive as regulatory requirements change
- AI-assisted rule/schema generation, automatically adapted to the record’s jurisdiction (TR / US / Default)
2. AML & Sanctions Config
Purpose: Anti-money-laundering and sanctions screening rule configuration — defines which watchlists are screened against, at what monetary threshold, and how often.
Ledger columns / key fields
- Watchlist source (the sanctions/AML list a transaction or counterparty is screened against)
- Threshold amount (the monetary trigger above which screening applies)
- Screening frequency (how often the configured check re-runs)
- Jurisdiction (TR / US / Default strategy, same as Audit Rules Registry)
Key actions
- Create/edit an AML/sanctions screening rule; adjust threshold amounts and screening cadence
- AI-assisted schema generation follows the same jurisdiction-based adaptation as Audit Rules Registry
3. Chart of Accounts Audit
Purpose: Audits the chart of accounts structure itself for compliance and completeness issues — missing account categories, malformed account codes, jurisdiction-required accounts that are absent. This is distinct from Ledger Variance Audit in the Transaction Audit & Reconciliation group, which compares an expected balance (trial balance) against an actual ledger balance on one specific line; Chart of Accounts Audit instead evaluates whether the account structure conforms to what the jurisdiction requires.
Ledger columns / key fields
- Account structure findings (missing/malformed categories or codes)
- Jurisdiction-required account checklist status
- Jurisdiction (TR / US / Default strategy)
Key actions
- Run/review a structural compliance audit of the chart of accounts
- AI-assisted schema generation to propose jurisdiction-conformant account structure fixes
4. Regulatory Reporting Setup
Purpose: Configures which regulatory reports must be filed, on what cadence, and per which jurisdiction — the filing calendar that downstream compliance tracking depends on.
Ledger columns / key fields
- Report type / regulatory filing name
- Filing cadence (frequency at which the report must be submitted)
- Jurisdiction (TR / US / Default strategy)
Key actions
- Create/edit a regulatory filing requirement; adjust cadence per jurisdiction
- AI-assisted schema generation for jurisdiction-specific filing requirements
Architectural note: jurisdiction-adaptive generation vs. the newer generation
All 4 screens in this group share one distinguishing trait that sets them apart from the other 12 screens in the add-on: their AI-assisted schema/rule generation automatically adapts to the selected jurisdiction. It produces one of three jurisdiction-specific outputs — TR, US, or Default — each shaped for that jurisdiction’s regulatory conventions.
This contrasts with the direct-per-record analysis used by the 12 newer-generation screens (Transaction Audit & Reconciliation, Treasury & Liquidity Operations, Payments & Clearing Execution), where each screen runs its own dedicated audit against a single record, routed purely by the user’s selected AI engine rather than by jurisdiction. Both generations share the same AI-engine-based routing for the second AI-synthesis stage (Ollama/local-LLM/web-LLM stay client-side; local-CLI/API go to the server, and every call is logged) — the difference is specifically in how the AI-assisted generation itself is structured: jurisdiction-adaptive here, versus record-level analysis elsewhere.
Being the older generation
Because this group predates the 12 newer screens, its per-screen detail is necessarily lighter than the QA-verified depth available for Transaction Audit & Reconciliation, Treasury & Liquidity Operations, and Payments & Clearing Execution — there is no equivalent manual-test QA document for this group at this time. The architectural facts above (categories, jurisdiction strategies, Strategy Pattern contrast) are verified; granular details such as gauge formulas or exact button i18n keys for these 4 screens are intentionally not stated here to avoid inventing unverified numbers.
Pages in this section
Frequently Asked Questions
audit_rules, aml_sanctions, chart_of_accounts, and regulatory_reporting — each screen in this group corresponds to one category.