Last week, we took a look at stuff you pay for and your clients don’t use. This week, a subtle variation. Paying for stuff that you don’t use properly.
When you negotiate to buy something, you will be starting from the notion that you need whatever good or service you are looking at. There is often an extensive effort to negotiate the terms and conditions. At the end of that you will often feel pretty pleased with yourself for negotiating and winning on your points. Banks buy in a lot of services, so a lot of that goes on. One major area of costs in all banks is market and reference data; data feeds, often live, with price information or ones with vital information about the products used in banks, such as a dividend announcement. The cost of this stuff is huge; it is right up there with IT spend and compensation in the group of major expenses.
Price information is a vital service. The value of your clients’ holdings drives many things, not least your own fees as a bank, as well as the measurement of performance on the clients’ portfolios. Some years back, in days at Goldman Sachs, a big issue was raised in our Operations area; there were numerous complaints from private clients about their holdings not being priced properly. This was enough of a problem to end up in my lap when I was working for our Control Improvement Group. At that time, pricing information was captured in something called the Product Master; am old mainframe system that held all the data about the products Goldman traded, such as coupon dates, and the latest price. Turns out that lots of products were not set-up and held by the clients, but there was no price. Looking into this, I found problems across the board, broadly driven by two root causes:
Convenient rules that fixed symptoms and not causes. At some point, two managers had been confronted by a similar complaint about prices and had decreed that any security held by two or fewer clients would not be actively priced. If we happened to pick up a price, good. If not, no measurement, no management. This deft slight of hand borrowed from the playbook of Mrs. Thatcher, the former UK Prime Minister; if you don’t like statistics, change the way you measure or the rules. Ironically, it was my then current boss who was one of the whiz kids that dreamed up that idea. Had to tell him that it was not such a good idea; although, to put things in perspective, he was pretty good at all aspects of Operations, so one couldn’t take this one howler too seriously. The second problem was the bigger one and one that highlighted how much technical knowhow you need in and around a bank’s processes. The Product Master at Goldman Sachs was based on the US securities identification standard of the time, the CUSIP. In the US, every public security needs one of these. In IT terms it is the “unique key”; one and only one security could have that CUSIP at any one time. But, because this was a US concept and Goldman traded other securities, the system would generate a Goldman Sachs Security ID, GSID, for every security. And, you could add any security and simply have the system allocate a new one of these GSID’s. Outside of the US, there are various securities numbering standards, with ISIN coming closest to to be ing the banks’ version of the ISBN used on a book. There are others too, such as SEDOL, used by the London Stock Exchange, or Valoren, the old Swiss standard. These too are “unique keys”; an identification number that unequivocally identifies one and only one security.
Not being able to use what you pay for. When banks buy services in the market data space, such as price feeds, the vendor will specify which unique key, or sometimes keys plural, will be used. What had happened here was that somebody on the buying side of the market data team had successfully bought a service, possibly even on great terms, but on the day-to-day operations side, there was not an effective procedure to ensure that every security in the Product Master had at least one of these public unique keys when it was set up. That was my linguistically challenged friends in Operations in London were able to set up the same security many times. In fact, this happened a lot. Particularly in matters of Swiss securities. In Switzerland, securities can be described in any of three of the national languages, German, French and Italian, as well as English. Add to that, some of the names are hard to pronounce and spell if your language skills are limited, which is the norm of folks in London. “Schweizerische Bankgesellschaft, UBS Reg. UBS N” anybody? Imagine the price data flying past your bank in the night sky. Loads of it. In order to get the price for a particular security you need a magnet to drag that price out of the night sky. That is what the unique key does for you. Without, you are paying for all that data to fly by and are not able to use it.
There were a lot of securities on the database that were what I termed “improperly dressed.” Fortunately for me, we were right at the start of the intranet and the internet. I was able to find a really clever young programer who was able to interrogate the data, assign a regional product owner based on some rules and then display the status on an intranet page, showing the score of new and old problems. Not bad for 1997. That way, we could “name and shame” all of those regional Ops folk, showing them who was doing how well at sorting out the issue by location. A little bit of friendly, virtual competition. Doing some remediation, fixing the numbering issue and doing it in a way that meant we saw any new problems meant we could massively improve the quality and completeness of the pricing data for the clients specifically and the firm generally. Happy clients; that makes a difference.
Lessons Learned: Three things. Such a wonderous number:
Addressing the symptoms and not the causes is a common error and a saying that many will understand. When you are fixing things, you need to get to the root cause. In this case it was an IT tool that could not add the controls to stop people adding things incorrectly; setting a rule at the data field level was not an easy thing to do. If you can set field level controls, that is a great thing. That is what is called an ex-ante check. Before. If you can’t manage that, then checking just after is the next best thing. That is an ex-post check.
Understand the unique key. What standard are you paying for? Can you ensure your system meets the standard?
Name & Shame. There is of course the old adage that what gets measured, gets managed. My subtle variation on that would be: “What gets measured publicly gets managed really well.”
A personal request: Comments and feedback from regular readers are very welcome. Thank you for each and every one of them. If you find this Blog useful, please subscribe. There is an E-Mail tool and an RSS link on the right hand side of the main Blog page. If you like it enough to share, please share this with a friend or two and ask them to subscribe too. If I am wide of the mark and not offering anything of use, please comment or contact me directly via E-Mail.
Share on:
