Reporting

Reporting

Reporting is the separately licensed Reporting Sub-module (tm_reporting) beneath Transaction monitoring. It prepares CTR (Currency Transaction), FTR (Funds Transfer), SAR (Suspicious Activity), and STR (Suspicious Transaction) reports as goAML-compatible XML, entirely from data already retained in your PostgreSQL database. It appears as its own Reporting navigation group for usability, but remains licensed and permissioned as part of Transaction monitoring.

OneView currently prepares, validates, and locally records these reports. It does not submit them to a regulator or FIU, ingest a submission receipt, or synchronise regulator messages. Record the actual submission outcome yourself using Mark accepted / Mark rejected once you have filed the generated XML through your own approved channel. Never represent a locally generated or downloaded XML file as regulator-submitted or accepted inside OneView.

Get started

Open Reporting → Get started. Three things are required before you can create and prepare reports:

1. An active institution profile — the institution identity and goAML institution identifier included in every generated report.
2. An active reporting contact — the officer of record, identified by either their approved identity or a goAML reporting user code.
3. An active goAML schema — the XSD used to validate every generated report XML.

Connecting Redis is shown on the same checklist but is optional: it is only required if you want OneView to generate CTR/FTR drafts automatically in the background. See Redis. Once the three required items are complete, OneView routes you straight to the reports list.

Reports list

Reporting → Reports has two tabs:

• Awaiting review — reports where you are a named approver for the currently pending maker-checker level. This is the default tab when it has anything in it; otherwise All reports opens by default. A count badge shows how many reports are awaiting your review.
• All reports — every report, searchable by internal reference and filterable by report type and status (draft, ready, submitted, accepted, rejected).

reports:read permits viewing both tabs. reports:manage additionally shows New report, for creating a CTR, FTR, SAR, or STR draft under a selected active institution profile and optional reporting contact. You can also start a report from a transaction: open a transaction and select Add to report to attach it to a new or existing draft, provided you have reports:manage and the Reporting entitlement.

CTR and FTR reports also support threshold candidate discovery — a bounded search that surfaces transactions matching each report type's threshold so you do not have to find them manually.

Report detail

Opening a report shows its reference, type, and status, plus a Locked badge once it is no longer editable. Reports are editable while draft, ready, or rejected; they lock once submitted or accepted. Six tabs cover its content:

• Overview — the report's core fields for its type.
• Transactions — attached transactions; add or remove them while the report is unlocked.
• Parties — the report's parties, editable while unlocked.
• Generate & submit — generate goAML XML from the current report snapshot, validate it against the active schema, and download it. Generating and downloading requires reports:export. Every generation is retained in history.
• Reviews — the maker-checker approval chain (when enabled) and the full review history: every approval, rejection, and acceptance recorded on the report, with the reviewer, outcome, any comment or rejection reason, and the date.
• Audit log — the report's own activity history.

Lifecycle

A report moves through draft → ready → submitted → accepted or rejected, using the actions in the report header (gated by reports:manage):

• Ready to submit — moves a draft report to ready once it is complete enough.
• Submit (or Submit for approval when maker-checker is enabled) — moves a ready report to submitted.
• Mark accepted — records an optional FIU reference number and moves a submitted report to accepted.
• Mark rejected — requires a rejection reason and moves a submitted report to rejected.
• Reopen as draft — available from ready or rejected, returns the report to an editable draft and clears any recorded approvals so it can be re-submitted after changes.

Maker-checker approval

An administrator with report_settings:manage can require one or more sequential approval levels before a report can be exported, under Reporting settings → Approval workflow. When enabled:

• Between 1 and 10 approval levels can be configured, each with its own named approvers.
• The user who submits a report can never also approve it.
• Submitting a report (or a decided level completing) opens the next pending level and notifies its named approvers. See Notifications.
• A user with reports:approve who is named on the currently pending level can Approve or Reject it from the report's Reviews tab. Rejecting requires a reason.
• Every configured level must be approved, in order, before the report can be exported.
• If the report is edited after a level was approved, that approval is flagged Stale — report edited since approval because it no longer reflects the current content.

When maker-checker is disabled, reports can be submitted and exported without an approval chain, and the Reviews tab shows only review history (if any).

Reporting settings

report_settings:read permits viewing Reporting settings; report_settings:manage permits editing them. Open Reporting → Settings:

• Institution profiles — the reporting institution identity and goAML identifier. Profiles are archived, not deleted, so historical report snapshots stay meaningful even after a profile changes.
• Reporting contacts — the officer(s) of record who can be attached to a report. Also archived rather than deleted.
• Regulatory code mappings — payment-method, party-role, and report-type code mappings required for valid goAML output.
• Validation schemas — upload, list, and activate goAML XSD versions used to validate generated XML.
• Automatic generation — optional scheduled CTR/FTR drafting; see below.
• Approval workflow — the maker-checker configuration described above.

Automatic CTR/FTR generation

An administrator can enable an independent daily, weekly, or monthly sweep for CTR and FTR reports. Each run examines one full calendar day at a time (never today's incomplete day), and drafts at most one report per matching period — individuals over ₦5,000,000 or corporates over ₦10,000,000 in a single transaction for CTR, and cumulative transactions over $10,000 (or equivalent) for one customer within 24 hours for FTR. Recent generation runs shows every day the sweep has examined, including days with no matching transactions, and flags any failed run.

This requires the shared Redis connection to be configured first (see Redis) because the sweep runs as a background worker. Enabling a schedule is rejected with a clear prompt to configure Redis if it is not yet connected. SAR and STR reports are never generated automatically — their suspicious-activity assessment cannot be reduced to a threshold check, so they remain analyst-created.

Permissions

Every Reporting route also independently checks the tm_reporting licence entitlement server-side. Reporting access does not grant Transaction monitoring access — opening or adding a transaction still requires the corresponding transaction permission and entitlement, and vice versa.

Current limitations

• No direct regulator/FIU submission, submission-receipt ingestion, regulator message sync, amendments, or automated resubmission. Record the actual outcome yourself after filing outside OneView.
• SAR and STR reports are always analyst-created; there is no automatic generation for them.
• There is no attachment or supporting-document upload on a report.
• The automatic-generation worker is not yet part of every generated release topology; confirm with your installation whether it is deployed before relying on scheduled generation in production.