In our last article Identify the “Best-Fit” CRS Solution – Outsource, Build or Buy?, we discussed “Best-Fit” and in a follow we wanted to discuss Data Management. Despite the substantial investment made by banks in data management, the requirement for a platform to carry out manual workarounds to the CRS Input data for impairing the risks of inaccurate reporting continues to persist.
It’s an obvious truth that many people overlook: master data is not as good as one would like it to be.
For CRS and FATCA reporting, especially, high data quality is required to generate accurate and complete reports to tax authorities. Financial institutions must look out for multiple data repositories of the account holders such as deposit-taking, wealth management and custody footprints for detailed information that is required to fulfil the reporting obligations.
Financial institutions can find themselves on a downhill slide if they don’t have effective data quality procedures in place to keep up with their reporting and refiling obligations while also monitoring constant multi-jurisdictional FATCA/CRS reporting changes.
Financial institutions now have clear and concise requirements for recording customer information. Some requirements are imposed by law, while others are the result of internal processes. In the past, there were fewer provisions and forms, which led to problems now with the master data’s accuracy.
Data gaps that arise in this manner are usually not addressed until the next customer meeting, which is usually a long time away. Filling the data gaps that frequently remain can be time-consuming and expensive in practice. Our CRS Stride software detects these gaps in real-time and alerts financial institutions so they can be closed within the application.
Data gaps begin from the Core System
Whether a specific attribute is recorded for a customer may be irrelevant to the core system of a financial institution. However, it may still be a key barrier if this information is needed later in the process.
Because different downstream systems demand various information, the list of mandatory core system attributes grows very long, even if they aren’t completely essential in the core system.
So, it all starts in the core system, where either there isn’t a field for certain information where the customer data is initially entered, or it wasn’t previously required to fill in these fields.
In 2015, for example, there were no requirements for TIN verification or validation checks in the CRS. Implementation of the US Internal Revenue Service TIN matching codes and the shift to CRS Schema 2.0 for XML filing are two recent significant changes that have affected data management and quality. Both changes necessitate financial institutions to achieve higher levels of granular data accuracy, necessitating data refiling.
Mandatory fields slow down the Customer Onboarding Process
Mandatory fields are a double-edged sword because, on the one hand, the customer should be completely documented, but on the other hand, the customer creation process must be quick and should not be slowed down by details that can be added later – provided, of course, that these later additions are made. And only if there is a suitable field for this purpose. Whatever the reason, there are frequently gaps in the data that can be time-consuming and costly to fill.
Data Inaccuracy & Data Gaps lead to Resubmission
Resubmission is one of the four major challenges associated with FATCA/CRS reporting, together with data challenges, rules, jurisdictional nuances, and 3rd party reporting. HMRC reach out to the financial institutions to resubmit the data if the institutions fail to submit data that is complete, accurate, valid, timely, and consistent. This process, which is often done manually, can be very long and tedious, as well as posing a compliance risk.
The need for resubmission is primarily spurred by poor data quality. Depending on whether (a) the resubmission is voluntary or non-voluntary, (b) the resubmission is under a tight deadline, and (c) the FATCA/CRS reporting solution is automated, organisations face significant pressure.
There are two possible scenarios when it comes to resubmission:
- The organisation is aware that a recent submission has a data quality issue.
- Regulators find a flaw in the initial submission and require a resubmission within an arbitrary timeline, which can range from two weeks to two months.
The approach used for refiling, whether it is voluntary or non-voluntary, must be carefully thought out to effectively tackle the many complex situations that arise.
During this resubmission process, financial institutions should handle complex situations more carefully as data quality issues may result in revisiting their operational approach. Gap analysis has to be done to identify the loopholes and a stringent data governance framework should be inducted to ensure the quality of data. CRS Schema 2.0 was imposed to overcome all these complex resubmission processes.
What should the financial institutions do for resubmission?
- Void submission: Cancel the original XML, make the necessary changes, and resubmit with a new XML.
- Account-level resubmission: Based on corrected data, all account-related details, including Controlling Person for CRS and Substantial Owner for FATCA details (if any), are re-classified. Following that, an updated XML is generated automatically.
- DocRefID resubmission: Regulators specify which DocRefID to correct, and users have the option of only correcting the affected DocRefID and leaving the rest of the XML file alone.
Whether the financial institutions resubmitting the CRS/FATCA reporting on their own or it is mandated by HMRC to rectify and resubmit within specific timelines, there should be a trustable, automated and seamless process should be in place to refine the specific data to reply to the HMRC quickly.
Most financial institutions are scrambling their heads to meet tight deadlines as the data cleansing process is a tiresome task if it is done manually.
Financial intuitions should shift to an automated CRS/FATCA reporting solution which takes care of all the reporting obligations seamlessly so that they can keep their focus on growing their business rather than running behind the compliance burdens.
Core Banking System is the golden source of reference data for CRS reporting but before accommodating the CRS input file it requires exhaustive refinements to comply with the HMRC standards. The maladaptation to the system scalability makes the banks lookout for new solutions.
What if the CRS application enables you to amend reportable data?
Having data management as an integrated feature within the CRS application will eradicate performing multiple iterations in amending the CRS reportable data.
Macro Global’s “CRS Stride – AEOI / HMRC CRS & FATCA Reporting Solution” facilitates amending the CRS data at the customer level within the application, enabling the banks to achieve the desired input data quality before considering it for CRS XML file generation.
Upon achieving the desired standards, CRS Stride generates an extensive audit trail with 90+ validations based on predefined rulesets to track and manage the deviations within the reportable data, providing utmost confidence for the banks in reporting the CRS data. This would save a lot of time and redundancy on both sides.
Macro Global offers a comprehensive “GAP Analysis and Recommendation” exercise, in which our subject matter experts will collaborate with the concerned teams of the financial institutions, perform raw data analysis, and bridge the gaps.
MG’s Adhoc and On-demand support for HMRC queries
In the event, that HMRC detects and notifies inaccurate data around the submitted CRS Reports, MG with its team of SMEs provides an extended arm to precisely fix the erroneous data by efficiently generating the Submission Variation and Submission Replacement XML files within the stringent timelines as specified by HMRC. The platform enables multiple variation submissions with ease.
Click Here to know more about the other features and benefits offered by CRS Stride.
