FATCA & CRS Compliance

Introduction

VSM has been engaged by a few public and private sector banks in India to identify/process the reportable accounts under FATCA & CRS regulations and ensure error-free uploading of FATCA&CRS Compliance Data in 61B format on the secure site of CBDT, which is the nodal authority for India.

Gaining from Experience:

As CBDT keeps enlarging the scope and coverage of reportable account holders, we realized that that Reporting Financial Institutions (RFIs) can no longer afford to continue with adhoc procedures to identify reportable account holders (and their accounts), as also to take up and follow up documentation and remediation. The reportable account holders (under FATCA & CRS regulations) have gone up from a few thousand to a few hundred thousand for medium sized banks. The task becomes complicated if a bank has Strategic Business Units (SBUs like DP, PMS Cells), products of which are also required to be examined for identifying reportable account holders.

Automation using VSM’s model of “Solution Assisted Data Remediation”

For the current set of clients ranging from small/private sector banks to medium sized public sector ones, VSM has automated the entire process of data mapping, extracting data from multiple systems, processing the same in its application, taking up (initiating) communication with operating units (branches) and customers for completing documentation & remediation, compiling/uploading the final report. The case study described below, explains as to how VSM has gone ahead with FATCA- CRS processing, using an automated process and the advantages accruing to the Reporting Financial Institution (RFI), which is a medium sized Public Sector Bank.

The Process

Step-1: We discussed with IT and bank’s compliance team to understand the following: What products and corresponding IT systems to take data from? Normally it would be: CBS –for all relevant liability products DP-Depository Participants - for equity investments and related information PMS-Portfolio Management System In this Bank, we had only CBS and DP Accounts for reporting to CBDT under FATCA & CRS Compliance.
Step 2: We then defined the fields (by mapping the CBDT fields with table/field names in bank systems) required to extract—this was done with the help of the bank. Code Mapping: For all the Reference Masters like Country code, Currency Code, Account Status, Account Type, we mapped the Codes one by one which were available in CBS with the codes required for reporting to CBDT. After mapping the fields, we defined the indicating fields (Indicia) available in the source system (in CBS) to determine what records to short-list for reporting.
Step 3: Helped the bank in the script to extract data. The script covered 4 files for each system:
i) Account holders
ii) Accounts
iii) Related party information
iv) Documents – The documents like self- certification forms were not available during the first data extraction as most of the data are to be picked up from the self_certifcation to be obtained as a part of data remediation subsequently. Though we have a separate data capture utility to capture additional details and the self-certification details, the Bank used its own utility to capture the additional data.
Step 4: We uploaded extracted files into our application using our utility.
Step 5: Next we unified the data –i.e. combined the files for each Data Type based on the unique reference key which is the customer_id. So now, we had reached a stage, where “Possibly Reportable” data were all in one place. Now started the job of determining
➢ With certainty—are all these reportable?
➢ Do we have all the required data to report?
➢ Are all the data in line with what is needed? (Formats etc.)
➢ Are the data consistent and free from inconsistencies such as an out-of-range DOB, irregular gender, Self-Certification vs documentation inconsistency, occupation type-code miss-match, etc.
➢ Have we classified the account holders?

Our utilities – what we did with them?

Code mapping by position: Our utility mapped all the codes by position ---and generated error reports. For example, we know that position 5 in the CSV file is country code. We provided error lists for CBS codes which were not having equivalent codes in CBDT 61B Codes. Data consistency/correctness were also checked automatically by our utility – e.g. an entity name given as an individual due to wrong constitution selection in CBS. This process was done for all 4 data types. Thus, with the help of Data Mapping accelerator (DMA s) and utilities, we had unified DATA that conformed to CBDT convention and devoid of errors. With this, every time, data file was extracted and uploaded through the utility. The above processes were automated and manual interventions were avoided during subsequent data extractions and conversions, which helped the Bank in saving a lot of manpower.

Factor - The Core FATCA_CRS Application:

Through the above steps, we were able to identify the “Potentially Reportable” account holders and all related data in ONE file each—for each data type. These files were uploaded into Factor. Factor was able to complete several things:

1. Verification and validation Correctness of several data elements—such as PAN no, Aadhar no, date_of_birth, GIIN etc. At each stage, we provided error reports for rectification by the Bank
2. Aggregation of balances Once this is done, we PROMOTED the data into FATCA-CRS layer; with the help of user-definable rule engine, the account holders were classified as individual/entity account holders reportable under FATCA & CRS regulations. Note that, once the classification was done, we had the final set of reportable account holders and their accounts, with classification. But, even at this stage, data were not REPORT WORTHY as the data was incomplete, bereft of certain mandatory fields required for reporting

Our Services model

It was at this stage that our services model, with its utilities, functional experts and technical resources added a lot of value to the bank. We now had Reportable FATCA accounts: Documented-undocumented, with errors (e.g. DOB blank/wrong, gender blank/default, etc.) Reportable CRS accounts: Documented-undocumented, with errors to be rectified. The objective was to have the CORRECT set of REPORTABLE accounts, ALL documented, and ALL fields correctly captured & filled up, which would be 100% compliance. That was our goal in these services. We brought automated mailing utility (to operating units, branches, and account holders) for follow up. . We also guided the bank on what accounts were worth following up to ensure documentation. We helped the bank in creating required audit trails on data remediation steps; this is an RBI need. Of course, because we know the space well, there were several other areas where we helped: ensuring consistency—are we reporting all accounts reported last year (a must step), etc. We took a risk based practical approach in data remediation/due diligence process like segmented customer approach concentrating on high value customers above a threshold balance in obtaining self- certification and making the account holder as “Documented” thereby minimizing the risks for the bank in reporting critical accounts.

Benefits in our structured approach

At least six major benefits accrued to the Bank through our engagement with them

1. We ensured that all reportable accounts were covered in spite of high volume in reportable accounts during the current year, as all the low value CRS accounts were included for reporting to CBDT. The volume of reportable account became multifold (from around ten thousand accounts in the year 2016 to more than 300 thousand accounts during 2017). Error-free data- the bank did not have rejections from CBDT. We also inserted default codes during the final data transformation, wherever necessary to avoid rejections.
2. Audit trails in customer communication, status changes, authentication, user activity
3. Data integrity through the processing cycles
4. Cost savings— the Bank’s compliance and IT Dept. did not spend much time on this exercise
5. Improved follow up on data remediation and making the source data error-free for correct compilation of other statements both internal and regulatory associated with the customers.
6. Follow up on due diligence, as needed by RBI.