“Being Smart About LEI”

EDMworks recently hosted the first in their new series of Data Practitioner Networking Events.

“Being smart about LEI”, was a great success and we’d like to extend a big thank you to everyone who was in attendance.

 

Our CEO, Dennis Slattery opened the event by giving a brief overview of what the Legal Entity Identifier (LEI) is and what regulatory implications it has for financial institutions.

PJ Di Giammarino (founder and CEO JWG) was the first of our guest speakers and gave some more detail on regulatory impact of LEI with his overview of G20 regulations.

 

 

Next up was Kevin Bowen from Thomson Reuters, who spoke in depth about how LEI would fit into an organisational data model for the investment sector.  Kevin provided an excellent overview of the scope of organisational data within a financial firm.

 

 

Dennis then gave his insights into Being smart about LEI implementation and approaches on leverage for budget spending to ensure regulatory demands and also organisational data changes were met.

 

He then invited Chris Johnson from HSBC Securities Services to talk about LEI from a buy-side perspective.

 

The event was rounded off by a question and answer session lead by Tom Dalglish which we were pleased to see had contributions from several attendees.

 

 

These events are designed to raise questions & discussion points; they act as a forum to share opinions and knowledge with fellow industry professionals.

 

We concluded the afternoon with a peer networking session and the chance to exchange business cards over a drink or two.

 

Once again… a big thank you to everyone who attended and participated in the discussion. We look forward to seeing you at our future events…

 

  • “Symbology and Asset Matching” – June 27th 2012
  • “Enterprise Data Planning and Budgeting” – September 26th 2012
  • “Fund Structures and Fund of Funds” – November 28th 2012

 

Big Data – what is the real challenge?

by Dennis Slattery

‘Big data’ clearly exists.

Physics experiments and astronomical research generate huge data volumes.  Collecting and storing this data in a form that can be usefully analysed is a challenge. But to what extent is it a real challenge for businesses?  How much is ‘Big Data’ a real problem and how much is it another Y2K ‘theme’ designed to drive hardware sales and IT projects.

Within the Securities industry there are many large data sets that are potential candidates for ‘Big Data’ solutions.  Algorithmic trading is based on computer models developed from analysing historic correlations between diverse sets of time series data, for example stock exchange tick prices against weather pattern records, news announcements and so on. The data volumes are large, correlation analysis is complex and computationally heavy. ‘Big Data’ techniques may have a role. The same argument can be applied to real-time risk calculations and similar applications.

Many data sets are large due to inefficiency, negligence and poor management.  ‘Big Data’ techniques do not address the problem.  So spending money on Big Data technologies could be a waste.

Real example

A fund accounting system generates two records for a trade; (1) the trade execution and (2) the trade settlement a few days later. Each record is accompanied by five accounts posting records giving a total of 2*(2+5) = 14 records.  The downstream data warehouse needs these converted into a single trade record for long term usage. But because of poor or inadequate design, all 14 are stored as copies of the accounting system.  The firm is an administrator with several thousand funds under administration so potentially 50,000 real trades per day giving 700,000 records for storage. 3,500,000 per week. Say 175,000,000 per annum.

The records are replicated to data marts in different parts of the business, so let’s say a total of 525,000,000 records per annum are stored for 12,500,000 actual trades.

On average, the stored records are 2kb each including indexes and database overheads so you have storage needs of 2,000 * 525,000,000 = 1,050,000,000,000 bytes.

Description

Basic Data

Calculated Data

No of actual trades per day

50,000

 
Estimated no of trades per week  

250,000

Estimated no of trades per year  

12,500,000

Records per trade

14

 
Actual no of records per day  

700,000

Estimated no of records per week  

700,000

Estimated no of records per year  

700,000

Additional replicated data marts

2

 
Records per enterprise per year  

525,000,000

Bytes per record

2,000

 
Bytes per year  

1,050,000,000,000

Leading investment banks and brokers execute several hundred thousand trades per day!! So megabytes + poor design = Terabytes.

Small data has become bigger data.

Counters to the ‘Big Data’ problem are in developing data practices, better data planning and better training for data practitioners.

Understanding LEI

Understanding LEI and what it means for EDM

by Dennis Slattery

 

The first of our LEI blogs gives a brief overview of LEI and offers some useful links for further reading. This is taken from EDMworks ‘LEI Research Paper’ shortly to be available as a pdf on our website.

As a result of the financial crisis in 2008, there has been an increasing demand for transparency and an understanding of exposure in the financial sector. This initiative has been spearheaded by the Obama administration who, as a result of the Dodd-Frank Wall Street Reform and Consumer Protection Act (2010), formed the U.S. Treasury’s, Office of Financial Research (OFR) to oversee their Wall Street Reform Act.

“Indeed, the recent crisis has reaffirmed an old lesson—good data and good analysis are the lifeblood of effective surveillance and policy responses at both the national and international level” (Financial Stability Board and International Monetary Fund (October 29, 2009)

As part of this initiative they’ve launched a campaign for an internationally uniform Legal Entity Identification system, or LEI. The aim of LEI is to develop a universal standard for identifying all parties to financial contracts. It is a unique identifier associated with a corporate entity… or in simple terms, a sort of National Insurance number for companies & corporations.

Regulatory risk modelling depends on an institutions ability to provide positions and supporting reference data in an aggregated and standardised view… the LEI will be an invaluable tool in facilitating this.

The LEI code will be twenty alpha numeric characters long and at a minimum have the following information associated with it for each corporate entity: Name, Address, Country of Incorporation & Entity status. All of these factors could change several times over the life of an entity but the LEI will remain constant.

The Global Financial Markets Association (GFMA) state that a LEI aims; “To enable organizations to more effectively measure and manage counterparty exposure, while providing substantial operational efficiencies and customer service improvements to the industry”

 

What’s Next for LEI?

Now that the ball is rolling… what are the next steps for the LEI system?

In January this year the U.S. Treasury Dept. issued a statement that they’ve formed a LEI Expert group (under the OFR) who will deliver “Concrete proposals” for implementation by April 2012. The International Organization for Standardization (ISO) has established an LEI standard (ISO 17442) which is expected to be finalised by Q2 2012.

SIFMA are hosting a conference entitled Building a Global LEI Framework on March 14th to address current global policy, regulation and business implementation issues.

It is hoped that the DDTC will announce a plan to rollout an initial batch of 12,000 LEI’s by July this year, followed by a further 50,000 to cover Swap & OTC derivatives markets at the G20 Summit in June.

 

LINKS

 

The Devil is in the Data 2

By Will Swift, Securities expert

Welcome back,

I promised I would dig out another wrinkle where a SEDOL identifies a market listing rather than that of a country. I have spared no expense travelling the virtual world to Russia to find an example.

We see multi-listed (Cross-Listed) stock on different exchanges all the time, but there are also instances where stock is multi-listed not in a single country but on the same exchange.

An example is the Russian Federal Hydro-generating Company (RUSHYDRO) http://www.eng.rushydro.ru/, RusHydro is one of Russia’s largest power generating companies.

The company lists its Common Stock under ISIN: RU000A0JPKH7

What is different with RusHydro is it lists its stock twice on the RTS exchange.

One listing in Russian Roubles (RUB) and the other United States Dollars (USD), the LSE gives the stock separate SEDOLs to identify the currency but both SEDOLs are assigned to Russia.

http://www.rts.ru/en/securityresults.html?code=HYDR – USD

http://www.rts.ru/en/securityresults.html?code=HYDRS – RUB

Pop back soon for more wrinkles in the data we see everyday.

The Devil is in the Data

By Will Swift, EDMworks Securities expert.

Being my first entry I hope you find it interesting and in a small way informative.

With Reference Data we occasionally stumble upon data exceptions that make us investigate the rules which we use every day. I was reminded recently of a “wrinkle” in the use of the Stock Exchange Daily Official Lists identifier (SEDOL) when a Client asked for an alteration to a Position report because the “wrong” SEDOL was being displayed. As I’m sure you’re aware, SEDOL is the instrument identifier assigned by the London Stock Exchange (LSE) and we often think of it as a country level identifier, and why not, the definition provided by the LSE tells us so:

“SEDOL codes are a unique country level identifier issued one per country for place of listing or trade. Each SEDOL is partnered with a Market Identification Code (ISO 10383 MIC) also creating a unique market level identifier.” http://www.londonstockexchange.com/products-and-services/reference-data/sedol-master-file/sedol-master-file.htm

 

The “wrinkle” I have in mind occurs with multi-listed stock in Dublin and London. While the LSE assigns SEDOLs for both Dublin and London we often find only the London SEDOL in use. An example is Irish Continental Group. The LSE allocated 3339455 for the Dublin listing and 3333651 for London.

Yet, when we look on the Irish Stock Exchange (XDUB) we find they’re using the London SEDOL.

Having spoken with the LSE about this they give the following disclaimer:

“The Irish Stock Exchange doesn’t use London codes that are issued now, but you may find that they are using them for existing listings.”

There are other SEDOL “wrinkles” I would like to share over the coming weeks so pop back for more insight, It is always interesting to find these odd conventions, they remind us why when we hear the statement “That’s simple – It’s only Reference Data” we know the Devil is in the data.