|
|
|
|
Main
Page by Topic |
||
|
C. Statistics |
||
How
to Think Like a CTRM Vendor
This page offers insights into what things
you would consider when designing a CTRM from the point of view of a CTRM
vendor and what things you would think about.
And then invites you to think about what
sort of designs and the software landscape would look like in a system designed
by CTRM users and for the best
interest of those users and market participants.
A more user-centric approach to things would
likely include open standards, though not necessarily Open Source, with regards
to designs and, especially, interfaces between modules.
Though
Experiment – Imagine This…
Part 1: Point Of
View: Legacy CTRM Vendor
As a thought experiment:
1) How would you design solutions from the
point of view of a typical CTRM vendor?
1.1) First…you would be very concerned with your intellectual property. So you would keep things hidden/opaque.
1.2) Next… you would be well aware,
constantly in your mind, of the tendency of software to drop down to the cost
of production. Which for software is practically zero,
since is it so each to just make another copy of softeware.
Think about what tricks and techniques you
would use to prevent the commoditization, pun intended, of your offering.
1.3) Lastly… think about what you would do
to make your software
‘sticky’. ‘Sticky’ is the term
used to describe a product or software that is hard for people to switch
off. You would want firms to use your
one Big Software product for ‘everything’, from trade capture and risk
management to confirms, invoices, accounting, etc. That would make it hardest to switch vendors.
In summary, a typical CTRM vendor will
employ strategies and techniques to benefit themselves
and, especially, to keep their pricing power and their existing clients paying
the annual software maintenance.
Part 2: Point Of
View: What CTRM User/Market Participants Want
Next up in the Thought Experiment:
2) How would you design a CTRM Ecosystem for the benefit of
the users/participants?
2.1) Would much of the software would be open standards, though not necessarily open source? And if you argue that one firm may not have
incentive to do this, then consider what benefits there would be if several
firms grouped together, a cooperative or consortium approach?
2.2) There would be competition for key features. E.g., if you as a firm just had the ‘Trading’
part… i.e., deal entry screens, feeds from the exchanges, and a database to
store the trades… imagine if you, as a firm, were able to choose from multiple
vendors for a ‘Risk as a Service’ type offering. That could be fully on the Web as a Web
Service, e.g., you send your trade data and get back reports and online viewing
or similar functionality could be delivered as software you install locally
onsite or in your own private cloud.
With open standards for communicating
between modules, e.g., trading and risk or trading and scheduling, competition
would drive the prices down and drive the race for new features and enhanced
ease of use.
Introduction to
CTRM
Click on this
link for a great introduction to CTRM software: Introduction to CTRM Software