The majority of the Sprint 48 development work has been focussed under the hood, enhancing our automation technology stack for future gains that will allow us to reach more jurisdictions more efficiently – In the short term Benvenuta italia!
Our goal remains to automate everything we can, whilst also maintaining our leading role in GLEIS Data Quality. We’ve also completed a few minor functions post support of CDF 3.0, some of which will be rarely triggered, but we still need to support and some of which are now becoming more common place as we grow our international enterprise client base.
Contracts – ‘Contract Expiry Dates’ may change in query LE-RD/Check GUI
Prior to Sprint 48, ‘Contract Expiry Date’ (CED) was based on a simple formulae of Contract Expiry date = Contract Start Date + Multi-Year. However, given that we’ve had to modify the Next Renewal Date (NRD) for LEIs for various reasons we sometimes saw date alignment issues appear. NRDs may have been modified due to one of the following reasons:-
- GLEIF Policy (See International Branches – Alignment of Next Renewal Date(s) below),
- Enterprise needs around LEI NRD alignment via Advanced API functions such as “nextRenewalDate”
- During imports and early renewals, where we successfully add up to 60 days.
New Logic will align the Contract Expiry Date to the NRD of the final year of any multi-year contract – i.e. no gaps.
We expect the majority of the Contract Expiry Dates will not change after Sprint 48 is released – only the errors will be removed.
International Branches – Alignment of Next Renewal Date(s).
Let’s ensure we know exactly what an International Branch is by looking at the State Transition Rules (Page 18)
GLEIF State Transition Rules (Version 2.6)
“Branches are part of the same legal person as their head office, and can be described as different establishments, or locations, of the same corporate entity, whereas a Subsidiary is a legal person distinct from its parent. However, International Branches may have independent requirements for regulatory reporting and are therefore eligible for their own LEIs. A Branch relationship describes the relationship between an International Branch and its head office. The Branch LEI MAY represent multiple offices or locations of a Legal Entity in a host country jurisdiction. The Legal Entity SHALL provide the address information and additional Reference Data of the Branch. A Branch SHALL NOT declare a direct or ultimate accounting consolidating parent relationship or report exceptions.”
Here’s a representation of the relationship structure between a Head Office and it’s International Branch(es). Please note that the key word remains ‘International’ – i.e. it’s not possible to issue LEIs to alternative entities across the United States. you an only issue to the entity that is incorporated (Usually this will be in Delaware). Back to the thread…
The Next Renewal Date (NRD) of an LEI code is one of the most important events in the LEI calendar. It highlights the point at which the LEI code LAPSES (if it is not renewed in time). The RapidLEI platform provides up to 60 days of headroom to take action, warning by email and via the DASHBOARD interface. Ordinarily, LEIs, even multi-year LEIs, need to be renewed every 365 days. If LEIs are linked to other LEIs by Level 2 (who owns whom) relationship records, then the fate of the Parent record can, and does, affect the fate of the associated Child(ren). The Status of the Head Office of an International Branch affects all International Branches. i.e. When the Head Office LAPSES, all International Branches LAPSE too.
This functionality has been in place for several years in our system. What’s different now, in Sprint 48, is that we have taken the opportunity to pre-warn our customers when this might happen during branch workflows. If you are applying for an LEI code for a Branch, we’ll warn you of the NRD of the Head Office. We are tasked to align the NRD of the Branch to that Head Office when we create and LEI code, import and existing LEI code or renew one that we manage. Depending on the NRD of the Head Office, this will always vary during the initial alignment process.
Once alignment has taken place, there should be no need to curtail the validity of the BRANCH again in the future, as each annual renewal of the Head Office (ideally through RapidLEI by importing the Head Office LEI code if it’s not already managed by us) will allow the branch(es) to be renewed too. It’s only the first time through the process where there may be an issue/loss of validity. Don’t worry, the solution is easy. Simply renew (or import if not managed by RapidLEI) the head office first, so each International Branch can be set to the maximum time frame. Each year, renew the Head Office first and then each International branch afterwards.
Tagging Orders – Billing Efficiency for Enterprise Customers with multiple cost centres.
LEI codes are typically not that expensive in real terms (especially from RapidLEI or one of our partners), however as with any digital asset, care needs to be taken with the life cycle of the asset. Early renewal of the data to prevent LAPSING and the ability to modify the data at any time via our fully functional management system helps, but sometimes customers need to add unique ‘tags’ to each LEI code so that RapidLEI can bill the appropriate cost centre, or clients can efficiently slice and dice their LEI portfolio. Adding tags is easy – Ensure your account manager is aware you need to use tags and they’ll allow this function within the ‘My Settings’ area. Simply add tags using the simple interface.
From the LEGAL ENTITY IDENTIFIERS Dashboard, tags can be allocated on an individual order by order basis…
or to multiple orders at once…
The tags will also be visible on any .xlsx based reports downloaded from the dashboard.
Support for Funds classified as ‘in formation’
In some jurisdictions or financial markets, Funds are required to have an LEI in order to register the Funds or set up the clearing accounts, before they become active from a legal perspective. We have therefore made some enhancements to our workflow to allow for application of ‘in formation’ Funds
RapidLEI will still create and validate the LEI record for any Fund ‘in formation’, including all relevant relationships, and based on the information that is provided take the necessary steps to ensure the Fund meets, or will shortly meet, the requirements to be issued an LEI.
Technically, to support a Fund ‘in formation’, the ROC (Regulatory Oversight Committee) have amended Policy and CDF (Common Data Format) schema to allow the Entity Status to be reported as “NULL” and Entity Creation Date to be omitted. To support these two changes, you will need to indicate the Fund is in formation and has no Registration Authority Entity ID (RAEID) as an RAEID would indicate registration and therefore negate the ‘in formation’ status. Here’s where you specify, for a Fund ‘in formation’
Please note that in formation Funds will only ever be associated with RA999999 (Entity Supplied Only).
If there is a fund relationship to report, you can still do this but the relationship period should not be populated.
It is essential that you notify us as soon as the fund has become legally active. Please use the ‘Amend’ function from the GUI, removing the in formation status check and highlighting the Registration Authority, Entity Status of ‘Active’ and Entity Creation Date (i.e. The date that legal status was achieved). If there was a relationship reported, we will update the relationship period start date to the date that legal status was achieved.
If for whatever reason that registration or set up of the fund is cancelled or withdrawn, we will set the registration status to be “ANNULLED”.
Updates to our API (https://rapidlei.com/api)
LEI – Upload Comments (added)
We’ve added a new API endpoint for “comments” to be added. Comments provide a useful way to allow our vetting teams to quickly act on new information. Comments can be used to pass through important information quickly such as dates, page references for Level 2 accounting information etc. We’ll be working with our partners to decide how best to pass through other structured information in the future, but for now, comments offer a quick and easy fix and can now be sent at any point for any API based order including API based renewals of orders, even those originally created using the shopping cart or bulk XLS methods. The full function is described at https://rapidlei.com/api with the following POST URL format https://api.rapidlei.com/v1/leis/uploadComments with the example format of the body as follows:-
{ "orderTrackingCode": "gIywrwb1on0rH7BswFor", "userComments": "Page 10 of the annual report details the level 2 parental structure your vetting team needs" }
LEI – Query Level 1 LE-RD and Signing Authority (Entity Creation Date added)
In line with the updates to CDF 3.1, we’ve added the “entityCreationDate” into the Level 1 query response. For example here’s a section of a typical LE-RD response for Ubisecure’s LEI (Partial response illustrated for brevity)
... "leiNumber": "529900T8BM49AURSDO55", "legalName": "Ubisecure Oy", "legalNameLanguage": "fi", "registrationAuthorityEntityId": "1748721–4", "entityLegalFormCode": "DKUW", "entityLegalForm": null, "entityLegalFormLanguage": "FI", "entityStatus": "ACTIVE", "registrationAuthorityId": "RA000188", "registrationAuthority": null, "entityCategory": "GENERAL", "entityCreationDate" : "2002-02-14T00:00:00+00:00", "legalJurisdiction": "FI", "initialRegistrationDate": "2016–08–04T11:00:36+00:00", ...
LEI – Check LEI Order Status (Entity Creation Date added)
Again, in line with the updates to CDF 3.1, we’ve also added the “entityCreationDate” into the Check LEI Order Status. Please ensure your customers verify this data. For example here’s a section of a typical LE-RD confirmation request. (Partial response illustrated for brevity)
... "legalJurisdiction": "DK", "entityCreationDate": "2020-06-16T00:00:00+00:00", "legalAddress": { ...
“orderStatus” changes during the Transfer/Export workflow – new Webhook added – “lei_transferred”
We never like to lose a customer, but sometimes it’s inevitable. Our Export Process follows the GLEIF defined protocols for “registrationStatus”, i.e. setting the LEI code’s status to PENDING_TRANSFER when a request has been received and is being discussed with the Legal Entity and PEDNING_ARCHIVAL if the entity approves the transfer. We prefer the entity to stay. if they do, the LEI code reverts back to its’ original status. This system is great for the GLEIF, but what about our API and GUI systems.
As an example, let’s take a look at an LEI that is currently ISSUED. The API end point – LEI Check Order Status, shows the “orderStatus” parameter as “complete”.
{ "message": "LEI Issued and Published to GLEIS", "leiNumber": "98450049B75BHF675020", "nextRenewalDate": "2023-10-20T10:50:58+00:00", "registrationStatus": "ISSUED", "adminMessage": "", "orderTrackingCode": "CJguFnlaBThKI4UFHSHg", "orderStatus": "complete", "publicationStatus": "published" }
Any Transfer Request from a ‘Receiving LOU’ moves the “orderStatus” to “transferring“. This status will be maintained throughout the transfer process (replacing “complete” until the request is either approved or rejected. If approved, the timeline from approval to the LEI being TRANSFERRED is dependant on the Receiving LOU. To be complete, once we set the status of the LEI to PENDING_ARCHIVAL it’s an indication to the Receiving LOU to being their process of importing and this may take a number of days.
{ "message": "LEI Issued and Published to GLEIS", "leiNumber": "98450049B75BHF675020", "nextRenewalDate": "2023-10-20T10:50:58+00:00", "registrationStatus": "PENDING_TRANSFER", "adminMessage": "", "orderTrackingCode": "CJguFnlaBThKI4UFHSHg", "orderStatus": "transferring", "publicationStatus": "" }
Once the LEI has been published by the Receiving LOU, we will set the “orderStatus” to “transferred”.
{
"message": "LEI successfully transferred to the Receiving LOU",
"leiNumber": "98450049B75BHF675020",
"nextRenewalDate": "2023-10-20T10:50:58+00:00",
"registrationStatus": "TRANSFERRED",
"adminMessage": "",
"orderTrackingCode": "CJguFnlaBThKI4UFHSHg",
"orderStatus": "transferred",
"publicationStatus": ""
} Additional points to note:-
- LEI Check Order Status is only possible for LEIs created, imported or renewed via API as the orderTrackingCode is mandatory.
- Webhook notifications will only be sent for orders created, imported or renewed via API with a suitable “notificationUrl”.
- The exiting Webhook “lei_published” will continue to be sent when we publish alternative status’s to GLEIF such as PENDING_TRANSFER, PENDING_ARCHIVAL (or back to ISSUED/LASPED if a transfer objection is received).
- A new Webhook notification has been added. “lei_transferred” will be sent once the LEI has successfully been transferred to the Receiving LOU.
