JULY, 2014
by GEORGE BOLLENBACHER
With the compliance date for the Volcker Rule (VR) just under a year away, most banks are fully involved in getting ready, but their technology vendors may be way behind, if they are even aware of its implications for their products. Unless tech companies get on the stick, banks may find that many of their compliance efforts are compromised, if not ineffective.
First Things First
To understand the VR’s impact on technology, we first have to understand its structure. After exempting certain securities (US governments, munis and foreign sovereigns), the rule says that no US bank – no matter how small – can trade as principal in any other instruments unless it has an exemption. In addition, the determination of whether a trade is exempt is up to the bank’s examiners, and will be made after the fact. The OCC has recently issued a guide for examiners, and the five relevant agencies have also issued a set of FAQs which give us some insights into how the rule will be enforced. When we read them with the rule itself and the preamble, we get a clear picture of what is needed.
To begin with, every trade a bank does in a non-exempt instrument will have to be defensible to an examiner, possibly years after the fact. Needless to say, banks are worried about both intentional and inadvertent violations, which could get them into hot water with their regulators, and are placing a premium on automated ways of: 1) linking trades to exemptions and 2) alerting management when a potential violation occurs. Those two requirements are where technology comes in.
The Basics
There are four main exemptions, all with different justifications and requirements. They are: 1) liquidity management, 2) underwriting, 3) market-making and 4) hedging. Since a single trading desk may execute trades under more than one exemption, and more than one desk may trade in the same instrument, the first requirement is a field to identify which exemption applies, such as (L)iquidity, (U)nderwriting, (M)arket-making, (H)edging, or (N)/A (for exempt securities). We should note that two trades in the same instrument might have different exemption codes. Making this a required field would prevent trades being entered without an exemption, and maintaining a list of exempt securities would allow the booking system to verify that N coded trades are actually in those securities.
There are two other exemptions that need to be addressed – repo and securities lending – but these trades are usually done in special systems and may not need the linkage in the previous paragraph. However, examiners may require that repo and sec lending systems have built-in functions, such as requiring a two-sided trade for repos, in order to prevent a bank from using those systems to book prohibited trades.
The rules, instructions, and FAQs all spend considerable time on the definition of a trading desk, which is “the smallest discrete unit of organization of a banking entity that purchases or sells financial
instruments.” The FAQ allows trading desks to book trades into more than one legal entity, but “if a single trading desk books positions in different affiliated legal entities, it must have records that identify all positions included in the trading desk’s financial exposure and the legal entities where such positions are held.” Thus each trade will probably have to identify both which legal entity it was for, and which trading desk executed it.
Finally, the rule places a heavy emphasis on policies and procedures (P&Ps), and the examiners will be expected to judge the permissibility of individual trades primarily on whether they follow the P&Ps. There are different P&Ps for each exemption, but they all require three things: 1) specification of allowed instruments, 2) specification of which desks may trade them, and 3) position and risk limits for each desk. So another enhancement for trade booking systems will be checking that 1) the instrument is allowed, 2) that the right trading desk is doing the trade, and 3) the trade leaves the desk within its position and risk limits.
Liquidity Management
Although this exemption has generated the least public scrutiny, it is important because it applies to pretty much any US bank, unless it restricts its liquidity portfolio to exempt instruments. The liquidity exemption requires a management plan that specifies: 1) which instruments can be purchased, 2) the aggregate size of the portfolio, and 3) that the purchase is “not for the purpose of short-term resale, benifitting from actual or expected short-term price movements, realizing short-term arbitrage profits, or hedging a position taken for such short-term purposes.” The rule specifically calls for “internal controls, analysis, and independent testing to ensure that the purchase and sale of securities” comply with the P&Ps, which function would logically fall under the various trade booking systems.
The typical logic process for entering a liquidity purchase would then be:
If exemption = L,
If instrument is on allowed list,
If desk is allowed under exemption L,
If aggregate position after trade < limit,
Then allow trade,
Else return alert.
One additional check, applied to sales under the L exemption, would be whether the total number of sales in a specified period exceeds a set limit, defined either in absolute amount or a percentage of the portfolio. This would alert management that examiners may question whether the portfolio is being managed to benefit from short-term price movements.
Underwriting
In addition to the P&P requirements above, the underwriting requirement makes the first mention of something that will also appear in market-making – the “reasonably expected near term demand” or RENTD. The rule, and the examination instructions, place a heavy emphasis on showing that position sizes conform to the RENTD at the time. The examiners’ instructions indicate that the RENTD should be
based on a “[d]emonstrable analysis of historical customer demand, current inventory of financial instruments, and market and other factors regarding the amount, types, and risks of or associated with financial instruments in which the trading desk makes a market, including through block trades.”
Obviously, the RENTD can change over time, particularly when instruments are new to the market or fall out of favor. Thus the bank will need to keep a record of its RENTD analysis at the time of the trade, probably in a document management system. The ideal arrangement would then be for the trade booking system to have at least one additional field for a reference to that RENTD analysis. For trades where the exemption code is U or M, having that field empty should raise an alert.
Finally, the underwriting exemption requires that the P&Ps specify the “[p]eriod of time a security may be held.” Any position management system used for underwriting should have an alert function if positions with an exemption code of U remain on the books for significantly longer than the P&P holding period.
Market-Making
The market-making exemption has received the most press coverage and commentary, largely because it will be the most difficult for examiners to verify. Partly for that reason the rule specifies seven metrics that large banks must start capturing and keeping as of July 1, 2014. They are:
- Risk and Position Limits and Usage;
- Risk Factor Sensitivities;
- Value-at-Risk and Stress VaR;
- Comprehensive Profit and Loss Attribution;
- Inventory Turnover;
- Inventory Aging; and
- Customer-Facing Trade Ratio
We are not going to go into the tech requirements for capturing and storing the metrics here, but banks will have to be able to link trades and positions to those metrics after the fact, in case an examiner questions the exemption. Of more value, though, would be alerts in cases where the metrics suddenly deviate from acceptable norms, or in cases where a trade is at odds with the metrics. As with underwriting, alerts are needed where the trade has no link to a RENTD document. And, of course, the combination of instrument and trading desk needs to be checked against the P&Ps. The examiners’ manual also refers to the holding period as a criterion, so the bank may want an alert where a position with an exemption code of M is unchanged for an extended period, say a month, an event that should reflect against the inventory turnover metric.
Hedging
Of all the exemptions, hedging will require the biggest changes to a bank’s business processes and technology. To begin with, the only things that can be hedged are “the specific risks to the banking entity.” So, no hedging of positions or portfolios, only risks. In addition, the rule requires “analysis, including correlation analysis, and independent testing designed to ensure that the positions,
techniques and strategies that may be used for hedging” are correlated to the risk. Finally, the rule requires that the hedge “[i]s subject to continuing review, monitoring and management” throughout its life.
We can see that any position where the exemption code is H will need a link to the documentation of the risk being hedged, perhaps using the same field used for the RENTD link in underwriting and market-making, since RENTD doesn’t apply to hedging. In addition, the rule requires documentation of “[t]he specific risk-mitigating strategy that the purchase or sale is designed to fulfill,” so that additional link will be needed in the trade record as well, unless the risk and the strategy are contained in the same document. Given that there is a history of banks or traders claiming that a trade was a hedge when it wasn’t, a few additional checks may be needed, such as a large number of positions referring to the same risk documentation.
What can’t be hedged? The examiners’ manual indicates that the following are not hedges under the exemption:
Reducing risks associated with:
the bank’s assets or liabilities generally; or
general market movements or broad economic conditions;
Profiting in the case of a general economic downturn;
Counterbalancing revenue declines generally; or
Arbitraging market imbalances unrelated to the risks resulting from the positions lawfully held by the bank.
Other than that, the rule allows the hedging of any banking risk, as long as it is quantifiable and correlated. Given the wide range of risks that could be hedged, the correlation function might be fairly complicated, and monitoring that correlation might be a stretch for the usual bank technology. This is an area where creative technologists might capture a significant market share and profit.
Additional Implications
Of course, everyone knows the myriad of separate systems that a typical bank runs in its trading businesses, and this part of the VR doesn’t promise to simplify that any. Banks will have to determine where and how they will store the documentation that the VR requires, and tech vendors will probably have to build interfaces, calls and APIs to wherever it is stored. In addition, banks will have to determine how important automated monitoring and alerts are to them, and be prepared to pay for such functionality from vendors or build it themselves.
In the end, solving the technology hurdles inherent in the proprietary trading part of the VR will be a group effort, and should probably include the regulators, to make sure any development will satisfy their mandates. At this point, though, if banks aren’t actively engaging their tech vendors with a set of requirements, they should expect some unpleasant surprises come next spring.
