Regulatory | Trick Bites Back!

One of our gripes with trading systems is that sometimes they just can’t properly book certain trade types.  Yes, there really are trading systems out there that can’t book Futures.  Yes, there really are systems out there that can’t book spread trades, options and an assortment of exchange products upon which traders have already pulled the trigger.
What do we do if our trading system can’t trade futures?  No problem, we just “trick” the system and book it as a swap. You know, the old “work around.”  Sometimes this turns out OK.  With a little push here and a rub there the P&L

Enjoying work arounds?

all turns out fine.  Fine that is, until someone needs to run a report specific to futures.

Like a Dodd Frank report?  Why yes!

To begin with, if you are in the know, then you know that not only is system tricking done…it’s done a lot.   Every trading company has some work around here or there.   So, remember those futures we couldn’t book as futures so we booked them as swaps?  Looks like Dodd Frank requires us to report our futures as …well …futures.  So now we are going to have to go through every one and figure out which swaps are actually futures and compile them into a report.

This got us thinking that clients will need all trades reported to the CFTC exactly as executed on the exchange.  But as we dug deeper we realized that there is not chance it would be so simple.

Turns out it looks like CFTC can’t book spread trades (as spread trades) either. So that trick we did on spread trades, booking them as swap legs.  Yep, the CFTC wants them that way too.  They don’t want the aggregated spread, just the underlying legs.  Those stellar ETRM systems that have gone the distance and actually book spreads as spreads?  You’re out of luck.  We have to decouple these into their respective swap legs.

Our only suggestion is that if you are holding out on how to do regulatory reporting, it’s a good time to get the ball rolling because there are going to be a lot of twists and turns in this plot.

Dumb Things We Saw Today | Ref Field Constraint

Why the constraint?

We work with A LOT of different systems and run into all kinds of crazy stuff. Feel free to email us your Dumb Things We Saw Today.   Here is another gem:

We were working with a vendor energy trading system and inputting an exchange Order ID into an Order ID Ref field.  Kudos to the vendor for having an Order ID Ref field at all.  But there is a constraint on the field that the OID has to be unique.  If you’ve worked with the exchanges then you know that exchanges only guarantee these numbers are unique for a single trade date.

Opinion | No Strategy is Not a Strategy

We met up with some executives of a large asset based company.  They have a HUGE fleet of delivery vehicles.  When we got on the subject of their fuel use, I asked them what their approach was to hedging.  The answer: no approach.
Build Market DNA

More discussion and it turned out that this was not actually true.  Their hedging approach is to pass all the costs along to their customers in the form of fuel surcharges.  They are traditionally “old school” and hate the idea of “being in the fuel business.”

Fair enough, but it got me thinking about different strategies.  The structure guy in me went immediately to a “participating” structure.  This is simple enough.  You lock in a year’s worth of fuel (Futures/Forwards) at a fixed price.  Let’s say RBOB at 3.00 a gallon.  Then you add on a RBOB put option at, let’s say, 10 cents /gal.  So, the company’s all in price is $3.10.

So, if prices go up?  This company has capped itself with the futures at a fixed price.  If prices go down, the put options come into the money and pay, effectively allowing the company to “participate” in lower prices.  This will contain fuel charges and prevent a spike by keeping delivery constant and low.  More than likely lower than their competitors who have similar no policy policies.

So, should they do it?  Well, there is the real problem here: this company is missing key market DNA. I don’t mean to sound cocky, but I’ll bet a steak that 3/4ths of the company executives cannot come within 10 cents of the current RBOB price.  The DNA just isn’t in place.  Until the DNA is there, things like participating deals are pie in the sky.  Can a company like this build market DNA?  Sure, but nothing is really broken, so the motivation is lacking.  There is so much momentum behind the status quo that I’m doubtful even simple DNA building has legs.  It most likely won’t be until one of their competitors makes the leap that it becomes a big enough problem to solve.

Regulatory | The Case of the Missing Execution Time

Execution time please

Still a ways from final Dodd-Frank Rules.  But we can definitely see how they are shaping up.   One issue that is certain for all companies engaged in trading: Execution Time.   Here’s the issue: We were working with a client using one of the larger ETRM systems.  Trades are brought in through a “Quick Fix” custom set of code from ICE and NYMEX and entered into the ETRM system.  Pretty straightforward.   What we are certain of, based on current Dodd-Frank Rules is that Execution Time, or the time that a transaction was actually executed, is going to be a key parameter in Dodd-Frank reporting.  I’d put it at 99% certainty. So here is the problem.  The client’s Quick Fix connection somehow dumped execution time.  The people who originally developed the solution did not think it was an important criteria and did not code it into the ETRM loading solution.   Second, the target ETRM system did not really have any place to put  Execution Time.   Sure, you can load it into a User Defined Field.  But where we really wanted it was in the Primary Position Table where we could report off of it.   The only thing the ETRM offered was trade input time.  But for Regulatory Reporting this is…as they say….not Kosher. It is worth taking a look at how your exchange solution might be able to feed through Execution Time to your ETRM system or wherever you plan on doing regulatory reporting.

News | BroadPeak Releases Fills Aggregator

BroadPeak Partners today released the first version of its Exchange Fills Aggregation component for K3.

“It’s one of the most irritating problems for trading management.   A trader might put out an order for 100 Lots and get 6 fills.   So what was once a simple trade has now become 6 trades in the ETRM system,” said Gordon Allott, BroadPeak’s President.   “We developed a component for our rules engine that re-aggregates fills before booking into the ETRM system.  As always we are focused on referential integrity so traders have access to both the original fills and the end aggregated trades.”

The development of the Fills Aggregator allows traders to more easily view trades as they posted them as opposed to how they are executed on the market.  Likewise it eliminates the ETRM system from additional calculation overhead, shortening the end of day process.  Aggregation is now a standard component in the K3 F1 Suite.

To view a demo of the Fills Aggregator please email Vivek Pathak.

News | K3 Integrates Seamlessly With Zema

BroadPeak Partners announces K3 can now be used to seamlessly manage price movements from ZEMA, a leading enterprise market data warehouse for energy and commodities.  Trading firms relying on ZEMA for market prices can now leverage K3 to manage the distribution of ZEMA data throughout their enterprise.  This gives firms a single point of control for all downstream interfaces, instant connections to internal applications, and real-time insight into any data transmission failures.

“ZEMA is one of the fastest growing price and market data repositories.  K3’s interface makes it very easy to get this pricing and analytical power to downstream applications where it can be leveraged,” said Vivek Pathak, BroadPeak’s COO.

K3 gives the business instant insight into data that has flowed and alerts them when corrective action is required.  It further gives them a simple interface to function as air traffic controller over the network of data being sent from ZEMA to many downstream systems.  Lastly, it significantly accelerates any ZEMA implementation as interfaces with K3 Server take 30% of the effort of building a single point-to-point interface.

Looking to harness your market data infrastructure or accelerate your ZEMA implementation?  Contact us and we can help.




News | K3 Adds Trayport connection

BroadPeak Partners announces a newly added Trayport connection to K3.  Firms trading European energy and commodity products can now automatically receive Trayport deals into their native trading systems directly using K3.

Trayport allows a single connection to 7 exchanges and 18 brokers operating in the European commodities markets.

K3 allows the enterprise to focus on what it does best, manage internal operations and systems.  K3 retrieves all deals (both exchange and OTC) and then the enterprise focuses on ensuring those deals flow to all the correct systems with the correct reference data.  With K3 there are no more lost deals and ongoing manual adjustments.

K3 is the world’s leading Interface Harness, offering off the shelf connectivity to over 23 exchanges and nearly every major trading system on the market.

Welcome to BroadPeak Think

Welcome to BroadPeak Think.   This is where we provide comments on Architecture, Integration, Industry and whatever else strikes our fancy.

We love feedback.  Feedback is a key piece to our core values, so if something strikes you don’t be bashful about reaching out to us.

Page 10 of 10« First...678910
(877) 738-0470