Convene & roll call

Tosha:

• Reviewed FINOS FO website (from last week)

• Announced Members meeting in London at JPM on May 1st.  
• Great opportunity to bring people together and member firms can join & come together.  Showcase FO work & could figure into roadmap and changes to be made to website.
• Demo of financial objects would be great.  
• Members mtg across all FINOS programs.  
• Good time to look at crossover of WG, interaction sessions, please give FINOS ideas of content they’d like to see.

Johan started discussion on feedback of attribute naming conventions

Tony reiterated that some objects model well in public forum but not as well in web based.  

Johan:

Back in the day was involved in Symphony FO/structured objects.  Had similar confusion.

Standards exist but also not used everywhere.  So people still say “wouldn’t it be great if everything was standardized”.  Hears there are problems but also hears there are standards.

Asked Tony what UBS needs to do for a more flexible standard

Tony:

Ion trading system uses fixed as based model but add ons are very well defined and well understood

Kevin:

Client integration perspective - fixed offers good base but hard to come up with standard that works for everyone in every situation.  What are the problems with fixed and correct those rather than try to “boil the ocean”.

Tony:

Agrees only needs a few certain standards.  

Kevin asked: Client facing only?

Will:

What is the package of data attributes needed to transfer back and forth.  Not trying to change fix schema just pull out 4 or 5 essentials. We’re at stage where attributes are define but need use cases.  

Use as mechanism to bring back to this WG

Johan:

Main interest is reference objects which are on front end, desktop, 2 applications on desktop.  Where it is relevant to use the same identifiers there are very clear use case and clear improvement

The functional use case is where line is blurred - tapping into existing standards which makes it more challenging.  Maybe best to define items that make up basic CDS so application can be built and when goes to actual venue, there’s an easy translation mechanism.  Not sure if that’s difficult and valuable but that’s how he’s seen functional objects. Johan opinion is these objects shouldn’t be basis of actual trading.  

Will:

Attributes can be replicated and are common  

Tony:

For OTC he agrees this applies and has concrete use cases.

Will

If interop scenario of taking piece of text and putting into text but would additional attributes be needed to create a ticket?

Tony:

Depends on asset class

Will:

For this object this is about ability to translate workflow, the necessary attributes, the ability to send attributes to inform work flow.  More interop scenario but if take IRS, the idea is that one can take the minimum attributes and enrich them. Idea is to extend the hierarchy and message “payload”.  

Take a number of these objects whether on buyside or sellside

Johan:

Re: Use case for reference objects. If he wanted to transfer simple portfolio today, he’d send excel spreadsheet.   It wouldn’t be hard to figure out but in order for receiver to add into his portfolio, he’s have to reformat the spreadsheet

But a more modern way, he’d paste into Symphony.  But even better, if in Symphony could be in portfolio management system with data blob.  Might have to write new parser but once this is done, exchanging portfolios with same structure is easier.  

Will:

These are being more angled to desktop facilitation, which is much easier.   

How to take subset of those attributes and form object out of that then all is needed is the object.

Johan:

We don’t speak ISIN yet, so sending as object it can use ISIN shows a nice view to the user but using exact identifiers for systems that understand them.

Johan:

When Factset symbologies were added but coders have now said that’s not nice in modern languages (no dots or spaces) in attribute names.  Johan now pushing for change in names. Mao changed to one word on FINOS web page. But we need to standardize & define what characters are used so there won’t be confusion

Tosha:

Currency, would you expect that to be referencing a different standard since they are common standards?

Johan:

Outstanding standardizing currency request on page.   Need currency object in references which has a certain standard.  

Tony:

Currency is usually ISO extended and normally in different fields.  

Johan:

Great example on where loose standard could really help.  Distinguishing the currency for example. Defining it on Properties page. Yes, there are de facto standards that have tiny little differences, but could turn them into use cases in WG, this could be simplified in 5 years.

Will:

Which ones?  We want to build out library of concepts but which can be extended out further? Want to use this forum for wider use cases to start and expand on.  

Tony:

Good starting point take a standard then chop the fields which gets you to simply answer. But has to think about what his traders type into chat window.  Ultimately they need the full representation but traders start with very few fields but that’s where mistakes start to happen.

Johan:

Agrees with Tony idea.  Find something that is causing user or technologies headaches and those basic scenarios and see where FO could help.  This would be good place to start.

Asked Will if Sid & Mario ready to demo RFQ

Will

Sid working through it & will leave to Sid to respond.  Sid working through with members so no update on Symphony side yet.

At object level Mario confirmed he’ll participate.  They’ve been using attributes Will & Hammad put together.  Which is whole point of validation of objects they are parsing through.

• Hammad back next week