Trade Talk Blog

The official blog of Trading Technologies, your source for professional futures trading software.

UPDATE: If you missed our live broadcast of the ADL Hangout, you can view the recording here.

Our first Google Hangout (below) featuring TT’s newest algorithmic trading tool, ADL, was so well received that we’re gearing up to produce another live broadcast on Tuesday, December 18th, at 3:30 p.m. CST.

If you missed our first ADL Hangout, click the “play” button above
 to watch the team build and launch an actual trading strategy with ADL

In our second episode, Product Manager John Yoo and Senior Business Analyst Tom Zagara will build the exit-side logic to the scalper algorithm introduced in the first episode. In doing so, they’ll also cover the Value Extractor Block and the concept of “virtualization”.

To watch the live broadcast, come to our YouTube channel, TradingTechTV, at 3:30 p.m. CST on Tuesday. No registration, login or special software is required. If you can’t watch us live, we’ll post the recording to TradingTechTV shortly after the event has concluded.

UPDATE: If you missed our live webinar with Eris Exchange, you can view the recording here.As announced in September and discussed here on Trade Talk, TT will launch connectivity to Eris Exchange in early 2013.

To help our mutual customers learn more about these new trading opportunities and prepare for the rollout, TT and Eris Exchange will co-host a 30-minute webcast on December 12th at 3:30 p.m. CST/4:30 p.m. EST.


Michael Riddle, Eris Exchange (L) and Jeff Mezger, Trading Technologies (R)

The agenda will include an overview of Eris Exchange Interest Rate Swap (IRS) futures presented by Eris Exchange COO, Michael Riddle, followed by a demonstration of unique Eris-specific X_TRADER functionality by TT Senior Product Manager, Jeff Mezger .

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.

Image via M-Pics/

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.”
      – Unknown

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.