The elevator panel in my apartment lobby is slightly unusual. It has up and down arrows, as one would expect, but it also has a third button labeled “Dog Run”. This button often makes visitors momentarily hesitate as they reach for the panel.
|Dog Run Button:
Keep reading if you don’t know what this button does.
Every day, when I look at this elevator panel, it reminds me that even the most trivial features come with costs. The cost of one additional button may not be readily apparent. But imagine an elevator panel that includes dozens, or perhaps hundreds, of specialized buttons. A panel like this might be completely counter-intuitive and maybe even unusable.
Knowing what I know about the dog run button’s purpose, I’m sure that it’s exactly where it needs to be. However, I often wonder about the thought process that went into its design:
- What need was this feature designed to address?
- Was that need worth addressing?
- If so, is this the optimal implementation?
These are the same questions we ask as we strive to innovate ADL
in a way that achieves extraordinary flexibility, yet keeps it slick—both above and below the hood. As the fastest-growing product at TT, ADL has garnered more than 100 enhancement ideas from its users; the innovation that surrounds ADL is truly remarkable.
Below, I’ll shed some light on how we analyze enhancement requests, especially in the context of the three questions mentioned above. My reason for doing this is simple: I want to reassure users that their suggestions don’t disappear into a void. I also want to encourage users to continue to participate in the brainstorm and help us keep the pace of innovation on fire.
The Root Issue
When we visit a doctor, we don’t typically start by handing him or her a list of the prescription drugs we need; the doctor usually makes a diagnosis first.
In the same manner, when a product enhancement is suggested, we don’t usually jump to implementation. Instead, we examine the root issue first.
We typically find that each enhancement request is actually a request for a solution to an issue encountered by the user. An examination often reveals the root issue to be one of the following:
- A defect that needs to be fixed
- A need that the user doesn’t know the product already addresses
- A need that the product doesn’t address
Here’s a real example. During the beta phase of ADL, a user suggested that we introduce the ability to automatically launch an algorithm when the market opens. Upon further interview, we discovered that the user had previously attempted to launch his algo during the pre-open, only to have it pause immediately. As a result, he resorted to manually launching his algo right at the open to gain place-in-queue, and he was looking to automate this manual action.
The root issue here was that all algos were designed to pause during untradable market states (e.g. closed, closing auction, expired, post trading, freeze etc.). What the trader really needed was a way to operate an algo outside of tradable market states. To satisfy this need, we ended up introducing the “Ignore Market State” functionality and the Market State Block.
This was a case where we decided to address the trader’s need. However, that is not always the case – every identified need begs the question: “Is the need worth addressing?”
Scope of the Product
When it comes to determining whether an identified need should fall within the scope of the product, I believe in the “less is more” philosophy. I strive to keep ADL focused on and proficient at its core competencies: market-depth-based analysis and execution.
Some users may conclude that their business needs lie outside of ADL’s scope. I recognize and respect this decision. In fact, I believe focused scope benefits the prospective user; the more focused the product, the easier it is for a user to determine whether or not a product meets his/her needs.
When ADL fits a user’s needs, its focused scope translates into a superior user experience with a product that is highly performant, intuitive and effective.
As ADL matures, we plan to gradually expand the scope to accommodate the usage of technical indicators and fundamental data. However, proficiency will always be prioritized before expansion.
Implementation: Tools, Not Options
Once we determine that a need falls within the scope of the product, we look for a solution.
The core “less is more” principle behind ADL’s implementation is self-evident in the product itself: ADL is a streamlined toolbox of blocks, not a giant collection of checkboxes and drop-down menus.
Look at the image below. I call this the “learning curve vs. flexibility” spectrum. Generally speaking, hard-coded options, such as drop-down menus and checkboxes, lie on the left; they are probably the easiest to use, but also limited in flexibility. APIs are placed on the right; they probably have steep learning curves, but are also very flexible.
|Learning Curve vs. Flexibility
ADL’s implementation is deftly balanced about halfway between. It does not require the user to write code, but it does grant sufficient flexibility to excel at its core competencies.
When this principle is applied, the final implementation may end up looking nothing like the original enhancement request, even if it fully addresses the user’s need.
Back to Dog Run…
To come back to where I started, let me tell you what the dog run button does: it calls elevator car #1, which stops at the second floor, where there is an indoor area for walking dogs. Other cars don’t stop at the second floor.
Applying the principles mentioned above, it seems that this button was a downstream effect of an architectural limitation (apparently only one elevator can stop at the second floor) combined with the residents’ need to use the elevator to reach the second floor (apparently residents can’t or won’t use the stairs). Going further upstream, the root cause seems to be the residents’ need to walk their dogs indoors. I don’t own any pets, but it is my humble opinion that owners should walk their dogs outside in the first place…yes, even during Chicago winters. With that said, the indoor area seems like a superfluous feature that can be removed along with the “Dog Run” button.
While I hope I entertained you with my analysis of the dog run button, I hope even more that you gained an understanding of how your ideas and feedback fuel the processes that drive ADL’s evolution. If you’re an ADL user, I hope I’ve inspired you to contribute (or continue contributing) to the innovation of ADL.
“It’s not a question of enough, pal. It’s a zero-sum game. Somebody
wins, somebody loses. Money itself isn’t lost or made, it’s simply, uh,
transferred from one perception to another. Like magic.”
– Gordon Gekko
The futures markets are generally regarded as a classic example of a zero-sum game. Simply stated, a zero-sum game consists of one winner for every loser. When I play against you, if I win, then by definition you must lose. The net outcome of our efforts is zero.
Participants in a financial zero-sum game transfer money only amongst themselves as they win or lose. Winning traders do not increase the total pool of available funds, they obtain their winnings from the losing traders. Some pundits who label futures markets as zero sum also claim that futures differ from equity markets because in the futures markets, no new wealth is created.
Personally, I feel the zero-sum depiction incorrectly casts futures trading in an unfavorable light. To me, it portrays futures markets as providing little or no useful economic benefit, and instead as just a collection of private high-stakes games for greedy speculators.
By design, a single futures transaction matches the opposing views of one buyer and one seller. And yes, the net proceeds of completed trades do indeed impact the participants as the profits (and losses) are marked to market and ultimately transferred to their respective accounts. So in that respect, I do agree that an individual futures trade in and of itself is a zero sum.
Much More Than a Single Transaction
“The truth is more important than the facts.”
– Frank Lloyd Wright
Where I disagree with those who label futures trading as zero sum is the common disregard for the distinct economic benefits that occur due to the activity of futures buyers and futures sellers. Here’s a quick list of examples describing how their actions do indeed add value and positively impact the overall economy.
First, the fundamental reason why futures markets exist is to efficiently facilitate risk transfer from producers to speculators. This function provides a real economic benefit to effectively manage a business against uncertain variables, such as weather and economic changes. Imagine a world without futures markets for a second…how much would a gallon of gas have cost the day after Saddam Hussein set the Iraq oil fields on fire? Without the futures markets, producers would need to build those types of future uncertainty into their current-day prices.
Volatility is a popular buzzword these days. Futures markets
take the unmanaged, uncontrolled volatility that exists in the real world and
bring it into a controlled, regulated environment. This important role of futures markets is often overlooked and/or misunderstood by casual observers.
Second, the price discovery process provided by freely traded markets constantly assimilates all available information to produce the best possible assessment of current value. Not only are price levels established for today’s date, but the breadth of available futures contracts forecast prices for months and even years in advance. Name another method that can better predict a future interest rate or the prices of specific global commodities several years from now.
Third, the one buyer/one seller transaction—where I win and you lose—does not occur without a great deal of associated enabling capabilities. Someone looking to consummate a transaction equivalent to the purchase of a futures contract does not privately locate a seller on their own, negotiate the price and terms and conduct the trade. An extensive fabric of supporting functions has been developed to facilitate the ability for that trade to even occur. Futures trading has evolved far beyond the necessary standardized contract terms and centralized order matching and clearing. Data center facility providers, telecommunications lines and equipment makers, computer hardware providers and software vendors have all invested time, effort and capital in an extremely competitive quest to better facilitate electronic futures trading. Not only do the futures buyer and seller benefit from these efforts, but the providers themselves (including their employees and shareholders) benefit according to the success of their contributions.
Innovation and Ingenuity Add Value
Lastly, the potential financial reward inherent in futures trading ensures a continuous stream of new ideas from traders looking to identify and capitalize on profitable trading opportunities. In parallel, the efforts by others focused on creating new markets and contracts, along with developing more efficient means to submit, match and process transactions, all work to add value and help increase trading volumes.
When new ideas and innovation move from thought to reality, the contributions benefit more than the originators. The entire market grows and prospers, becoming larger and stronger from these new additions. Human ingenuity can indeed create new wealth.
I suppose that you could argue that the examples I’ve described encompass more than “futures trading” and should more correctly be associated with the “futures industry”. But even so, to me it is clear that a strong, vibrant futures industry provides numerous benefits beyond the individual recipients of each winning trade. Not to try to spin a pun, but while some say zero sum, I say the futures industry provides something much more.
Thanks for reading.
Just a Little History
“Who am I? Why am I here?”
– Vice Admiral James Stockdale
A “multibroker solution” can be broadly defined as a trading platform that provides the buy side with the ability to execute and clear with multiple brokers, preferably from a single screen.Over the years, there have been many reasons for TT to offer a multibroker solution. The beginning of the 21st century was a boom time for commodities and futures markets. During that period, the biggest challenge for a trader seemed to be how to capture a piece of the ever-growing pie, in an environment where trade volumes would go up for the foreseeable future. Even the occasional bump in the road
didn’t seem to slow anyone down for long. The more relationships you had, the wider you could reach to gather in the bounty.
But it was by no means an easy road. The barriers to multiple broker relationships were many:
- Some brokers could be accessed only via their proprietary single-broker offerings.
- Multi-asset, multibroker platforms lacked advanced futures trading functionality.
- Software vendors (like TT) had solutions that were “broker-neutral”, but still required separate infrastructure for each broker.
- Each broker presented unique back- and middle-office integration overhead, especially with regard to Financial Information eXchange (FIX) protocol integration.
In spite of the costs and complexity, those firms with enough resources to apply to the problem simply forged ahead with handcrafted multiple-broker integration, sometimes supporting separate software solutions for as many as half a dozen different futures commission merchants (FCMs). When it came to the multiple broker club, many small or even mid-tier buy-side firms were left on the outside looking in.
Over the years, TT has done a fair amount of talking about a multibroker solution. We made a couple abortive attempts at trying to bolt-on multibroker functionality to our existing system. But for the most part, TT focused its R&D resources on expanding trader functionality and market access. Our 7x platform was solid and time-tested. In most cases, FCMs managed their TT infrastructures with only occasional guidance from TT. Yes, TT dipped its proverbial toe in the hosted-solution water with TTNET™. But TTNET only aspired to provide the same type of TT infrastructure management that most FCMs were already doing–basically a competent but cookie-cutter approach, with a few efficiencies gained due to shared infrastructure, best practices and proximity to TT support. Not much progress was being made on the multibroker front at TT.
Then in 2008, the unforeseeable happened.
Consolidation, Consolidation, Consolidation
“There are only three things that matter when it comes to property: location, location, location.”
The events of the 2008 crash are well known; we won’t review them here. From our perspective, the crash brought a number of critical issues to the forefront:
- Broker risk: Anyone with just a single broker relationship now wanted two; those with two now wanted three, etc. On the other hand, those with six might cut back to five, or even four. It’s no longer just about maximizing profits, but insuring survival.
- Regulatory risk: As an industry, we’re still coming to grips with the impact of Dodd-Frank and ESMA regulatory changes. The demands that these changes are placing on FCMs and the buy side are a driving factor in system consolidation.
- Opportunity risk: Near-zero interest rates and reduced trade volumes mean FCMs are keeping a much tighter rein on which buy side firms are worth the cost and effort to support on a trading system.
At TT, we continued to talk with our end users about these issues. Internally, we had many debates and brainstorming sessions about how to attack various pieces of the new puzzle. About two years ago, the case for a multibroker application service provider (ASP) solution at TT became so compelling–seeming to solve so many of the disparate problems with which our end users were being faced–that we stopped trying, and started doing (apologies to Yoda): we decided to transform our current single-bank platform into a multibroker architecture, starting from the bottom up. So let’s talk about what TT’s multibroker solution is.
What is the New TT MultiBroker Solution?
“It’s a little room in the front of the plane…but that’s not important right now.”
– Leslie Nielsen
Aptly enough, we’ve named our solution MultiBroker. We started by taking a new approach in TTNET, introducing an ASP model for MultiBroker that allows TT to fully manage and scale the trading infrastructure as trade volumes dictate. We are starting to take advantage of cloud resources
to help scale the less latency-sensitive components of the system. We believe that an ASP approach will help us take any barriers to entry for our MultiBroker end users down to the bare minimum.Under the software covers, we made precise changes from end to end in every TT component to accommodate the order-routing demands of MultiBroker, while at the same time matching or exceeding the performance and feature set of our existing platform. Buy-side firms will be able to integrate with a single FIX interface across all brokers for back-office and compliance reporting. We kept the visible changes in X_TRADER® and the APIs to a minimum to keep the learning curve low for our current traders and to retain the clean and fast trading style for which TT is so well known.
We are pretty proud of the end result. The MultiBroker solution has been routing live trades in our alpha environment since late summer. Early reviews from both the buy side and the sell side have been enthusiastic, and I am equally enthusiastic. As we move on to beta and ultimately to production in the coming months, you can track progress on our MuiltiBroker initiatives webpage, or in my future blog posts.
|Image via Renjith Krishnan/FreeDigitalPhotos.net
As someone who has been at TT for more than just a couple of years, I have seen various CTOs and product managers come and go. One common trend was always this: in the world of limited engineering resources and competing priorities, risk management features would typically take a back seat to the high-performance demands of the end user who was routing orders on TT’s platform. Historically, I guess that made some sense. At the end of the day, screen sales drove the business, and screen sales weren’t driven by the demands of the risk administrator.
TT Must Change with the Times
Only recently has the product management responsibility for risk and administration at TT become my own. So, now it’s my job to give the risk administrator a voice. Call it fate or bad luck (depending on the day), but this responsibility happened to coincide with some major risk management blow-ups resulting in quite a bit of regulatory reform. This, in turn, has resulted in rising compliance concerns and a major overhaul of how FCMs view risk management. So, the role I’m performing now looks very different than it would have five years ago at TT.
The conversation between TT and its customers has gone from common questions like these:
- Does your system do pre-trade risk checking per user?
- Can fat-finger limits be configured?
- Can I configure a daily loss limit?
- I’m concerned about high-frequency trading algorithms; how do I prevent a trader from flooding the market with orders?
- I have my own sophisticated system for evaluating risk exposure; how do I use that system to programmatically shut off trading at the user, account or account group level on your platform?
- We have a customer that hosts their own TT trading environment on their own servers; how can we ensure that we have exclusive risk management control over that trading environment?
So, What Has Changed?
There are some very real risk and compliance concerns that did not exist before—or if they existed, they have since been amplified. Proper risk management practices are more critical than ever.
What Else is Different?
For starters, TT has taken notice. What was once an afterthought has now become a major driver for us. We understand the importance of having multiple types and levels of risk control on our platform. Implementing these on our existing and next-generation platforms is something that sits atop our priority list. Risk management has found its voice and its place at TT.
Risk and Regulatory Challenges Faced by Large FCMs
As I meet with some of the larger FCMs who currently provide TT’s software to clients, I hear many of the same stories. Mainly, that TT is just one of many vendors that they offer. Managing risk across all platforms is a challenge, and they’ll gladly take any opportunity they can to consolidate the number of systems they have.
For us, the message is clear. We must make our software more flexible and easy to integrate with the FCMs’ existing risk management systems. They are looking for API functionality to get data in and out of TT’s platform. Pre-trade risk checking on TT isn’t valuable if it isn’t encompassing trades that are happening on other systems or on the floor. Because TT is just one of several systems, real risk management is happening outside of TT’s platform, often in the FCMs’ proprietary systems.
So, What is the Role of the Vendor?
Our response to this is to build flexible API functionality that provides a means for integrating TT’s software into other systems and processes. We’re doing that with products like TT API, and a brand new TT User Setup Risk API. And, when necessary, we must evolve our risk management features. We just launched, among other things, order throughput limits on our gateways, and we’re in the process of introducing new account and account group-based risk checking features into a platform that has historically been trader-based. Meanwhile, we will continue to develop new and compelling products, such as ADL™, to provide end users with advanced trading solutions.
Challenging times? Yes. But, for me, it creates an exciting opportunity to work closely with our clients to meet their changing needs. We either become flexible and adapt, or we must be replaced. If we can’t help to minimize their risks, then our trading features won’t matter. As of late, I’ve been inspired by the ability of our engineers to build platform-wide solutions into our current trading architecture. Look for more on this in future blog posts.
UPDATE: If you missed our live broadcast of the ADL Hangout, you can view the recording on our YouTube channel, TradingTechTV.
We recently started moving our corporate IT infrastructure to Google’s enterprise solution. It’s a big change, but I’m really excited about this from a marketing perspective because Google offers some pretty amazing collaboration tools. One of these is Google Hangouts on Air.
This Thursday, November 8th, at 3:30 p.m. CT, we will stream our first Hangout. Our broadcast won’t be formal or scripted, with fancy graphics or an elaborate set. In fact, it won’t even be tied to TT’s official corporate YouTube channel, which will launch soon. But we see incredible potential for Hangouts as a way to talk about our products and engage our users, so we’re going to dive in and experiment.
Our debut broadcast will feature Product Manager John Yoo and Senior Business Analyst Tom Zagara. They will present TT’s newest algorithmic trading tool, ADL
. While you watch, they will also build and launch an actual trading strategy—live—using ADL.
To access our Hangout, just come to John’s YouTube channel at 3:30 p.m. CT on Thursday. Our broadcast will automatically play. No registration, login or special software is required. Note Chrome and Internet Explorer are supported, but Firefox may not be compatible. If you can’t make it for the live broadcast, you’ll be able to access a recording on John’s YouTube channel after the event concludes.
Hope you can “hangout” with us.