Market data was the subject of last week’s post. This week, we take a took at transaction information; the stuff that is associated with every trade that a bank books.
Trade lifecycle. That expression will be familiar to those who work in financial services. It starts with book trade and ends with settle trade. Along the way, any one trade can be in many different states; instructed, accepted by where it is going to, matched, failed and similar. Over the last 20 years, it has become the norm that lots of electronic status messages are sent, informing the sender of the change of status. This is a great idea. As best I know, it started in the securities business and was adopted by the FX business when CLS was built. The theory goes that the sending institution can use the status messages to drive their exception management processes. Sometimes the expression STP, Straight Through Processing, is used around this too. The idea being that with the status message, you can triage between what needs attention and what does not. A fabulous idea, albeit that in some instances was overly pedantic. CLS took this to extremes, telling you on value date that your trade was “ready for settlement”. The exception as ever defining the rule that this is a good thing.
Once the design is out there, there are two parts that are important. The first is your ability to do something with them. Not every bank has the ability to take in these messages in real time, match them up with the internal transaction and then drive exception screens. If you can do something with them, then you will want them, even if you might not want every single one. In general, it is all or nothing and you have to throw away the messages you do not want.
If you do want the messages, because you can make good use of them, then the next question is, or at least ought to be, what does it cost? This depends on the way you receive them. The financial services industry’s standard transport mechanism is SWIFT. Some similarities to using a phone here; as a rule you pay for what you send and receiving is free. Now SWIFT has historically charged per message. If you have been in and around the SWIFT world, this will be a familiar concept. You may be less aware that a message has a maximum size, in bytes. So sending an MT950 statement for one account may mean several units being sent. Especially if that account is in a major currency for an active user. SWIFT also allows the concept of reverse invoicing, which is like collect calling. It can be useful if the receiver has low SWIFT rates and the sender has higher ones. In the earliest days of CLS, the FX community found it was locked in to the use of SWIFTNet and being reversed invoiced for lots of messages. That has changed since, but it was a horribly rude awakening at the time. In the meantime too, SWIFT has gone to more all-you-can-eat pricing; a fixed price per year with a message cap. But, and it is not a small one, all those messages you send eat up that allowance; eventually somebody will add activity that means you need the next plan size up or you are preventing a reduction to the next size down.
Where this gets very interesting is when you have a correspondent or depot bank in the mix. If you have a direct connection to a place and you are simply renting the line, then the traffic volume does not matter, it is a fixed cost. Banks use lots of leased lines, especially for electronic trading. You know where you are; you pay for the line. Size matters, of course; the bigger the size of that pipe, the more it costs, but it is fixed. Generally, on the Operations side of a bank, leased lines are not used. SWIFT is the main carrier. Great, it connects you to any and all Nostros and Custodians and works in both directions. Now if you ask your custodian or Nostro to send you updates, they have to think how to recover those SWIFT costs. With a potential variable number of messages per trade, for example if a trade fails or is unmatched and then matched, this is tricky, both to fix a price for and to keep track of. What gets charged for is a function of two things: firstly, Network Management. Every bank has a team that negotiates terms and conditions with Nostros and Custodians. That is the first line of defense; make sure you know exactly what you are paying for and don’t pay for anything you don’t need. The second line of defense is billing. Do you actually control and check that what you were charged for is what you agreed to? Invariably, the banks will direct debit fees from your cash account. Sometimes there is some advance warning, sometimes not. Sometimes, this latter part is handled by an Expense Management team, i.e. not the folk who negotiated the deals.
The poster child for how to mess this up will remain anonymous. The story though is too good a case study not to use. This institution decided to expand its investment banking activities massively. As a result of both market conditions and their supplier’s own circumstances at the time, this bank had a massive price increase imposed on it by its service provider; a hike from some $2.50 a ticket to $10. This is unusual, as prices in transaction banking normally only move one way, down. Outraged, the Network Management team swung into gear. Some chest beating was involved with various insiders proclaiming they had a great relationship with the provider and would fix this. Soon it was announced that the price had been really successfully re-negotiated down to just $5 per ticket. High fives, self congratulation and savings headlines all round. Twice as much as before, but 1/2 of the worst case. It was decided to move to self-clearing since with volumes growing and that price hike, a project to develop capabilities in this space was a proverbial “no brainer”. It appeared eminently doable to sort out a do-it-yourself service for at most $2.50 tickets. With volumes rising steeply, there were lots of potential savings. Some 18 months later, when that self-clearing project was implemented, it came to light that the actual cost per ticket from the supplier was $7.50 a ticket; the supplier was charging 50 cents per status message and for about five per trade. The only business I can think of with better margins is McDonalds on its coke; the syrup costs less than a penny a time. The amazing thing was that the Network Management team had been proud of the $5 fee. They had either not read, or not understood the fine print. And, the saddest part is they had no idea that they were receiving these messages, which were going into the virtual trash can. Every month, the bank account reconciliation folks were reporting that there was a debit on the account for fees and the Expense Management crew were passing a ledger adjustment to reflect the charge. This was going on unchecked for longer than that Rogue Trader’s shenanigans at UBS. They had been spending at the rate of some USD 10 million per year for services nobody used. Now, on the flip side, those who did the self-clearing project looked twice as smart; they could show savings of 20 million a year based on the higher cost. Happy days.
Lessons Learned: Banks are not very efficient? Lame; that is straight out of the Ministry of the Bleedin’ Obvious and no more of a shock than a headline that says “Rugby Players Drink”. As ever, three things to ponder here:
Read the fine print; make really sure that you are not paying for anything that you do not want or can use. Read it again.
Skin in the game; those who negotiate the prices or fees should process them.
What gets measured, gets managed; there should be two levels of controls. Both a budget level one on nominal spend, the actual amount of dollars spend and, just as importantly, a check of actual vs. expected ticket price.
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.