A report is a query, not a project
Reporting built after the platform becomes a second system with its own version of the truth. Built from the ledger, it is a view of the one you already have.
Regulatory reporting is often the last thing a new financial platform builds. The product launches, the obligations arrive on schedule, and a team is asked to produce the reports from whatever data is to hand. What they usually build is a second system: extracts, transformations and a spreadsheet that someone reconciles by hand before every submission.
That second system is where reporting risk lives. It can disagree with the platform, and when it does, nobody can say quickly which one is right.
One source of truth
A report is a set of figures about money that moved. The ledger already holds a complete, immutable record of that movement. Build the report as a query over the ledger's entries and it cannot disagree with the balances, because both are derived from the same facts.
It also makes reports repeatable. Run the same query over the same period and the same figures come back, which is exactly what an auditor will try to do.
Monitor what actually moved
Transaction monitoring built on application logs, or on a copy of the data, sees what the application believed happened. Monitoring built on ledger events sees what did happen. The difference matters most in the cases monitoring exists for: the unusual flows, the partial failures, the corrections.
Screening does not stop at onboarding
Screening at onboarding is necessary and not sufficient. Lists change, customers change, and a counterparty that was clean last month may not be today. Screening belongs at onboarding, on every material change and whenever the lists themselves are updated.
Every result should be kept, including every clear one. Being able to show that a check was run and passed is part of the obligation.
Obligations change, so version them
Rules, thresholds and report definitions are not settings to be edited in place. They are part of the system's behaviour, and they change when the regulator's guidance does. Keep them in version control, review them like code and date them, so that any past report can be explained by the rules that applied on the day it was produced.
Rehearse the audit
The simplest test of a reporting system is to pick a figure from a submitted report and trace it back to the transactions behind it. If that takes a query, the system is sound. If it takes a week and three people, the report is a project, and it will be one every time it is due.
Leave with the approach, the risks and what it would take
Ninety minutes with the engineers who would do the work, on one problem you name: a processor replacement, an onboarding flow, a ledger reconciliation.