Financial Objects Light

This a suggestion of a middle-ground between todays cashtags (rendered natively in Symphony) and the Financial Ojects (rendered in an iframe by external applications) to solve the immediate need in the community - being able to discuss and link to a specific identifier (eg a company or a bond) when the participants are using different apps, ticker universes and market data providers.

Cashtags

These are very easy to use but they are just text without any universe lookup. V1.44 will introduce a common tag lookup but will not solve the underlying issue and we can already today see that – outside of American tickers – it difficult to find one cashtag that works in all of the currently published apps. I have also heard about teams defining a universe - eg $XXX to mean this – and also building inhouse apps and setting up signals based on this.

You can send a message with a cashtag via the REST API like this:

<messageML>I am buying <cash tag="AAPL"/> for $100</messageML>

and it will be rendered as a cashtag in Symphony and a hover card is shown so that you can navigate to desired app or create/add Signals.

Financial Object + Renderers 

Current functionality allows us to send a structured object rather than the cashtag and also provide users with a renderer to display the object.

The above message could then be something like:

<messageML>I am buying <entity type="org.symphonyoss.fin.security" version="1.0"><attribute name="id" type="org.symphonyoss.fin.security.id.ticker" priority="1" value="AAPL-US"><attribute name="id" type="org.symphonyoss.fin.security.id.isin" priority="2" value="US0378331005"><presentationML>AAPL</presentationML></entity> for $100!</messageML>

This has many interesting possibilities and can be much more complex than the above. However, for the basic scenario the benefit is that you can include several attributes for various types of identifiers (sedol, cusip, etc) but you also lose much of the functionality of the cashtag. Some issues:

1. The recipient must have a renderer otherwise the functionality is less appealing than the cashtag – you get line breaks in the presentation, plain text presentation and no hover card.
2. Even with a renderer, you lose the hover card and thus the interaction with other Symphony Apps and Signals.
3. If the renderer fails, the recipient might not see the company at all.
4. As the sender you actually don’t know what the recipient is seeing.

Native Rendering of basic Financial Ojects

I would suggest we come up with a solution and structure that the LLC would consider for native rending similar to – or as a replacement for – cashtags.

Something like:

<entity type="org.symphonyoss.fin.security" version="1.0">
	<attribute name="id" type="org.symphonyoss.fin.security.id.ticker" priority="1" value="AAPL-US">
	<attribute name="id" type="org.symphonyoss.fin.security.id.isin" priority="2" value="US0378331005">
	<presentationML>AAPL</presentationML>
</entity>

Symphony would render this showing only $ + presentationML but behind the scenes the entire object can be used when sending to other applications. The generic example with Apple could therefore be posted as:

<messageML>I am buying <entity type="org.symphonyoss.fin.security" version="1.0"><attribute name="id" type="org.symphonyoss.fin.security.id.ticker" priority="1" value="AAPL-US"><attribute name="id" type="org.symphonyoss.fin.security.id.isin" priority="2" value="US0378331005"><presentationML>AAPL</presentationML></entity> for $100!</messageML>

This would allow the following:

1. Maintained functionality as per cashtags (inline rendering, hover card, signals).
2. Sender being more confident about the recipient’s view.
3. Speed as custom renders can be sluggish.
4. Possibilities to include several attributes for the identifier.
5. Maintained possibilities for custom enrichers.
6. The entire object should be passed along to the Apps so that they can pick the identifier attribute of choice.
7. Current input mechanism can be maintained – eg $AAPL creates the above “org.symphonyoss.cashtag” entity.
8. Market data firms and clients would be interested in providing composers – that could replace the cashtag type-ahead with custom lookups that would create a “org.symphonyoss.cashtag” entity with as many identifier attributes as they can provide.
9. Get the community working asap with a more defined and controllable identifier universe.
10. Lower the threshold for getting into the possibility and future of financial objects.

I think now is the time and that this would provide a good solution – easy enough for new users/firms and powerful enough for users/firms that are considering trading over Symphony. This without derailing the functionality and possibilities with Financial Objects.