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

Fund FX and CLS

Here’s a picture: You buy a nice bottle of wine from me for $50 (What can I say, you like wine and I sell some serious gourmet Brunello.) I’m just a broker so I’ll have the wine shipped to you and you’ll send the payment directly to my supplier… The catch is, all I know about this supplier is that the guy’s name is “Giovanni’s Vinos”, in Milan Italy, and that he has a Bank of America account somewhere in New York City. So now, I expect you to transfer $50 into Giovanni’s account at BofA based solely on this information. Sorry, dude.

In the world of Foreign Exchange (FX) Trading, it’s called Fund FX, and that’s exactly what I’ve been trying to implement for one of our Japanese clients for the last several months. Yeah, fun stuff.

On the interface, I need to extract settlement information from an imcoming MT202 SWIFT message. This message contains antiquated pseudo-cryptic character sequences clearly conceived by twisted alien creatures with pasty white faces to keep track of where we keep our pieces of green paper. A SWIFT MT202 Message is used to order the movement of funds (Your $50) to the Bank of America account of ‘Giovanni’s Vinos.’ It would look something like this:

{1:F01YOUUSNYAXXX0000000000}{2:I202DFO1SFNYAXXXN2020}{3:{108:MT202}}{4:
:20:2021
:32A:040723USD50,
:57D:BANK OF AMERICANEW YORK
:58D:GIOVANNI'S VINOSMILANO
-}{5:}

I need to interpret these instructions as soon as they come in the system and match them against transfers and issue settlement instructions to BofA in New York. So now I’ve got to figure out a way to identify Giovanni’s account at BofA… Granted, in real-life the bank name would allow me to uniquely identify it, and all I really need to do is locate its SWIFT code and, with the recent introduction of Continuous Linked Settlement (CLS), all this has gotten a lot easier. The thing gets to be a real nightmare, though, if you’re trying to implement an interface to both Fund FX and CLS at the same time. What came first, the chicken or the egg?

What really irks me, though, is that both CLS and Fund FX are brand-spanking new services. Don’t you think they could at least have opted for a less arcane protocol than SWIFT? I fully understand the ubiquitous presence of SWIFT in the world of foreign exchange settlements. Still, If I’m architecting a new system, I’d much rather use XML and SOAP to communicate and let people generate their own SWIFT, if they need to. Apparently though, that’s just me…