|
|
|
|
Main
Page by Topic |
||
|
C. Statistics |
||
Reporting
Some thoughts
and considerations on the topic of Reports/Reporting and Extracts for CTRM
system.
1) ‘Reports’
versus ‘Extracts’
Reports:
Target end users, i.e., human readers.
Extracts:
Target some downstream system or other process.
So the
difference, as defined, is more about intended usage (of the report/extract)
and not how is it created and/or the format (if it is an output file).
For example, a
‘Report’ could be created as a CSV (Comma Separated Value) file, same as an ‘Extract’,
where the only difference is the usage. E.g.,
a user could open the ‘Report’ in Excel (Excel can read in CSV files) to look
at the data/the values.
A file
generated could serve both as a ‘Report’ (human readable) as well as an ‘Extract’.
In addition to
the above, a Report will often be formatted, i.e., contain additional formatting
for a human reader, such as bold font for some text and/or a logo added.
2) Report Output
Formats
Reports can be
generated as
2.1) TXT – Text
files with some minimal formatting like tabbed/spaced columns
2.2) CSV –
Comma separated values. This is also a
text based file. This would not support
formatting like bold/italic or logos, but values could be formatted, e.g., a
number as $1,000 instead of 1000. CSV files
can be opened in Excel.
2.3) Native
Excel format
2.4) PDF –
Portable Document Format from Adobe. The
advantages of this format is that the report is read-only by nature and you can
add logos and other cosmetic (pretty) feature.
Keep in mind
that a report can be generated into multiple output formats and that one ‘report’
may produce multiple files, e.g., one file per ‘Portfolio’ (a.k.a., Trade
Book).
3) Extract
Output Formats
Since extracts
are intended for non-human consumption, these can be in a format that a human
would find it difficult to understand like XML.
3.1) XML –XML format
with tags.
3.2) JSON –
Javascript Object Notation. This seems
to be replacing XML format as the most popular approach.
3.3) CSV - Comma
separated values. This is likely the most
common format for extracts
3.4) Writing
to a database, e.g., relational tables.
4) Intraday
versus EOD (End-of-Day) reporting
4.1) CTRM
systems will, almost universally, create a set of ‘official’ EOD reports for
things like MTM (Mark to Market), PnL (Profit/Loss) and Positions (both
Physical Positions and Market Risk Positions).
These reports would be one per day, so if you have been running your
CTRM system for a year, you might have about 265 copies of a report, each for a
different business day. There being
about 265 business days in a year.
An EOD report
will often have the date in the file name, i.e., the Run Date of the report
(indicating the day it was run on), such that new reports for new days do not
overwrite the prior day’s versions. As
an alternate, the reports could be output to a new Directory (Windows file
system) where the date is in the Directory name. Or sometimes reports do both.
4.2) For intraday
reporting, a new version of the report will usually overwrite the prior
version, since traders and other user of the CTRM system just need the latest
values without necessarily needing a history.
For intraday reporting,
often times the ‘Report’ will not even get output anywhere (i.e., not written
to a file) and, instead, just be viewed within a CTRM system. i.e., would be transient versus an EOD report
being ‘permanent’.
5) Report versus
Raw Data
5.1) Many CTRM
systems will create raw/source data that then will get pivoted into a
report. E.g., a PnL (profit/loss) report
might have raw data of
a) Deal number
(a.k.a., Trade number)
b) Portfolio
of the Trade (a.k.a., Trade Book)
c) Trade Type
d) Trade Date
e)
Market/index of the trade, e.g., NYMEX Natural Gas
f) Trader
g) Some other
trade attributes, potentially.
And then
values like
h) ‘Prior Day
MTM’ (mark to Market)
i) ‘Today MTM’
(mark to Market)
j) PnL (profit/loss,
i.e., change in MTM from one day to the next).
Introduction to
CTRM
Click on this
link for a great introduction to CTRM software: Introduction to CTRM Software