Tag: programming

Writing a language interpreter

Today was a kickass day… I love days like this. I woke up this morning with feedback from one of our consultants in Tokyo. Sumitomo Trust went live on FX yesterday and it turns out that they processed 240 incoming MT202 SWIFT messages yesterday and the STP process is working well. The messages come in via MQ and the trades are automatically matched with appropriate payments generated. I felt quite gratified because I seriously suffered trying to implement this stuff.

I spent the rest of the day implementing iteration in our advice document generation language. Calypso generates different formats for advice documents (SWIFT, HTML, text) to be sent from the system via various gateways (SWIFT, E-mail, printer, fax) and the HTML documents are generated based on template files using a rudimentary in-house processing language and keyword substitution. I implemented conditionals a while back but it finally came time to add in iteration. Talk about a blast to code! I’ve got a command queue, contexts and variables being pushed on and off the stack (since we can have nested conditionals and, now, nested iterations). It had been a while since I’d revisited that code and I took advantage of this enhancement to do a lot of refactoring. From the onset (and for historical reasons) I’ve been using JavaCup to generate a parse tree. With the added complexity, however, I’ve moved all of the processing outside of the cryptic cup file, especially now that I’ve got a command queue (since we can only actually execute the commands within the iteration block after we’ve exited it.) Granted, there’s still plenty of performance optimization to do, and I’ve got to investigate whether or not I can use a cache. One limitation of the current setup is that the conditional statements within the iteration block can’t actually reference the iterator. That bugs me, but only a little since all that is really being done is keyword substitution in generated HTML. I’m also pushing the limits of JavaCup, I think… Thankfully, I’ve got the companion book at home so it looks like that’ll be coming off the shelf tonight and I’ll be burning the midnight oil.

Cover-your-ass clauses and gourmet FX traders

Certain long term maturing products are negotiated with conditions for early trade termination at predefined dates that either party can terminate the trade. This is common practice among interbank players to limit credit risk exposure. This is more or less financial mumbo-jumbo to allow traders to add special clauses to cover their asses. “We wanna do this deal but… just in case… let’s add a couple of get-out-of-jail-free cards in here.”

So that’s what I’ve been working on lately… Trying to ensure that our system allow Early Termination and Cash Settlement of Interest Rate and Credit Derivatives. I’d actually implemented a lot of that a while back and just needed to do some enhancements. Typically when I approach such a problem, I try to think how to encapsulate the new functionality by creating a new interface. It seems pretty evident. If you want to do more or less the same thing across a variety of dissimilar objects, figure out how to abstract out the common functionality and determine what information you need from those objects. Bam! You got yourself an interface.

Hmmm… I’m just blown away by how few people grasp this concept. Funny thing, too, is that this approach is usually harder at the onset but allows you to kick back later on by making fixes or enhancements in one place instead of 50. I just cringe when I see the same code cut-and-pasted across so many classes…. Oh, and people… If you tend to have a bunch of if clauses checking whether an object is an instance of something or other… you’re doing it wrong!

I’ve also been wrapping up Fund FX. That’s been brutal… These Japanese bankers are serious FX gourmets. They requested bulk matching of incoming MT202 messages against payments in the system. And all of that had to be recursive since it might require netting of payments, which then needed to be split to match against the incoming message amounts and, whatever residual payment could later be bulk matched with other payments. The thing drove me absolutely bonkers, mainly because I didn’t write the payment netting functionality of the system. The guy that did is brilliant with lots of business knowledge and good technical foundation, but his code… errrr… shall we say, inherits from structural programming as opposed to OOP. Ever heard of 5000 line methods? Calypso’s Back Office got ‘em! Oh the humanity…

Anyway, I’m off to San Diego for a long weekend and I’m looking forward to hanging out by the beach. The San Francisco fog, combined with the constant bombardment of CRT rays has me feeling white and pasty.

Peace,

David