Since their conception hundreds of years ago, banks have been responsible for various know-your-customer (KYC), anti-money laundering (AML), and background checks in one form or another. Their role as trusted intermediary has been essential to the day-to-day running of society ever since.
In September 2020 the GLEIF defined the concept of Validation Agents in coordination with the Globally Important Financial Institutions (GIFI). This is in recognition of the fact that processes performed by banks when onboarding new clients have direct parallels in the verification of Legal Entity Reference Data (LE-RD).
According to the GLEIF: “The Validation Agent role allows financial institutions to obtain and maintain LEIs for their clients in cooperation with accredited LEI Issuer Organizations by leveraging their business as usual client identification procedures in Know Your Customer (KYC), client onboarding or standard client refresh update processes.
The goal of the Validation Agent role is to streamline the LEI issuance process and, in doing so, deliver a multitude of benefits for legal entities, LEI Issuers and financial institutions that serve legal entities as clients.
The Validation Agent role is designed to remove the duplication of processes across a financial institution’s client onboarding and LEI issuance, resulting in a simpler, faster and more convenient experience for financial institutions and their clients, enabled by a more efficient LEI issuance process.
This article examines some of the technological problems facing LOUs as they onboard new validation agent data and processes, and the available solutions
While the GLEIF have shared that they plan to release an API protocol around the second half of 2021 Local Operating Units (LOUs) and Registration Agents should see this as an opportunity to prepare for this eventuality. This is to ensure that the Banks are not tied to an individual LOU and allows the possibility that the Validation Agent may be able to work with multiple LOUs to leverage the local expertise available of working in multiple jurisdictions.
The API protocol has not been released, but it should be possible to make some educated guesses here. The GLEIF Common Data Format (CDF) for specifying LEI-RD is well defined and publicly available along with the cross checks and lookups that ensure that the data submitted is valid and complies with the data quality rules that have been clearly laid out.
So, what will be the challenges in integrating Validation Agents into the LEI Application Request Process? There are a couple that seem to spring to mind which broadly break down to data-quality, technology, and volume.
Internal Banking solutions are complex and relatively fixed, and it is often simpler to create/ integrate a satellite solution rather than modify the core system itself. The issue here is that the GLEIF data definitions are specific having a GLEIF ecosystem nomenclature that govern the accepted values; referencing ISO standards, Countries, Regions, Entity Legal Forms, Registration Authorities used, Registration Authority ID formats, Direct and Ultimate Ownership (Level II Data) definition and proof, and PNI and LEI usage.
So now return to the Internal Banking systems that will have their own structures and data dictionaries, trying to connect to the LOU to submit their data into the verification and approval process. This may result in the square peg trying to fit into the proverbial round hole. Furthermore, the Validation Agent Banks may wish to switch from one LOU to another as required. There is also the variety and maturity of the LOUs systems that will determine flexibility and the ability of the LOUs to develop and offer the APIs, some LOUs may decide to operate independently without the integration of validation or registration agents.
These factors seem to the point to opportunity to develop a “Proxy”/Adapter solutionthat accepts the Validation Agent’s request data, converts this to the CDF, processes the data-quality checks, and finally submits it to the LOU for Verification.
To be more specific the proxy can be developed to accept the LEI-RD in standard interchangeable formats including CSV, XML, JSON or submitted to the Receiving API that will map the LE-RD data and fields received into the formats that are defined to the request type, its domicile, and legal form. The “normalised” application will then be processed for validity, duplication, and data-quality checks performed by the LOU to ensure that conflicts or fails are not introduced into theGLEIF data.
Employing Digital Risk Management (DRM) into the process, offered by solutions such as the pTools suite of data checks, “non- structured” data such as addresses, emails, phone numbers, company names can be validated, and where checks fail the applications can be returned to the banks– failing checks and risk results can be returned to the Bank (DRM on Internal KYC) for rectification and re-submission prior to submission to the LOU.
Once digitally validated and “approved” the applications will be submitted onto the LOU through a Sending API or exports in the CSV, XML, or JSON formats that are supported. The processed and verified dataset sent to the LOU will have passed the digital checks and balances allowing the LOU to focus on the manual verifications and signoffs required.
Employing these and other elements of pTools Technologies there is the opportunity to expand the LEI Validation Agent Proxy to include the notifications and payments required for the renewal process, the scanning and identification of corporate actions that form Legal Entity Events, integration with our LOU Management Solution and the augmentation or your LEI dataset with our LEI Manager solution matching and including information from BIC, ISIN and news. This would put the LOU and Validation Agent in a position to handle the high volume of LEI registration and the ability to manage their LE-RD forecast in the coming years.
For more information and updates on the products and services of pTools Software please contact us here.