Page 10
Page 11
What Challenges Do Financial
Institutions Face With Reference To
Data Management?
I’m answering this question as someone who
worked on an IT-intensive derivatives trading
desk that, due to its proprietary nature, was
somewhat sequestered from the rest of the bank.
I’m a trader, not an IT guy, and will try and harass
a colleague to give me an answer. Until then, you
have this mess to dig through.
For starters, understand that most banks’ IT sys-
tems are nowhere close to sophisticated enough
to differentiate between master and reference
data. We are the product of decades of M&A ac-
tivity and the technical debt is an impolite topic
to bring up.
Ideal world
Every desk’s book (list of positions and their siz-
es) would be visible to everyone else in the bank
real-time. The instant I put in an order, it would
report across risk, transaction, and strategy en-
gines on my desk and everyone else’s. There
would be a unified counter-party information
so that I’m not trying to sell X something at 30,
while another desk is offering it at 35. It would
also allow senior management to, in real-time,
aggregate counter-party gross, net, and beta
exposure as well as net notional and theoretical
exposure to several factors. We would have an
internal Quora, internal Wikipedia, chat systems
that wouldn’t make 1990 blush, etc.
Really
Let’s take something that you’d imagine would
be relatively streamlined: trade and risk report-
ing.
When I make a proprietary trade, I put the trade
into a blotter that goes to the exchange (if it’s
exchange traded). I then re-type the order into a
system that will report it to our risk books. Note:
every asset type has a different risk book. They all
use different nomenclature and surrogate keys.
At the end of the day, I (manually) tally up my
P&L and risk positions and report it, after round-
ing, to another system. The counter-party does
something similar. When one of them feels en-
lightened and marks a “market maker” order as
“client,” our operations team screams Hail Mary
and we spend the better part of the morning
tracking down the original trade, which may
have been mis-entered across systems. To make
it more exciting, we make sure we’re migrat-
ing from system to system, such that there’s
always—for each system—a legacy system, a
totally different “current system,” and a beta sys-
tem. There will also generally be another sys-
tem that the Russian or Hong Kong or Frankfurt
branch decided to use, in which case everything
will be in a foreign language.
The reference data are managed very much ad
hoc. There are lots of duplicates, lots of surro-
gate keys (why in God’s name AWK803 is the
“country code” for Australia is a few rails of coke
beyond me), the systems are always changing
(ahem...being “maintained”) and generally, the
interface between them is a human being.
For further illustration, the entire risk system
reference database (for relating surrogate keys,
mostly) for a particular asset class was shared
between our desk and another in an Excel file,
on a shared server that was accidentally delet-
ed (and un-deleted) more than once in my time
there. Once, we also stopped someone from a
rival desk from literally walking away with the
physical box“because he really needed a server.”
Steps being taken
Legendary IT lives at Citadel, Renaissance
Technologies, and the former AIG FP: basically,
hedge funds and newer asset management
companies that have grown internally.
Every bank is trying to unify client-facing staff’s
interactions with clients. Unfortunately, this
has manifested as every client-facing group re-
leasing its own client-unification scheme that
everyone else has to use. There are also valiant
attempts at making shitty internal versions of
Facebook.
Problem
Every bank’s system is uniquely structured. Ho-
listic knowledge is not concentrated. Taking
these systems down—however crappy—for
even a few seconds could spell disaster in the
order of billions of dollars.
