Learn more about automated reporting.
While regulatory reporting for cross-border transactions may appear straightforward, it has hidden complexities and consequences for authorized dealers. This complexity can be simplified with a clear vision that takes your business’s clients and overall processes into account.
The regulator requires all people who transfer to or receive money from overseas to report the reason for this transfer and any other relevant support information. This information needs to be collated and reported, with transactions being evaluated as reportable or not, with the relevant information captured.
However, information capture also includes other information required for the broader payments process and is not restricted to regulatory information only. Therefore, the vision needs to be much broader than just regulatory reporting. An effective vision for reporting addresses pain points for clients and financial institutions and can be summarised in six steps.
1. Evaluation
An automated evaluation of the reportability status of transactions is needed to satisfy the demands of the regulator. In addition, automating transactions allows for better client service and management of high volumes. These automated rules need to have a centralized definition for effective auditing purposes. They must be easily deployed on any online or offline platform and function using the bare minimum of information.
2. Capture
The capture of data takes place over numerous channels. The primary goal is to ensure that comprehensive validation must be done at the point of capture.
In order to make the client capture process as painless and accurate as possible,
clients should only be asked for information that the institution does not already have; clients must understand the information required; the information must be verified against the full set of validation rules before submission; and data capture must be supported both online and offline.
Bulk data uploads also need to be addressed. Many corporates collect regulatory information from their clients and provide this information in a data upload to a banking institution. In this case, the information must be verified against the full set of validation rules before uploading. This improves the quality of of the data collected.
3. Enrichment
Enrichment is simply another channel of capture. As a result the goals associated with capture above are still relevant. Although enrichment is focused on only a small subset of data, a full validation should be done even if just a single piece of data is added.
4. Reconciliation
Reconciliation is an integral part of the reporting process. All transactions must be given a single unique reference at its origin. This is the reference that must be reported. This is in direct contrast to providing a new reference in the reporting system. This reference must reflect both in the accounting entry and in the reporting information so that the two can be tied together. Reporting information should only be reported when its associated accounting entry is available.
5. Report
Reporting should also have support for straight through processing. This means that if the reporting information is valid then it should be reported automatically. Only invalid data must require human intervention. Ideally transaction data should not be changed in the reporting system. If information is amended, there must be an automated process for providing these updates to upstream systems. If already reported information is amended (e.g. upstream system provides the reporting system with an updated version of the transaction) the “cancel” and “add” process must be automated.
6. Validation
This is the most important ability that underpins the entire process.
It is very difficult to reproduce and maintain a common set of validation rules across multiple systems. It is essential that architecture of the validation rules provides a concise and easy-to-understand definition of all the standard regulatory rules; supports additional institutional and channel specific rules on top of the standard regulatory rules; provides lists of countries, currencies, codes etc that are easily configured for a specific channel; and hooks to external validation calls (e.g. IVS, loan references etc.)
The rules must be able to be deployed across all platforms e.g. internet browsers, mobile applications and server-side applications etc. This means that while only a single definition of the rules exists, there must be support for multiple rule engines that can execute the rules across different platforms and programming languages. The rules must be made available to execute in both online and offline deployments.
This implies that it is not good enough to expose a web service to do validation.
Validation must be performed in the client application in order to support immediate feedback during client capture and to process large volumes of transactions in server deployments.
