From montgomery.conner at gmail.com Fri Dec 1 15:57:17 2006 From: montgomery.conner at gmail.com (Montgomery Conner) Date: Fri, 1 Dec 2006 17:57:17 -0600 Subject: [Banking-pm] FIX: Financial Information eXchange Message-ID: Hello, New to the list... nice plug in the Perl Review! Anyway, does anyone know of any existing modular Perl implementations of the FIX messaging protocol or the associated FIXML markup? I need to monitor some FIX communications with Perl and I'd like to avoid reinventing the wheel. If anyone has any experience with this and could offer some insight it would be much appreciated. Thanks, Montgomery -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.pm.org/pipermail/banking-pm/attachments/20061201/3f8bda77/attachment.html From alex at owal.co.uk Sat Dec 2 02:49:12 2006 From: alex at owal.co.uk (Alex McLintock) Date: Sat, 02 Dec 2006 10:49:12 +0000 Subject: [Banking-pm] FIX: Financial Information eXchange In-Reply-To: References: Message-ID: <45715A28.7050809@owal.co.uk> > Anyway, does anyone know of any existing modular Perl implementations of the FIX messaging protocol or the associated FIXML markup? I would have assumed that FIX is so large that any generic implementation of it is likely to be incomplete. Is it not just an XML format where you can create your own SAX handlers when specific messages come through that you are interested in? > I need to monitor some FIX communications with Perl and I'd like to avoid reinventing the wheel. Aha - you need to monitor it - so presumably you need everything.... Hmmmm. Do you need to actually understand the entire FIX protocol? Can you not just say "I have received this type of message" and leave it at that? Alex From BHolzman at iseoptions.com Sat Dec 2 07:51:18 2006 From: BHolzman at iseoptions.com (Holzman, Benjamin) Date: Sat, 2 Dec 2006 10:51:18 -0500 Subject: [Banking-pm] FIX: Financial Information eXchange In-Reply-To: <45715A28.7050809@owal.co.uk> Message-ID: <4ECB163CF3B2C54E869D6392B0D4DDDA06D238@CRPA-MB01-V.office.iseoptions.com> > I would have assumed that FIX is so large that any generic > implementation of it is likely to be incomplete. Yes and no, I think. My experience with FIX has been that the application-level messages tend to be domain-specific, but the protocol-level is quite stable. I have built FIX interfaces to allow order entry and market data for our parimutuel matching engine. I did it using the quickfix open source FIX engine (actually C++ libraries) to handle the protocol and wrote a minimal C++ bridge that shuttles FIX application messages back and forth to a perl process over a socket. I then parse the FIX messages in perl with a custom FixMessage base class, run all of my application logic there, creating FixMessage objects as responses and then turn them back into a string to send back to the C++ bridge. I store the FIX messages as a hash mapping the fix tag number to the value. I then have accessor methods named after the mnemonic for each tag number. I actually just have a hash (%tagMapping) in my base class with the mapping and use an AUTOLOAD to create the accessors on demand. Parsing the FIX message is as simple as this code: sub fromString { my $string = shift; my($class, %tags); foreach my $field (split /\001/, $string) { my($tag, $value) = split /=/, $field, 2; if ($tag == $tagMapping{'MsgType'}) { $class = $msgType_2_class{$value}; next; } next if defined $isHeaderTag{$tag}; $tags{$tag} = $value; } return $class->new(\%tags); } I have sub-classes of FixMessage for each MsgType that I handle; the %msgType_2_class hash has the mapping. Actually, there's an additional complication to handle repeating groups; the value of a repeating group is an array ref with one element for each instance of the group; because tag order in repeating groups matters, each instance is represented with an array consisting of tag number/value pairs. Something like this: [ [ 42 => 'value', 165 => 'another value' ], [ 42 => 'value2', 165 => 'yet another' ], ... ]. So my actual fromString function has more logic to handle this. Anyway, converting an object back to a string isn't too hard; the only tricky parts are including the body length in the header and computing the checksum for the trailer. My code looks like this: sub toString { my $this = shift; my $header = "8=FIX.4.4\0019="; my $body = join("\001", "35=$class_2_msgType{ref $this}", map _toString($_, $this->{$_}), keys %$this) . "\001"; my $msg = $header . length($body) . "\001$body"; my $cksum = 0; $cksum += ord($_) for split //, $msg; $cksum = sprintf "%03d", $cksum %256; return $msg . "10=$cksum\001"; } sub _toString { my($key, $value) = @_; if (ref $value eq 'ARRAY') { return unless @$value; return join "\001", "$key=" . @$value, map { my $val = $_; my @data; for (my $i = 0; $i < $#$val; $i+=2) { push @data, "$tagMapping{$val->[$i]}=" . $val->[$i + 1]; } @data; } @$value; } elsif ($value ne '') { return "$key=$value"; } else { return; } } That's pretty much my whole FIX message base class. The constructor allows objects to be constructed from a string or from tag mnemonic => value pairs. I don't know if this helps you, but at least you see how simple it is to handle parsing and generation of FIX messages. Benjamin Holzman From montgomery.conner at gmail.com Sat Dec 2 20:21:02 2006 From: montgomery.conner at gmail.com (Montgomery Conner) Date: Sat, 2 Dec 2006 22:21:02 -0600 Subject: [Banking-pm] FIX: Financial Information eXchange In-Reply-To: <4ECB163CF3B2C54E869D6392B0D4DDDA06D238@CRPA-MB01-V.office.iseoptions.com> References: <45715A28.7050809@owal.co.uk> <4ECB163CF3B2C54E869D6392B0D4DDDA06D238@CRPA-MB01-V.office.iseoptions.com> Message-ID: Thank you for you very complete response! A few questions... There's been a lot of talk at my job about using FIX to standardize the application infrastructure (logging, some kinds of IPC, etc. ), in which case many of these tags would likely be in the range of FIX tags that are reserved for vendor communications and are thus undocumented/undefined. For a case such as this, in your experience, is there any simple (yet robust) way respond to tags that have not been encountered before? That is, do you think that such a parser might need a more complete grammar specification than a simple hash, or is FIX itself simple enough that certain default responses could be engineered for ranges of tags regardless of whether they already resided in a local specification hash? Thanks again, your insight has been very helpful, Montgomery On 12/2/06, Holzman, Benjamin wrote: > > > I would have assumed that FIX is so large that any generic > > implementation of it is likely to be incomplete. > > Yes and no, I think. My experience with FIX has been that the > application-level messages tend to be domain-specific, but the > protocol-level is quite stable. I have built FIX interfaces to allow > order entry and market data for our parimutuel matching engine. I did > it using the quickfix open source FIX engine (actually C++ libraries) to > handle the protocol and wrote a minimal C++ bridge that shuttles FIX > application messages back and forth to a perl process over a socket. > > I then parse the FIX messages in perl with a custom FixMessage base > class, run all of my application logic there, creating FixMessage > objects as responses and then turn them back into a string to send back > to the C++ bridge. I store the FIX messages as a hash mapping the fix > tag number to the value. I then have accessor methods named after the > mnemonic for each tag number. I actually just have a hash (%tagMapping) > in my base class with the mapping and use an AUTOLOAD to create the > accessors on demand. Parsing the FIX message is as simple as this code: > > > sub fromString { > my $string = shift; > > my($class, %tags); > foreach my $field (split /\001/, $string) { > my($tag, $value) = split /=/, $field, 2; > if ($tag == $tagMapping{'MsgType'}) { > $class = $msgType_2_class{$value}; > next; > } > > next if defined $isHeaderTag{$tag}; > > $tags{$tag} = $value; > } > > return $class->new(\%tags); > } > > I have sub-classes of FixMessage for each MsgType that I handle; the > %msgType_2_class hash has the mapping. > > Actually, there's an additional complication to handle repeating groups; > the value of a repeating group is an array ref with one element for each > instance of the group; because tag order in repeating groups matters, > each instance is represented with an array consisting of tag > number/value pairs. Something like this: [ [ 42 => 'value', 165 => > 'another value' ], [ 42 => 'value2', 165 => 'yet another' ], ... ]. So > my actual fromString function has more logic to handle this. > > Anyway, converting an object back to a string isn't too hard; the only > tricky parts are including the body length in the header and computing > the checksum for the trailer. My code looks like this: > > sub toString { > my $this = shift; > > my $header = "8=FIX.4.4\0019="; > my $body = join("\001", "35=$class_2_msgType{ref $this}", > map _toString($_, $this->{$_}), keys %$this) . > "\001"; > > my $msg = $header . length($body) . "\001$body"; > > my $cksum = 0; > $cksum += ord($_) for split //, $msg; > > $cksum = sprintf "%03d", $cksum %256; > > return $msg . "10=$cksum\001"; > } > > sub _toString { > my($key, $value) = @_; > if (ref $value eq 'ARRAY') { > return unless @$value; > > return join "\001", > "$key=" . @$value, > map { my $val = $_; > my @data; > for (my $i = 0; $i < $#$val; $i+=2) { > push @data, "$tagMapping{$val->[$i]}=" > . > $val->[$i + 1]; > } > @data; > } @$value; > } elsif ($value ne '') { > return "$key=$value"; > } else { > return; > } > } > > That's pretty much my whole FIX message base class. The constructor > allows objects to be constructed from a string or from tag mnemonic => > value pairs. > > I don't know if this helps you, but at least you see how simple it is to > handle parsing and generation of FIX messages. > > Benjamin Holzman > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.pm.org/pipermail/banking-pm/attachments/20061202/94a82f80/attachment.html From BHolzman at iseoptions.com Sun Dec 3 09:44:29 2006 From: BHolzman at iseoptions.com (Holzman, Benjamin) Date: Sun, 3 Dec 2006 12:44:29 -0500 Subject: [Banking-pm] FIX: Financial Information eXchange References: <45715A28.7050809@owal.co.uk><4ECB163CF3B2C54E869D6392B0D4DDDA06D238@CRPA-MB01-V.office.iseoptions.com> Message-ID: <4ECB163CF3B2C54E869D6392B0D4DDDA309DB7@CRPA-MB01-V.office.iseoptions.com> You're welcome! I have to say that I don't quite understand why you'd want to use FIX for logging or IPC. The protocol layer of FIX has some pretty complicated retransmission logic and although it's not as bad as XML, it's not a very compact format. Recovering from a sequence number mismatch between the two sides of a FIX connection can be a real headache. However, to answer your other questions, it is possible to deal with arbitrary FIX messages, but not if they have repeating groups. It would be very painful to try to encode all your data without using repeating groups, so I don't think that helps you. The syntax of FIX is really fairly simplistic. It's either a simple tag => value or it's a repeating group. Repeating groups can be nested, although the code I pasted below won't quite handle this case. Repeating groups always have a starting tag that represents the count of elements in the group. Confusingly, the FIX documentation always uses the prefix "No" for number in the mnemonic (e.g., NoCounterParties, which means "number of counter parties", not that there are no counter parties). Anyway, following the starting tag, there's the contents of the repeating group, one instance after another, as tag => value pairs (or nested repeating groups). Without telling the parser which tags start repeating groups, and what the contents of the repeating group will be, there can be parsing ambiguities. Note, also, the verbosity here; every tag gets duplicated for every instance of a repeating group. I know the FIX protocol organization has been working on something called FAST (FIX Adapted for Streaming) that would resolve some of these issues, but I think it's still in the proof-of-concept phase. Anyway, under that model, you would certainly need to describe your message structure in detail to both sides of the connection. Hope that helps... Ben ________________________________ From: Montgomery Conner [mailto:montgomery.conner at gmail.com] Sent: Sat 12/2/2006 11:21 PM To: Holzman, Benjamin Cc: banking-pm at pm.org Subject: Re: [Banking-pm] FIX: Financial Information eXchange Thank you for you very complete response! A few questions... There's been a lot of talk at my job about using FIX to standardize the application infrastructure (logging, some kinds of IPC, etc. ), in which case many of these tags would likely be in the range of FIX tags that are reserved for vendor communications and are thus undocumented/undefined. For a case such as this, in your experience, is there any simple (yet robust) way respond to tags that have not been encountered before? That is, do you think that such a parser might need a more complete grammar specification than a simple hash, or is FIX itself simple enough that certain default responses could be engineered for ranges of tags regardless of whether they already resided in a local specification hash? Thanks again, your insight has been very helpful, Montgomery On 12/2/06, Holzman, Benjamin < BHolzman at iseoptions.com > wrote: > I would have assumed that FIX is so large that any generic > implementation of it is likely to be incomplete. Yes and no, I think. My experience with FIX has been that the application-level messages tend to be domain-specific, but the protocol-level is quite stable. I have built FIX interfaces to allow order entry and market data for our parimutuel matching engine. I did it using the quickfix open source FIX engine (actually C++ libraries) to handle the protocol and wrote a minimal C++ bridge that shuttles FIX application messages back and forth to a perl process over a socket. I then parse the FIX messages in perl with a custom FixMessage base class, run all of my application logic there, creating FixMessage objects as responses and then turn them back into a string to send back to the C++ bridge. I store the FIX messages as a hash mapping the fix tag number to the value. I then have accessor methods named after the mnemonic for each tag number. I actually just have a hash (%tagMapping) in my base class with the mapping and use an AUTOLOAD to create the accessors on demand. Parsing the FIX message is as simple as this code: sub fromString { my $string = shift; my($class, %tags); foreach my $field (split /\001/, $string) { my($tag, $value) = split /=/, $field, 2; if ($tag == $tagMapping{'MsgType'}) { $class = $msgType_2_class{$value}; next; } next if defined $isHeaderTag{$tag}; $tags{$tag} = $value; } return $class->new(\%tags); } I have sub-classes of FixMessage for each MsgType that I handle; the %msgType_2_class hash has the mapping. Actually, there's an additional complication to handle repeating groups; the value of a repeating group is an array ref with one element for each instance of the group; because tag order in repeating groups matters, each instance is represented with an array consisting of tag number/value pairs. Something like this: [ [ 42 => 'value', 165 => 'another value' ], [ 42 => 'value2', 165 => 'yet another' ], ... ]. So my actual fromString function has more logic to handle this. Anyway, converting an object back to a string isn't too hard; the only tricky parts are including the body length in the header and computing the checksum for the trailer. My code looks like this: sub toString { my $this = shift; my $header = "8=FIX.4.4\0019="; my $body = join("\001", "35=$class_2_msgType{ref $this}", map _toString($_, $this->{$_}), keys %$this) . "\001"; my $msg = $header . length($body) . "\001$body"; my $cksum = 0; $cksum += ord($_) for split //, $msg; $cksum = sprintf "%03d", $cksum %256; return $msg . "10=$cksum\001"; } sub _toString { my($key, $value) = @_; if (ref $value eq 'ARRAY') { return unless @$value; return join "\001", "$key=" . @$value, map { my $val = $_; my @data; for (my $i = 0; $i < $#$val; $i+=2) { push @data, "$tagMapping{$val->[$i]}=" . $val->[$i + 1]; } @data; } @$value; } elsif ($value ne '') { return "$key=$value"; } else { return; } } That's pretty much my whole FIX message base class. The constructor allows objects to be constructed from a string or from tag mnemonic => value pairs. I don't know if this helps you, but at least you see how simple it is to handle parsing and generation of FIX messages. Benjamin Holzman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.pm.org/pipermail/banking-pm/attachments/20061203/ff318292/attachment-0001.html From alex at owal.co.uk Tue Dec 5 04:52:57 2006 From: alex at owal.co.uk (alex at owal.co.uk) Date: Tue, 5 Dec 2006 12:52:57 -0000 (GMT) Subject: [Banking-pm] Ladybird book of Risk? Message-ID: <24135.193.26.4.35.1165323177.squirrel@sflink.net> This is rather embarassing after I've been doing perl for Risk systems for six months but does anyone know of a "Ladybird's First Book of Risk"? I can handle the little detail - but I still dont have the big picture. As an example I do have on my desk Derivatives - by Paul Wilmott The Fundamentals of Risk Measurement - by Marrison Risk Management in Banking - by Bessis I also use http://riskglossary.com Alex From adrianh at quietstars.com Tue Dec 5 04:44:34 2006 From: adrianh at quietstars.com (Adrian Howard) Date: Tue, 5 Dec 2006 12:44:34 +0000 Subject: [Banking-pm] Ladybird book of Risk? In-Reply-To: <24135.193.26.4.35.1165323177.squirrel@sflink.net> References: <24135.193.26.4.35.1165323177.squirrel@sflink.net> Message-ID: <8E831DEE-356E-4F18-AF4B-FCC07EDE589C@quietstars.com> On 5 Dec 2006, at 12:52, alex at owal.co.uk wrote: > This is rather embarassing after I've been doing perl for Risk > systems for > six months but does anyone know of a "Ladybird's First Book of Risk"? > > I can handle the little detail - but I still dont have the big > picture. On project-related risks I like DeMarco & Lister's "Waltzing with Bears"... may be too light though... Adrian From mike at wormers.net Tue Dec 5 05:10:33 2006 From: mike at wormers.net (mike at wormers.net) Date: Tue, 5 Dec 2006 13:10:33 -0000 (GMT) Subject: [Banking-pm] Ladybird book of Risk? In-Reply-To: <8E831DEE-356E-4F18-AF4B-FCC07EDE589C@quietstars.com> References: <24135.193.26.4.35.1165323177.squirrel@sflink.net> <8E831DEE-356E-4F18-AF4B-FCC07EDE589C@quietstars.com> Message-ID: <64271.141.228.106.136.1165324233.squirrel@mail.wormers.net> Depends what area you are looking at but, I don't think you could go wrong with any of these: Equity Derivs: Nassim Taleb 'Dynamic Hedgign' is fairly light but quite good. Bonds: 'The Treasure Bond Basis', forget the author! Its on Amazon. Interest Rates: 'Swaps and Other Derivatives' , Richard Flavell. (Google, Uri Ron , Bank of Canada has some good on-line papers for bootstrapping curves) e.g. ' A Practical Guide to Swap Curve Construction. ' Rds Mike > > On 5 Dec 2006, at 12:52, alex at owal.co.uk wrote: > >> This is rather embarassing after I've been doing perl for Risk >> systems for >> six months but does anyone know of a "Ladybird's First Book of Risk"? >> >> I can handle the little detail - but I still dont have the big >> picture. > > On project-related risks I like DeMarco & Lister's "Waltzing with > Bears"... may be too light though... > > Adrian > > _______________________________________________ > Banking-pm mailing list > Banking-pm at pm.org > http://mail.pm.org/mailman/listinfo/banking-pm > From alex at owal.co.uk Tue Dec 5 05:51:34 2006 From: alex at owal.co.uk (alex at owal.co.uk) Date: Tue, 5 Dec 2006 13:51:34 -0000 (GMT) Subject: [Banking-pm] Ladybird book of Risk? In-Reply-To: <8E831DEE-356E-4F18-AF4B-FCC07EDE589C@quietstars.com> References: <24135.193.26.4.35.1165323177.squirrel@sflink.net> <8E831DEE-356E-4F18-AF4B-FCC07EDE589C@quietstars.com> Message-ID: <10436.193.26.4.35.1165326694.squirrel@sflink.net> > > On 5 Dec 2006, at 12:52, alex at owal.co.uk wrote: > >> This is rather embarassing after I've been doing perl for Risk >> systems for >> six months but does anyone know of a "Ladybird's First Book of Risk"? >> >> I can handle the little detail - but I still dont have the big >> picture. Adrian wrote: > On project-related risks I like DeMarco & Lister's "Waltzing with > Bears"... may be too light though... Sorry to not make things clear. I meant financial Risk as in "What would happen to our portfolio of financial instruments should interest rates go up by 1%?" and so on... Alex From alex at owal.co.uk Tue Dec 5 06:01:04 2006 From: alex at owal.co.uk (alex at owal.co.uk) Date: Tue, 5 Dec 2006 14:01:04 -0000 (GMT) Subject: [Banking-pm] Ladybird book of Risk? In-Reply-To: <64271.141.228.106.136.1165324233.squirrel@mail.wormers.net> References: <24135.193.26.4.35.1165323177.squirrel@sflink.net> <8E831DEE-356E-4F18-AF4B-FCC07EDE589C@quietstars.com> <64271.141.228.106.136.1165324233.squirrel@mail.wormers.net> Message-ID: <17433.193.26.4.35.1165327264.squirrel@sflink.net> > Depends what area you are looking at but, I don't think you could > go wrong with any of these: > > > Equity Derivs: Nassim Taleb 'Dynamic Hedgign' is fairly light but quite > good. Hmmm "fairly light" is what I need :-) I have only recently heard of Taleb because he does training with Paul Wilmott. > Bonds: 'The Treasure Bond Basis', forget the author! Its on Amazon. http://www.usastores.com/Consensus/26-48/c637.htm http://www.amazon.com/Treasury-Bond-Basis-Speculators-Arbitrageurs/dp/1557384797 Hmmm - my problem is that I need to understand the Risk on *EVERYTHING*. Limiting myself to just Treasury is not an option. Obviously I might benefit from understanding Treasury - but that is just one desk amng many for me :-( > Interest Rates: 'Swaps and Other Derivatives' , Richard Flavell. http://www.amazon.com/Swaps-Other-Derivatives-CD-ROM-Finance/dp/0471495891/sr=11-1/qid=1165325831/ref=sr_11_1/103-5291245-0981423 Hmmm - I dont actually need to know how to price anything - or calculate risk sensitivities - but I do need to know what they are... > (Google, Uri Ron , Bank of Canada has some good on-line papers for > bootstrapping curves) e.g. > ' A Practical Guide to Swap Curve Construction. ' Thanks! Any more suggestions? The lighter the better :-) Alex From mike at wormers.net Tue Dec 5 05:39:46 2006 From: mike at wormers.net (mike at wormers.net) Date: Tue, 5 Dec 2006 13:39:46 -0000 (GMT) Subject: [Banking-pm] Ladybird book of Risk? In-Reply-To: <17433.193.26.4.35.1165327264.squirrel@sflink.net> References: <24135.193.26.4.35.1165323177.squirrel@sflink.net> <8E831DEE-356E-4F18-AF4B-FCC07EDE589C@quietstars.com> <64271.141.228.106.136.1165324233.squirrel@mail.wormers.net> <17433.193.26.4.35.1165327264.squirrel@sflink.net> Message-ID: <6811.141.228.106.136.1165325986.squirrel@mail.wormers.net> > Hmmm - my problem is that I need to understand the Risk on *EVERYTHING*. > Limiting myself to just Treasury is not an option. Obviously I might > benefit from understanding Treasury - but that is just one desk amng many > for me :-( See the other two books, between them, equity derivs, treasury & interest rates you pretty much cover everything apart from Credit & Commodity. >> Interest Rates: 'Swaps and Other Derivatives' , Richard Flavell. > Hmmm - I dont actually need to know how to price anything - or calculate > risk sensitivities - but I do need to know what they are... > The book doesn't go into that much detail about pricing (though you have to know something ) and does explain the risks across differen products (which may not be universal across all products). > >> (Google, Uri Ron , Bank of Canada has some good on-line papers for >> bootstrapping curves) e.g. >> ' A Practical Guide to Swap Curve Construction. ' > > > Thanks! I'd start with Nassim Taleb on equities , which should cover volatility measures for equity derivatives. Uri Ron and Richard Flavell should cover the interest rate side of things. From bpretsel at gotadsl.co.uk Tue Dec 5 14:40:36 2006 From: bpretsel at gotadsl.co.uk (Barry Pretsell) Date: Tue, 5 Dec 2006 22:40:36 +0000 Subject: [Banking-pm] Ladybird book of Risk? In-Reply-To: <17433.193.26.4.35.1165327264.squirrel@sflink.net> References: <24135.193.26.4.35.1165323177.squirrel@sflink.net> <8E831DEE-356E-4F18-AF4B-FCC07EDE589C@quietstars.com> <64271.141.228.106.136.1165324233.squirrel@mail.wormers.net> <17433.193.26.4.35.1165327264.squirrel@sflink.net> Message-ID: <2141F6B6-A58B-41C6-87A6-F3613EEF14BA@gotadsl.co.uk> http://www.amazon.co.uk/Against-Gods-Remarkable-Story-Risk/dp/ 0471295639/sr=8-1/qid=1165358228/ref=pd_ka_1/203-1490188-9173507? ie=UTF8&s=books light and quite interesting. Barry On 5 Dec 2006, at 14:01, alex at owal.co.uk wrote: >> Depends what area you are looking at but, I don't think you could >> go wrong with any of these: >> >> >> Equity Derivs: Nassim Taleb 'Dynamic Hedgign' is fairly light but >> quite >> good. > > > Hmmm "fairly light" is what I need :-) > I have only recently heard of Taleb because he does training with Paul > Wilmott. > > > >> Bonds: 'The Treasure Bond Basis', forget the author! Its on Amazon. > > http://www.usastores.com/Consensus/26-48/c637.htm > http://www.amazon.com/Treasury-Bond-Basis-Speculators-Arbitrageurs/ > dp/1557384797 > > Hmmm - my problem is that I need to understand the Risk on > *EVERYTHING*. > Limiting myself to just Treasury is not an option. Obviously I might > benefit from understanding Treasury - but that is just one desk > amng many > for me :-( > > > >> Interest Rates: 'Swaps and Other Derivatives' , Richard Flavell. > > http://www.amazon.com/Swaps-Other-Derivatives-CD-ROM-Finance/dp/ > 0471495891/sr=11-1/qid=1165325831/ref=sr_11_1/103-5291245-0981423 > > Hmmm - I dont actually need to know how to price anything - or > calculate > risk sensitivities - but I do need to know what they are... > > > >> (Google, Uri Ron , Bank of Canada has some good on-line papers for >> bootstrapping curves) e.g. >> ' A Practical Guide to Swap Curve Construction. ' > > > Thanks! > > Any more suggestions? The lighter the better :-) > > Alex > > _______________________________________________ > Banking-pm mailing list > Banking-pm at pm.org > http://mail.pm.org/mailman/listinfo/banking-pm > regards, Barry -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.pm.org/pipermail/banking-pm/attachments/20061205/d84bf8c8/attachment.html From ns7d-l3x0 at xemaps.com Thu Dec 14 05:01:16 2006 From: ns7d-l3x0 at xemaps.com (IvorW) Date: Thu, 14 Dec 2006 08:01:16 -0500 Subject: [Banking-pm] [JOB] My role at LCH is going permie Message-ID: My assignment at the London Clearing House is being extended until March 2007, but for the last time. They have also asked me to come up with a job spec, which I have attached. This is my document, and has not been through their HR department. The current policy is to migrate all their IT contract roles to permanent staff. They are probably looking to hire somebody before March so that I can cross-train before I go. Let me know if you are interested. Please reply off list to ivor.williams (at) lchclearnet.com. -------------- next part -------------- A non-text attachment was scrubbed... Name: SwapClear_Support_Skills_Handover.doc Type: application/msword Size: 20480 bytes Desc: not available Url : http://mail.pm.org/pipermail/banking-pm/attachments/20061214/cc0ccb43/attachment.doc From andy at almond-technologies.co.uk Mon Dec 18 05:11:06 2006 From: andy at almond-technologies.co.uk (Almond Technologies) Date: Mon, 18 Dec 2006 13:11:06 +0000 Subject: [Banking-pm] My fellow contractors! Message-ID: <20061218131106.GT17797@almond.milky.org.uk> I know this is a list about banking perl workers, but you seem like a knowledgeable bunch, so I thought I'd throw this one open to you: When adding VAT to invoices, does the resultant VAT get rounded up or down? I'm on a rate that ends in 5, and calculating VAT on this gives: 5*0.0175 = .0875 Should that be 8p or 9p on my invoice? Or, given that's a daily rate, do I only round off the total figure? Thanks in advance, Andy -- Andrew White, Almond Technologies Ltd. Reg. company no. 5383888 E:andy at almond-technologies.co.uk P:+44 7749 418194 From alex at owal.co.uk Mon Dec 18 06:19:02 2006 From: alex at owal.co.uk (alex at owal.co.uk) Date: Mon, 18 Dec 2006 14:19:02 -0000 (GMT) Subject: [Banking-pm] My fellow contractors! In-Reply-To: <20061218131106.GT17797@almond.milky.org.uk> References: <20061218131106.GT17797@almond.milky.org.uk> Message-ID: <59066.218.189.94.27.1166451542.squirrel@www.sflink.net> Andy wrote: > When adding VAT to invoices, does the resultant VAT get rounded up or > down? > > Or, given that's a daily rate, do I only round off the total figure? The latter. Basically no one seems to mind about half pence... perhaps you could sometimes round up and sometimes round down. Howevever if you repeatedly round down then the accumulative effect will might be noticed. BUT who knows... Alex (in china) McLintock From andy at almond-technologies.co.uk Mon Dec 18 12:00:37 2006 From: andy at almond-technologies.co.uk (Almond Technologies) Date: Mon, 18 Dec 2006 20:00:37 +0000 Subject: [Banking-pm] My fellow contractors! In-Reply-To: <59066.218.189.94.27.1166451542.squirrel@www.sflink.net> References: <20061218131106.GT17797@almond.milky.org.uk> <59066.218.189.94.27.1166451542.squirrel@www.sflink.net> Message-ID: <20061218200037.GW17797@almond.milky.org.uk> On Mon, Dec 18, 2006 at 02:19:02PM -0000, alex at owal.co.uk wrote: > Andy wrote: > > When adding VAT to invoices, does the resultant VAT get rounded up or > > down? > > > > Or, given that's a daily rate, do I only round off the total figure? > > The latter. Basically no one seems to mind about half pence... perhaps you > could sometimes round up and sometimes round down. Howevever if you > repeatedly round down then the accumulative effect will might be noticed. > > BUT who knows... that's what http://shrunk.net/ac356451 says too (hmrc). It says to always round down, which is fine by me Thanks alex, and I hope you're enjoying China! ;-) -- Andrew White, Almond Technologies Ltd. Reg. company no. 5383888 E:andy at almond-technologies.co.uk P:+44 7749 418194