Affirm^Confirm in FX derivatives

In both FX derivativies and Equity derivatives worlds, there’s a Affirmation process before the Confirm process. We will focus on FX derivatives but most of it applies to eq derivatives.

Confirm is a legally binding document, accessible by clients, often on paper. Affirm is not legally binding. It’s often based on a phone call between the 2 counterparties. Think of Affirm as a preliminary Confirm.

Q: can we (operations) complete Affirm on a trade without checking with counterparty?
AA: Forbidden. Operations must verify with counterparty before completing Affirm.

Given its legal power, it’s good to know what a confirm document contains. A BofA veteran told me it might say “Blackrock shall pay BofA $1m on 1/1/2013”. There are 2 such confirms, on both sides, to be matched.

For a derivative deal executed on T+0 and settles T + 3mth, Affirmation could happen T + 0/1/2, but Confirmation usually happens right before T + 3mth — real world settlement. Settlement system actually receives the trade around T + 0/1/2, but keeps the trade as unsettled and often reports such unsettled trades on a daily basis.

##feeling like 滥竽充数 among trading developers #letter to friends

(another blog post. No need to reply.)

Working in trading system [1], every now and then i feel like 滥竽充数. If i ask myself

Q: if i benchmark myself among java developers with 5+ year experience in trading, are the majority higher than me?

i can’t categorically say YES. A lot of them are not obviously better than me. For one thing, I feel most of them aren’t battle-tested in demanding places like Goldman Sachs;) However, some of the trading developers I see are more experienced than me on several technical fronts below, and are faster [2]. However, as stated in my post on “perl defensible turf”, 5 years in trading doesn’t mean you know threads or MOM (for eg) inside out.

* threading — idioms and implementation techniques, and to a lesser extent, design techniques. Devil in the details. Compared to other developers, i place more emphasis on low-level implementation skill. If you want a competent and productive[2] threading developer, test her implementation skill, not architecture.
* MOM ie messaging
* data grid
* trouble-shooting MOM, serialization, Spring
* trouble-shooting eclipse. I single out this one as the most frequent weakness and most neglected area.
*** (For a balanced perspective, I should point out I rate myself above average on Unix, SQL and scripting. In fact i had a recent “debate” with a younger java developer with narrower experience than me. He is less comfortable putting complex biz logic into queries and procs.)

Bottom line ==> If i were to lead a team in S’pore, I had better catch up.

[1] I feel lucky this is a mainstream wall street trading system rather than a no-name trading house with a cheap, home-made system.
[2] trading systems are more fast-paced than anywhere i know including telecom, media, manufacturing, dotcom, e-government, healthcare… Managers really do benchmark developer productivity.

Baye’s formula with simple quiz #my take

Tree diagram — useful in Baye’s.

Wikipedia has a very simple example — If someone told you they had a nice conversation in the train, the probability it was a woman they spoke with is 50%. If they told you the person they spoke to was going to visit a quilt exhibition, it is far more likely than 50% it is a woman. This is because women enjoy the comforting feel of a quilt. Call the event “they spoke to a woman” W, and the event “a visitor of the quilt exhibition” Q. Then pr(W) = 50%, but with the knowledge of Q the updated value is pr(W|Q) that may be calculated with Bayes’ formula.

Let’s be concrete. Let’s say out of 100 woman, 10 would mention their visit to quilt exhibition, and out of 100 men, 2 would. We do a large number (10,000) of experiments and record the occurrence of W and Q.

pr(W and not Q) = 50%(1-10%) = 0.45
pr(W and Q) = 50%*10% = 5%
pr(M and Q) = .5*.02 = 1%
pr(M and not Q) = .5(1-0.02) = 49%

These 4 scenarios are Mutex and Exhaustive. Among the Q scenarios (6%), how many percent are W? It’s 5/6 = 83.3% = pr(W|Q). This is the Baye’s formula in action. In general,

pr(W|Q) = pr(W and Q) / pr(Q) , where

pr(Q) == [ pr(Q|W)pr(W) + pr(Q| !W)pr(!W) ]

Another common (and symmetrical) form of Beye’s formula is the “frequenist” interpretation of Baye’s formula —

pr(W|Q)pr(Q) =pr(W and Q)= pr(Q|W)pr(W)

I feel in quiz problems, we often have some information about pr(Q| !W), or pr(Q|W) or pr(W|Q) or pr(Q) or pr(W), and need to solve for the other Probabilities. Common problem scenarios:
* We have pr(A|B) and we need pr(B|A)
*

I think you inevitably need to calculate pr(A and B) in this kind of problems. I think you usually need to calculate pr(A) in this case, since the unknow probability = …/pr(A)

save a literal string in std::string or vector etc

— basic char pointer
char * ptr  = “and”;
char const * const_ptr = “and”;
— char array
char charArray[] = “and”;
char const  constCharArray[] = “and”;
— std::string
std::string std_string = “and”;
— std::string to vector of char.
std::vector<char> vc (std_string.begin(), std_string.end()); //

copy(vc.begin(), vc.end(), ostream_iterator<char>(cout, “”));

(2/3 of C/C++ coding tests involve strings…)

don’t repeat yourself ] sproc

Basic constructs/ideas/techniques to avoid repeating yourself ] sproc:

* dynamic sql
* nested sproc — sproc1 calling sproc2, which calls sproc3. i think the code in the nested sproc can be invoked repeatedly but coded once only
* app to construct the “sister statements”
* converge — short, non-repetitive queries insert into a shared table, then common logic applied to the shared table
* temp tables are essential to many of the constructs above
* case-expressions are powerful tools for cutting such repetition

t-sql: GO,

Think of it like this: Cut up your script into multiple files,separated by the “GO” statement. Run each of these files individually,but use the same connection. That’s all “GO” does.

Server never sees GO. GO is a keyword in client apps such as sqsh. I think java/perl apps don’t use GO.

Until you are clear on the fundamentals above, avoid the confusing questions over auto-commit, transaction and GO. I think auto-commit means every GO-batch is a self-contained transaction. If a GO-batch issues a begin tran without ending it, then server will keep it open.

Another confusing question is GO and stored proc.
* i believe a java/perl app calling a proc won’t use GO at all.
* when sqsh calls the proc, it needs GO to mark end-of-batch
* Most complicated scenario is when you create the proc in sqsh. I usually wrap the create-begin-end piece in one go-batch.

modify a check constraint ] sybase

According to my brief inet search, i think you must do a drop-add.

1) sp_helpconstraint table1 — to see the old constraint name
) alter table table1 drop constraint con1
) alter table table1 add constraint con2 check (….) — must specify a constraint name [1].

[1] when adding/creating columns, u don’t need to specify a constraint name

Constraints do not apply to the data that already exists in the table at the time the constraint is added.

how to estimate workload – le2XR

Hi XR,

There’s a lot of theory and many book chapters and courses on app development estimation. I don’t know how managers in my department does it. I’m sure these factors below affect their estimations.

* the right way of solving a problem can shorten a 2-day analysis/discussion to 2 hours, provided someone points out the correct way in the beginning. In our bigger department (100+ developers), many managers make estimates assuming each developer knows the standard (not always best) solutions from the onset. If I am new i could spend hours and hours trying something wrong.

* as in your struts form-validation example, a good framework/design can reduce a 1-month job to 1-week.

* tool — the right software tool can reduce a 3-hour job to 30-minutes. Example — I once mentioned to you testing tools. Also consider automated regression testing.

* A common complaint in my department (100+ developers) — a poorly documented system can turn a 2-day learning curve into a week.

* I suspect my colleagues do fewer test cases than i do, given the same system requirement. This is partly because they are confident and familiar with the system. This could mean 30% less effort over the entire project.