After several significant events and the 2008 financial crisis, the G20 expressed a request to the FSB (Financial Stability Board) to facilitate the many objectives of financial stability. Shortly before the G20 summit in 2012 the institute responded to this request. It offers increased security through the implementation of 15 high-level principles of the LEI system as well as 35 recommendations for the integration and proper development of this process. These recommendations were subsequently approved by the G20 in Los Cabos in the same year 2012.
The LEI code is then gradually implemented. In 2014, all the large groups are obliged to have an LEI code, then since the first quarter of 2018 it becomes mandatory for all companies regardless of the size of the company. Because indeed, the code aims to allow the traceability of each company and thus have more transparency on all financial transactions in the world.
This desire to increase security pushes institutes to always question the efficiency and use of the LEI code.
LEI code integrated into SSL
SSL certificates may soon be more involved in the KYC (Know Your Customer) process. Indeed, SSL and LEI have several points in common which can allow a possible gathering.
SSL is public and visible to everyone. Thus, by clicking in the URL of a company's website, we have access to several information about the latter and in particular its certification, proof of security for the user. LEI is also an accessible code to anyone who wants it and is available on several databases open to the public.
It is therefore always in the same perspective as at the Los Cabos summit in 2012, that the efficiency of the KYC seeks to be strengthened. A recent announcement made at Ca / Browser Forum 2019, expresses the possibility of fully integrating LEI codes into the SSL certifications of companies with a website. This announcement was unanimous among the members of certification authorities, because in addition to ensuring an easy search for financial institutions, this operation will also reach a new audience. By new audience we mean here all users browsing websites and who normally should not worry about such a code. This audience is the end user.
This integration is intended to be practical and effective for several reasons.
Direct and precise:
The end user or the institution issuing the will to do research company, can find the information at the exact moment it is on the company's website. If the latter does not have a site, the GLEIF database remains the main alternative to this research.
Regulated and consistent:
The LEI code is for businesses what the passport number is on our identity papers. Thus, it makes sense to easily obtain this number as it is simple to obtain an individual's passport number upon request of his papers.
In this way the LEI code takes on its full meaning and would act as real proof of identity within the SSL certificate.
Detailed if necessary:
The LEI code could also reveal more information about companies in this way. In addition to providing the details of "who is who" for a business, it would also provide information on "who owns who", which helps to understand the structure of a company with subsidiaries. If a company seems doubtful to you in its procedures or in its communication, it would then be simple to check if a reliable parent company exists and if necessary to contact it for more information on the company with which you treat.
The LEI code integrated into the SSL would probably be followed by the code of the issuing LOU which has its own identification. This code allows you to go back to the source of the program if necessary to complete the identity of the LEI.
The transparency of the LEI code will only be greater through this merger and will above all allow easy and rapid access to the information sought for the end customer, but also for the financial institutions in charge of business files. Some companies like SSL247 for example, which issues SSL certificates, have already developed sister companies capable of registering LEI codes for their customers.
If this integration is under development, it will be implemented very quickly. This will apply first to EV (Extended Validation) SSL certificates and then be applied to a wider range of SSL.