03 AprProcess control. The advanced class.
Editor’s Note: This is﹟7 in the series on Controls. All that heading stuff looks a bit funny in the emails, so I have dropped it.
More. Yes, there’s more. Last week’s blog looked at the three basic elements of good process controls: One Screen, Score and Action. This week we will take it to the next level, to use that phrase so beloved of folk in financial services. There are three topics worth covering, none of them more important than the other. If you can do all three great, if you already do all three, hats off to you and if you can improve your work life by doing just two of them, remember that “Two our Three Ain’t Bad.”
“Tie in the communications”: This follows from last week’s ﹟3, Action. Your whizzy system tells you that you have three problems with trades that will settle tomorrow. It takes you to the list, let’s you select item three. A trade with a bank in Mexico. Now, there are a few things you need in order to sort out the issue. First, a phone book. Who do you know, or more importantly, who does your team and even your boss know at that bank? Typically, folks keep their own phone books. Sometimes, the slightly smarter have a team phone book in Outlook. But, the success of that is tied to the quality of the entry and the spelling. Imagine that one guy likes to refer to RBS, another to Royal Bank of Scotland, or even The Royal Bank of Scotland. This used to be a lot worse in Switzerland when in days gone by there were four big banks whose name could be spelt any one of four ways, and abbreviated any one of four. The ideal team phonebook is the one that is embedded in the system you use to process exceptions, linked to the account number you booked the trade against. So now, you have a number for Jorge at Banamex in Mexico. You phone him up, he confesses to know the trade and promises he will input his instructions. You want to send him an email, or even a SWIFT message, to confirm who will do what. More than nine times out of ten, that communication is in a different system, probably your own or maybe a team email account. At a push, you might just find it again when you have to follow-up. A great system will allow you to integrate that email traffic with your exception processing.
Monitor activity flows: STP or exception processing monitoring normally relies on one key driver; traffic. When traffic flows, the processes look at what is going on and allow you to quickly see those things that do not conform to the rules. Many of you will have seen traffic reports on the TV news shows; particularly in New York, the early morning shows will show a webcam view of certain key traffic bottlenecks. No cars is good news. Simples. In the world of the Bankers’ Plumber, things are not so simple. Looking just at a screen that details exceptions, if there were no exceptions, one might just be a happy bunny and go back to reading the sports news on the BBC or killing off a couple of emails. But. in banking, no news could be bad news. Actually what you want is the goldilocks picture; the amount of traffic that is just right. For any hour of the day, there will be a “normal” or “expected” amount of traffic. If you are in FX Operations, you know to expect a traffic surge around 09:00 CET, the European opening and 15:00 CET, the NY opening. Once again the term “Normal” is the operative word here. If you are in a certain business, you ought to know what normal is. (Editor’s note: if you have not read them yet, there are a series of Blog posts on this. From http://3cadvisory.com/blog/, start at the bottom and work up). To do this well, you need the equivalent of a Webcam; a software service or agent that is looking at the flows in the channels into and out of your world, comparing them to expected or normal values and alerting you accordingly. This is a really important service and one we learned the hard way in the early days of providing a transaction service at Credit Suisse. We had started a new service, settling FX trades in CLS for Third Parties. Brown Brothers Harriman, BBH, was an early and discerning client. (Disclosure: normally this stuff is bound by Swiss Banking secrecy, however the information is in the public domain) In those early days, we often had calls from BBH about them not being able to see the trades they had sent to us in the CS web tools we provided and that they were taking phone calls from their counterparts about trades that were unmatched. Now we had hints in the system that something was not right, but it didn’t and we did not “join up the dots”. Suffering a series of “Gotcha’s” when you are in a client service business is never good. Suffering this in a new relationship with BBH is really bad; the good folks over there pride themselves on the longevity of their relationships. And with some justification; BBH is a great shop, always on top of their game. As the saying goes, from bad comes good. All credit to my old friend and early manager at GS, Mike Sammons, for that nugget of wisdom. That bad was the prompt for us to look in to how we could monitor traffic the same way the police and news stations do. Turns out our IT cousins had a term for this: “BAM” or “Business Activity Monitoring”. In 2004 or so, when we came up with this need, this IT discipline was in its infant years and there was as yet no clear standard. Way back then, in a fit of generosity to the French of proportions normally unknown to any Brit, we bought something from a French outfit. Good enough to get us started. The key was that these tools could be in the hands of the end user and not the main IT team. Done well these type of tools should enable your operation to look more mission control at Nasa than your ordinary email in-box.
“Don’t rely on a central service”: Our IT colleagues like to have something called service management. Supposed to do just what it says on the tin. They will, or so they say, take care of all your services. Fire & forget. Bad idea. A recent example experienced by a client highlights how far you ought to go to keep an eye on your stuff. Payments. Important things. Now since one in a gazzillion of these things might just have some not so benign intentions, those good ole boys from the US of long armed legislation, aka the USA, have decreed rules that force the rest of the planet to run every last little payment thru an OFAC checker, just in case you are addressing your donation directly to OBL, or Al Qaeda. So net result, all banks run every payment, every time, thru an OFAC filter. Even if you have made a payment to the same destination ever day for ten years, thru the OFAC filter it must go. So there you are in the FX operations of some big bank, making all those nice payments to CLS Bank, a place so limited in its operation that it has but 60 account holders. Even Her Majesty QEII, never mind Johnny come lately the terrorist, could not open an account there. But check those daily payments, along with all the rest, we must. So what happens when the server with the OFAC filter software crashes? All payment messages stop being sent out, including those vital ones for the FX Ops team. Now all you need to know is that the server is down and you would go straight to Plan C (sse last week’s installment for more on this), but if you don’t have that info immediately to hand, first you will not realise that Plan A will not work, second you will waste time going to Plan B. What you have to be able to do is see your process all the way thru to the end. Although you could, you should not simply assume the next part in the process will work. Design your exception processing to tell you when the messages don’t get all the way thru to the end.
A variation on this is when you don’t get the next message in the trade lifecycle back. Typically in a securities settlement system you will get something in SWIFT MT548 format telling you your trade is accepted, then matched or unmatched. So, if you are sending messages, you want to see those accepts and then either matched or unmatched. With a little bit of analysis, you can figure out what the normal “turn around time” is for messages, even the standard deviation and then set your monitors to alert you when you are well away from the mean. If you want to be totally scientific, if you are outside two standard deviations, then you can be 95% confident that something is not right. And you thought all that mean and normal distribution stuff in Math class was useless!
Lessons Learned: If you can get all the message flow into one central place, as long as that is not a group e-mail in-box, you will be ahead of the game. No news is bad news is too simple. In fact you want the goldilocks amount of news; the amount that is just right. Lastly, watch the ball all the way into the hole. Monitor your process all the way thru to the end.
Epilogue: I mentioned the subject of BAM, Business Activity Monitoring. This area has come a long way since our early work at CS in 2005. Back then we used a product from an outfit called Systar Since then, I have seen an excellent platform of more recent vintage. PaceMaker from Pace Metrics. Or Incentage is another offering in this space.