Brexit and Last Week’s CySEC Directives

Wednesday, 06/07/2016 | 09:09 GMT by Guest Contributors
  • Some of the new requirements will prove quite challenging for operators and vendors alike.
Brexit and Last Week’s CySEC Directives
Bloomberg
John Karanztis

This article was written by John Karanztis, Managing Director and CEO at iSignthis Ltd.

While the final impact of Brexit is unlikely to be known for some time, the regulatory impact on firms operating between Cyprus and the UK is likely to be limited.

Whilst this may appear to be a bold statement, let’s look at some of the treaty obligations and legislation underpinning regulations.

AML/CFT

There is a complex interaction of AML treaties and laws including EU, FATF and MONEYVAL obligations, on the UK and Cyprus respectively.

Whilst the 3AMLD and 4AMLD harmonise the way that all EU member states approach money laundering and counter funding of terrorism, it is important to note that only the original western EU countries are direct signatories to FATF – including the UK but excluding Cyprus.

Cyprus is a member of the MONEYVAL group, which includes the ‘Eastern’ EU member states, together with the Ukraine, and Russia which is also a FATF member. However, the joint MONEYVAL and EU members, including Cyprus and the Eastern EU states including Estonia, Latvia, Lithuania, Poland, Czech, Hungary, Romania, Bulgaria, Croatia and Slovakia, are bound by the 3AMLD and the 4AMLD, which have both been written to meet the FATF 40 recommendations.

I can’t see the UK moving away from the 4AMLD for a number of reasons, including its obligations to FATF outside of any EU based obligations, the attractiveness of being harmonised with the EU, as well as the fact that the implementation date of 4AMLD is next June – which is well within the period where the UK must continue to adhere to EU regulation, even during a Brexit.

Political Aspects

What is likely to change is the ability for UK regulated firms to operate in the EU. This will no doubt take a similar form of discussion as banking and financial services access for UK companies into the EU. For CIFs that currently also operate in the UK, it may pose the reverse challenge. These however are political issues, and not regulatory ones, noting that the regulations themselves are there to meet overarching obligations to FATF and MONEYVAL.

New Cyprus Directive re Article 64 of Law

CySEC released a new directive Directive- 144-2007-08(Α) (in Greek only) last week, harmonising Cyprus with the 3AMLD and preparing for the 4AMLD.

The directive also raises the bar with regard to CDD requirements by CIFs, with documents needing to be either original, certified, or used in support of and together with other remote verification elements.

Whilst the directive introduces electronic verification, it is an updated 2016 version of the 2004 approach that UK operators would be familiar with, due to the requirements with respect to real time, alerting, quality and updates of the reference data.

Documents

CySEC has confirmed that documents must be either original or certified as true copies in their physical form – directly addressing the current practice of some CIFs who have been using uncertified copies uploaded by end customers as the sole or primary basis for identity verification.

Remote Verification Elements

The following methods can be used to verify a customer's identity, with CIFs needing to assess each on a risk based approach, together with the quality and reliability of the source data or information. CySEC still requires (uploaded) copies of documents to be collected when using any of the below remote verification elements, which provide support in identification and verification of a customer.

- An authenticated transaction from an EU or equivalency financial institution drawn from an account in the customer's name.

- Confirmatory evidence from a financial institution of the customer's name, address and passport (or presumably other identification) details. This is a letter of introduction from the customer's bank, and it needs to be original or certified.

- Confirmation of home or office telephone listed in a reliable public directory.

- Video conference with the customer, provided that conference is recorded with high quality static frames of identity documentation. This is consistent with BaFIN and Swiss regulator approaches. We question how practical, scaleable or economic this approach is for a standard process, given that it will require a trained officer to conduct each interview. We do see the benefits of this approach for exceptions handling and audit, as it does have the benefit of being 'instant' as opposed to Items 2 or 5.

- Physical mail out of a post card to a customer’s address, and requesting customer to confirm a one-time code printed on mail out.

- Electronic verification, provided that ALL of the conditions are met, as summarised below.

- Electronic database must conform with EU privacy/data laws in how they are sourced, and be registered with an EU data protection agency. Not particularly difficult you might think, but, consider that PayPal fell foul of this for its Turkish operation (i.e. failed to store data to the requirements of Turkish law within Turkey) last month, and lost its Turkish financial license.

- Electronic databases need to show current and historic evidence that the person exists. They must contain both positive information (at least full name, address and the client's date of birth) and negative information (eg committing crimes like identity theft, including a deceased person files, including on sanctions lists and restrictive measures by the European Union and the UN Security Council). On the face of it, this appears to be ok. There should be a number of providers that should be able to offer this - the negative checks are worth querying of any provider however, as well as proving the 'recency' of their data.

- Electronic databases must contain a wide range of sources with information from various time intervals, which are updated in real time (real-time update) and send notifications (trigger alerts) when important data differentiate. Databases with a "wide" range of sources from "various time intervals" and trigger alerts on changes will prove challenging for most vendors.

- The CIF has made suitable enquiries or investigated with regard to the accuracy of the data and their results, and assessed their significance in relation to the degree of certainty with respect to the control of the customer.

- Establishment of procedures that allow the CIF to record and store information used and the results must be authenticated.

The above (which are set out in paras 1 (b) (1) (iv) and (v) of the directive) will be interesting in practice, as they start to require quality and consistency of data that is not addressed by the UK regime. The directive has incorporated and drawn from global best practice elements from regulators outside the EU.

Data Integrity

The directive requires that CIFs establish procedures to satisfy itself as to the quality, completeness, validity and reliability of the information to which it has access. The directive also requires that the review process includes both positive and negative information. This may present a challenge for data brokers and aggregators who often may not be focused on the ‘recentness’ of their data or if their data has been subject to a data breach elsewhere that may unknowingly invalidate the use of their data. It’s the “unknowingly” aspect that causes the headaches as to the veracity of the data, and will also fall foul of CySEC Directive 1(B)(Vi).

2+2 ID&V

Finally, the information must be derived from two or more sources, which is accepted practice globally for electronic verification. At a minimum, the electronic means must meet the following correlation model:

- Locating the full name and present address of the client from a source, and

- Locating the full name of the client and either this address or date of birth of a second source.

The CySEC requirements appear to be more robust than the UK’s JMLSG, which accepts in practice that a 2+2 is 'adequate' without questioning the data integrity behind it. This in turn means that UK 2+2 vendors will unlikely be able to offer an 'out of the box’ solution, and that they must address the requirements of CySEC's paragraphs 1(B) (vi), and paragraphs 2 & 4 directly.

That's probably not a bad thing, as the premise under which the UK model was designed has long gone. It was assumed that Personally Identifiable Information (PII) remains largely non-public. Identity theft, hacks, breaches, social engineering, and self-disclosure (e.g. social media) effectively nullifies the core premise that 'PII data is private'. Unfortunately, it is no longer the case that PII available on credit reference databases, electoral rolls and the like is non-public, and the use of authentication, real time updates and comparative analysis is now a necessary and smart requirement.

Some of these will prove quite challenging for operators and vendors alike.

John Karanztis

This article was written by John Karanztis, Managing Director and CEO at iSignthis Ltd.

While the final impact of Brexit is unlikely to be known for some time, the regulatory impact on firms operating between Cyprus and the UK is likely to be limited.

Whilst this may appear to be a bold statement, let’s look at some of the treaty obligations and legislation underpinning regulations.

AML/CFT

There is a complex interaction of AML treaties and laws including EU, FATF and MONEYVAL obligations, on the UK and Cyprus respectively.

Whilst the 3AMLD and 4AMLD harmonise the way that all EU member states approach money laundering and counter funding of terrorism, it is important to note that only the original western EU countries are direct signatories to FATF – including the UK but excluding Cyprus.

Cyprus is a member of the MONEYVAL group, which includes the ‘Eastern’ EU member states, together with the Ukraine, and Russia which is also a FATF member. However, the joint MONEYVAL and EU members, including Cyprus and the Eastern EU states including Estonia, Latvia, Lithuania, Poland, Czech, Hungary, Romania, Bulgaria, Croatia and Slovakia, are bound by the 3AMLD and the 4AMLD, which have both been written to meet the FATF 40 recommendations.

I can’t see the UK moving away from the 4AMLD for a number of reasons, including its obligations to FATF outside of any EU based obligations, the attractiveness of being harmonised with the EU, as well as the fact that the implementation date of 4AMLD is next June – which is well within the period where the UK must continue to adhere to EU regulation, even during a Brexit.

Political Aspects

What is likely to change is the ability for UK regulated firms to operate in the EU. This will no doubt take a similar form of discussion as banking and financial services access for UK companies into the EU. For CIFs that currently also operate in the UK, it may pose the reverse challenge. These however are political issues, and not regulatory ones, noting that the regulations themselves are there to meet overarching obligations to FATF and MONEYVAL.

New Cyprus Directive re Article 64 of Law

CySEC released a new directive Directive- 144-2007-08(Α) (in Greek only) last week, harmonising Cyprus with the 3AMLD and preparing for the 4AMLD.

The directive also raises the bar with regard to CDD requirements by CIFs, with documents needing to be either original, certified, or used in support of and together with other remote verification elements.

Whilst the directive introduces electronic verification, it is an updated 2016 version of the 2004 approach that UK operators would be familiar with, due to the requirements with respect to real time, alerting, quality and updates of the reference data.

Documents

CySEC has confirmed that documents must be either original or certified as true copies in their physical form – directly addressing the current practice of some CIFs who have been using uncertified copies uploaded by end customers as the sole or primary basis for identity verification.

Remote Verification Elements

The following methods can be used to verify a customer's identity, with CIFs needing to assess each on a risk based approach, together with the quality and reliability of the source data or information. CySEC still requires (uploaded) copies of documents to be collected when using any of the below remote verification elements, which provide support in identification and verification of a customer.

- An authenticated transaction from an EU or equivalency financial institution drawn from an account in the customer's name.

- Confirmatory evidence from a financial institution of the customer's name, address and passport (or presumably other identification) details. This is a letter of introduction from the customer's bank, and it needs to be original or certified.

- Confirmation of home or office telephone listed in a reliable public directory.

- Video conference with the customer, provided that conference is recorded with high quality static frames of identity documentation. This is consistent with BaFIN and Swiss regulator approaches. We question how practical, scaleable or economic this approach is for a standard process, given that it will require a trained officer to conduct each interview. We do see the benefits of this approach for exceptions handling and audit, as it does have the benefit of being 'instant' as opposed to Items 2 or 5.

- Physical mail out of a post card to a customer’s address, and requesting customer to confirm a one-time code printed on mail out.

- Electronic verification, provided that ALL of the conditions are met, as summarised below.

- Electronic database must conform with EU privacy/data laws in how they are sourced, and be registered with an EU data protection agency. Not particularly difficult you might think, but, consider that PayPal fell foul of this for its Turkish operation (i.e. failed to store data to the requirements of Turkish law within Turkey) last month, and lost its Turkish financial license.

- Electronic databases need to show current and historic evidence that the person exists. They must contain both positive information (at least full name, address and the client's date of birth) and negative information (eg committing crimes like identity theft, including a deceased person files, including on sanctions lists and restrictive measures by the European Union and the UN Security Council). On the face of it, this appears to be ok. There should be a number of providers that should be able to offer this - the negative checks are worth querying of any provider however, as well as proving the 'recency' of their data.

- Electronic databases must contain a wide range of sources with information from various time intervals, which are updated in real time (real-time update) and send notifications (trigger alerts) when important data differentiate. Databases with a "wide" range of sources from "various time intervals" and trigger alerts on changes will prove challenging for most vendors.

- The CIF has made suitable enquiries or investigated with regard to the accuracy of the data and their results, and assessed their significance in relation to the degree of certainty with respect to the control of the customer.

- Establishment of procedures that allow the CIF to record and store information used and the results must be authenticated.

The above (which are set out in paras 1 (b) (1) (iv) and (v) of the directive) will be interesting in practice, as they start to require quality and consistency of data that is not addressed by the UK regime. The directive has incorporated and drawn from global best practice elements from regulators outside the EU.

Data Integrity

The directive requires that CIFs establish procedures to satisfy itself as to the quality, completeness, validity and reliability of the information to which it has access. The directive also requires that the review process includes both positive and negative information. This may present a challenge for data brokers and aggregators who often may not be focused on the ‘recentness’ of their data or if their data has been subject to a data breach elsewhere that may unknowingly invalidate the use of their data. It’s the “unknowingly” aspect that causes the headaches as to the veracity of the data, and will also fall foul of CySEC Directive 1(B)(Vi).

2+2 ID&V

Finally, the information must be derived from two or more sources, which is accepted practice globally for electronic verification. At a minimum, the electronic means must meet the following correlation model:

- Locating the full name and present address of the client from a source, and

- Locating the full name of the client and either this address or date of birth of a second source.

The CySEC requirements appear to be more robust than the UK’s JMLSG, which accepts in practice that a 2+2 is 'adequate' without questioning the data integrity behind it. This in turn means that UK 2+2 vendors will unlikely be able to offer an 'out of the box’ solution, and that they must address the requirements of CySEC's paragraphs 1(B) (vi), and paragraphs 2 & 4 directly.

That's probably not a bad thing, as the premise under which the UK model was designed has long gone. It was assumed that Personally Identifiable Information (PII) remains largely non-public. Identity theft, hacks, breaches, social engineering, and self-disclosure (e.g. social media) effectively nullifies the core premise that 'PII data is private'. Unfortunately, it is no longer the case that PII available on credit reference databases, electoral rolls and the like is non-public, and the use of authentication, real time updates and comparative analysis is now a necessary and smart requirement.

Some of these will prove quite challenging for operators and vendors alike.

About the Author: Guest Contributors
Guest Contributors
  • 410 Articles
  • 9 Followers
About the Author: Guest Contributors
This could be your profile next week. Simply apply!
  • 410 Articles
  • 9 Followers

More from the Author

Retail FX

!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|} !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}