By Mark Davies, general manager
and head of Avox
Four years after
its 2010 inception, the Foreign Account Tax Compliance Act
(FATCA), now implemented, will impact financial institutions
and investment firms globally, including those engaged in
cross-border derivatives transactions.
The Act requires
firms to report information pertaining to their US clients, for
the purpose of stymieing tax avoidance by US persons hiding
income and assets overseas.
behind FATCA is a simple one: know who your customers are;
maintain accurate, up-to-date information about them; and
report this information to home governments or directly to the
compliance with the requirements is, seemingly, much more
complex. It can be most likened, from a data perspective to
Know-Your-Customer (KYC) obligations, but KYC information will
be, in the main part, insufficient for FATCA reporting
purposes. Indeed, FATCA classifications go well beyond those
contained in KYC documentation.
require some accounts to be reviewed periodically, based on
customer risk ratings. Conversely FATCA requires that
institutions should identify any changes in circumstance (for
example, a new operating address or company name) for
all clients on a continuous basis to make sure that
information updates have not changed the US or non-US status of
effect of the different reporting requirements – under
Dodd Frank, Emir and FATCA – is a more widespread
awareness of data quality and accuracy. While these regulations
are different in purpose, scope and technical requirements,
they all necessitate efficient client data processes and
institutions should therefore identify opportunities to make
adjustments in their approach to sourcing client data as well
as the design of systems and processes.
that good data management makes to how efficient, and even how
compliant, an institution is should not be underestimated. In
the context of FATCA, firms should ask themselves the following
as a first step in achieving efficiency:
conducted an analysis of our clients?
determine and classify the status of an entity for FATCA based
on a number of criteria related to geography, industry sector
and ownership. The legal entity data needed includes GIIN
identifier codes, entity types (& exemptions), public
listing data and ownership information to 10% shareholding in
significant research time and resources to source, check and
maintain this information for the thousands of entities that
institutions have on their books. Effective sourcing of
accurate data at this initial stage can help to focus outreach
effort where it is needed and greatly reduces the number of
requests for client documentation.
customer data centralised?
institutions store customer data and documentation in
technology silos and disparate operational processes--for
example, privacy considerations will often prevent KYC
documents used in the on-boarding function from being shared
among other levels of the institution, who instead rely on
their own data sources.
complexity and cost, and means that clients are bothered by
duplicate requests for information - a problem which will be
exacerbated by FATCA’s reporting requirements.
Ultimately, institutions should be able to produce a single
view of the customer as a foundation for effective and
efficient compliance and timely reporting.
is our data?
The problem of
inaccurate data has grown over time: more systems and
increasingly complex architecture result in more unstructured
data and parallel views of 'the truth’, and all
the time legal structures and company details change at a rate
of up to 20% per annum.
Simply keeping up
with changes to existing datasets is a huge challenge. In order
to ensure compliance with FATCA and other regulatory
requirements, firms must ensure that they have a good and well
maintained basic framework of entity information on which to
hang regulation specific fields.
Since FATCA was
enacted, the industry has expressed concerns about the
complexity of the reporting requirements. Making sure that
client data is as accurate and up-to-date will be the first
– and crucial – step in removing some of the
pain points experienced in this and most other reporting