Dodd Frank  | Trade Vault and DTCC “Gotchas”

The compliance deadlines are looming.   Some of the bigger Gotchas that keep coming up:

Data Is Not In Our Trading System.  The CFTC wants (XYZ Data Point).  We don’t have that in our trading system!

Case in Point:  Option Expiration Time Zone.  Obscure, yes.   So much so I have to say I have never seen this value actually captured in a trading system.

Case in Point: Termination Fee Payer:   Nope, have not seen this one either.

Case in Point:  Execution Time:  Oh sure, we have that in the trading system.  Wait, maybe not.   The trading system only has the execution date, not the execution time.

Missing data is the number one gotcha of SDR reporting.  The solution to this is what we refer to as value mapping to derive values.   If you were coding this from scratch one would have to create a table or a rule.  This is one of the reasons I love K3 Server mapping.   We joke when we demo the system that mapping is soooo boring.   But when it comes time to manage these relationships, we just put them into the mapper and away we go.

Aggregation & Disaggregation.  We’ve talked about this a bit in previous posts.  Sometimes calendar strips are booked as, just that, calendar strips.  And sometimes they are booked as 12 monthly legs.  Sometimes, spreads are booked as just that, spreads.   And sometimes they are booked as legs.  Depending on how the trades are booked and how the SDR wants them, we may have to do some fancy footwork to properly book into the SDR.

If you were coding from the ground up this means you’ve got to create some fancy logic.  For K3 Server it is a simple matter of either sending the trade to our aggregation or disaggregation components; or just use a rule to do the same.  All that fancy footwork is done already in a GUI that any BA can use.

DTCC Trade Vault or Both?  Just about everyone I have talked to is struggling with which SDR they should use.  As of this writing there is only one for commodities (Trade Vault), but I am sure that will change shortly.  So our answer is BOTH.  It’s just a fact that some trades are going to be on DTCC and some on Trade Vault.  We’ve integrated with both and routing is all done internally in K3 by deal type or other criteria.

SEF Deals Not on a SEF (yet).  Yes, SEF’s are supposed to submit trades on your behalf to the SDR.   The problem?  There are no SEFs yet.  There is a pretty good chance that there may be a lengthy period of time where we are executing on a “soon to be SEF” but it is not one yet.   It is worthwhile being cautious and not making assumptions about whether the SEF is going to submit on your behalf.  In the end every reporting entity is going to have to be ready to go to submit trades to the SDR, irrespective of where it was executed.

Changing Rules

All rules will inevitably be changed.  Some trade types may no longer need to be reported and some additional trade types will need to start being reported.  Whatever solution you craft to comply with Dodd-Frank requirements, it has to be agile enough to respond to a dynamic set of requirements.

You could just stick the problem in the lap of some smart developers or consultants and say “Go!” but that generally leads to a short-term solution which costs more and more to maintain as you add capabilities.  Doesn’t seem like an issue now when business groups are throwing endless money behind compliance efforts, but the gravy train will eventually run dry.  And if you haven’t thought up front about managing those interfaces efficiently, your current uptick in spend may paint you in a corner down the line.

This is just the tip of the iceberg.   More to come….