CRS – Common Reporting Standard

An OECD-led initiative, similar to FATCA. It’s about “…paying the right amount of tax to the right jurisdiction”, or more prosaically, it “…reduces the possibility for tax evasion.”

Another initiative that requires client data to be compared across systems, normalised and checked.

Overview

Relevant Information

Six “Indicia” or types of information have been defined that are used an indicators that a given client account belongs to a particular jurisdiction. However, such Indicia includes addresses and telephone numbers which opens a very wide door to inconsistency and human input error.

When do we Worry

Though CRS / AEOI is for information exchange, Indicia are generally of greater concern to financial services companies if there is a difference between the account’s jurisdiction and the Indicia.

Inherited Issues

Depending on the structure of the IT systems, there could be several different versions of data that are Indicia and rules will be needed to structure the hierachy of the data. Individuals may have inconsistent Indicia across multiple sole accounts, or even if it is consistent, then relevant joint account information may take precedence over the sole account data.

Inconsistent, manually adjusted P&L process

A global soft commodity company was calculating its P&L and P&L explain in excel across multiple locations. It needed a standard process that worked with and accepted the data nuances across all centres, complicated by a mix of trading and physical processing.

CPRA designed and implemented a full reval P&L explain with 200+ single and pairwise components for volume, plan and market data variations. Results were displayed in a dynamic dashboard.

Average 99+% P&L explain.

Inconsistent Data – Country Conventions

In a global business even if Indicia data is consistent for a given country one cannot guarantee that other countries have the same structure or the same internal consistency.

We discuss how we can tag and normalise text based data here.

DDI: +44; 0044; 011 44

UK; United Kingdom; U.K.; Inglaterra; ISO GB or ISO 826.

Solution

So this is another data issue: finding and tying together the information that may exist across multiple systems for a given user, developing a hierarchy and rule set to identify data inconsistencies. It’s a reconciliation and hierarchy exercise for client data, then transformation into the CRS xml format.

We used our rules based engine to connect to the myriad of data sources that the client had, applied a cleaning and normalisation process to allow the data to be joined.
We worked with clients to help determine the hierachies and process if the data were inconsistent, for a given individual.
Often this was deployed on a standard windows desktop under the business user’s control due for data privacy compliance.

Application

Data Cleaning and Matching

Our experience in client data cleaning meant that we had a head start in the normalisation of the data.

Mapping Tables

Mapping tables were used to control the data transformations, whether mapping from one language to another, IDD formats or country names.

The use of mapping tables limits the amount of hard coded rules (that are often invisible to users) and allows rules to be ordered in a centralised and coherent manner.

Reconcilations

Typical reconciliations of data were required to tie together data across different systems and reference data repositories.

Sub-accounts, power of attorneys, relationship management folders, nominee accounts data may all be relevant in a given client and would require reconciliation of identifiers. In one case a client had 28 different data sources.

Regular Structured Output

It’s another report and another output with it’s own nuances that make it different from all the other reports adding to the report burden.

Fortunately, CPRA’s rules based engine can output the correct structure for upload into an xml convertor and run an a repeatable basis.