The staple diet of the Operations professional is reconciliations. Other terms might be used, such as exception management or non-STP, however under the hood it is all about reconciliation; what did we expect to happen or be the case, the plan and what actually happened or is the case. It is those reconciliations that ensure Control, the first in what I consider the holy trinity that needs to be balanced to run a bank properly: Control, Capacity and Cost. Without the first, the other two do not really matter. A recent discussion on some new rec needs highlighted to me how important it is to get the basics right.
Independent Function
The team performing responsible for recs and monitoring the resolution of breaks must be independent of the people doing the work. In a standard operations environment, the mainstay reconciliation is the ledger vs. a statement from outside the firm. The recs team has to be completely independent of the people making entries to the ledger. In most cases, the recs are automated, for example using industry standard tools such as Smartstream’s TLM or SunGard’s IntelliMatch and the results are presented directly to the owning departments. The control over those tools and responsibility for any configuration or programming also has to be independent of the owning departments. Typically there is a department called “Operations Control”; in order to be effective, I firmly believe that this department has to report in to Finance and not to Operations. The goal is to ensure control of operations and not for operations to do the controls. And the same applies to the tools; it is quite likely that a situation develops where an Operations area needs to help itself by doing a rec and it might help itself some more by using an end user tool like Excel or something more powerful. As soon as the need is identified and version 1.0 built, the ownership of the tool has to go into the Operations Control function.
No false positives
The perfectly configured rec will compare one item on the ledger to one item on the statement. Then every mis-match is a break. Simple. There may be cases, where that is not the case. I was recently discussing a rec need for a new business. The rec was needed to ensure that certain assets that a client held and pledged to its clearing broker. A so called Third Party pledge. This is something that, at least outside the US, is likely to become increasingly in demand as a result of the need to post margin to support derivatives clearing. So, the clearing broker will likely find itself receiving a statement listing more assets than its client has pledged and maybe even situations where the holding in a particular security is greater than the ledger amount. This happens when the system producing the statement does not have the “memo seg” functionality typical in US broker-dealers, where a holding of 100 Apple shares can be sliced (sic) into 4 that are in memo seg and 6 that are unencumbered. If you are holding a pledge on the 4, you would like a statement showing 4. But failing that, a statement showing 10 would be next best. The statement might also tell you about 100 IBM shares that you are not interested in. The resulting rec needs to be custom fit to account for these special cases: statement, no ledger and statement > ledger. In this situation they are both “false positives”. In discussions about this need, I was told by somebody that all that could be done was a standard ledger to statement rec and if there were breaks that were false positives, I would just have to ignore them. Possible yes, sensible no. Leaving false positives on the rec means there is daily, perpetual noise in the rec. Therein lies a real danger; somebody looks at the noisy rec and assumes that the breaks are “the usual suspects” and simply misses the fact that there is a genuine break. Then the shit hits the fan.
Aged Breaks
Breaks can and do happen. Now it might happen that there are a large number of breaks on a day, because a whole process has broken down, the typical challenge is to ensure they do not age. My advice is to use three buckets: new, 1-7 days, 7+. If you want to be more granular, add a fourth and have 2-3 days, 4 to 7 and then 7+. If you are a manager, you need to really care about the 7+ bucket. Anything in that bucket needs a lot of explaining.
Lessons Learned: Good discipline is a requirement. Equally important are good tools, specifically ones that ensure that breaks are correctly identified, false positives are filtered out and exceptions are presented to users and managers in appropriate age buckets.
Share on:
