The problem with the many-small-checks approach to finding data errors (see Part II) is that the process is more complicated than the simple "balance check" report that most operations teams are familiar with. Most teams check custodial balances by running the balance check report, doing some data cleanup, then running the report again to see if the problems were fixed.
When you have twenty interlocking checks and balances, having separate reports for each rule makes it difficult to track down problems. You would make a change that fixed one rule but broke another, and you couldn't see the correlation -- errors would seem to randomly jump between reports. We needed something that could display all the errors for an account in one place that would update in real-time as users made changes to their transactions.
We created a tool window that displays below the current account that the user was working with. This tool window shows any errors that currently exist for the account and it updates as the user makes changes. Seeing how a particular change affects the account makes it easy to detect error patterns and determine whether a certain change fixed a problem.
We display high-level errors on account lists so users can see error patterns that stretch across multiple accounts. We decided to make these high-level errors visible to everybody in the system, not just the operations team. After all, if your data isn't clean, the entire company should be aware so they don't trade or print reports with incorrect results.
If the entire company sees data errors, it is important that the operations team be able to troubleshoot problems before data is posted to the system. So all data errors work in both Pending and Posted modes, allowing you to fix data problems while your trades are still Pending in the trade blotter. (the main lists only show errors with Posted data)
We're very happy with the end result. The feedback we've gotten is that our dynamic error tracking is much easier to work with than static balance check reports in other systems. And they certainly uncover more problems.
(continued in Data Quality IV - CleanData™)