CMOS for Bilaterals? A case against
Updated: Apr 18, 2018
In January's The Water Report, the publication teamed up with CGI for a thought piece on bilateral interactions. I found it a good, interesting article: it describes the state of play objectively, draws on some diverse views and gives a good summary of the main issues. Basically, the authority we have come to expect from both sides, especially with CGI being the delivery partner for CMOS.
But it is the premise of using CMOS as the basis of a central portal that I think needs a little qualification. Of course, even if market opinion did go against using CMOS for bilaterals, the rest of CGI's vision for a central portal could yet be the best for the market. I happen to be an admirer of MOSL and CGI's work on the central system, it's just that most of my points would apply to any CMOS, not just this CMOS.
Basically, my view is that 'CMOS as portal' has these downsides:
Opportunity cost - namely where something needed for smooth bilateral interaction is not possible because it happens not to fit with how CMOS itself is designed. There are some key innovations needed to mesh the differing approaches in the market together into a coherent whole without creating major re-work.
Constraint cost - namely where CMOS introduces other inhibitors because of its central position in the market, such as its deliberate change agility. Right for CMOS may not be right for these other interactions. The governance framework gets muddied by integrating these interactions with CMOS.
Scope cost - namely where the range of what can be covered by a bilateral portal gets limited by the scope of where MOSL is prepared to go, whether as a function of its Articles or just a discomfort amongst MOSL and its members. MOSL's is a key voice, of course, but it becomes more strictly invested with the coupling of bilaterals to CMOS.
Access constraint - namely where the range of what the portal can cover is limited by who can or should access CMOS (e.g. why shouldn't developers get limited access to a central solution and also benefit from a common approach across wholesalers once Section A comes into play [or even to enable Section A in the first place]?).
A blunt instrument - namely treating all LVI users the same; all HVI users the same - and not allowing nuance, necessarily. Flexibility is crucial to allowing trading parties to calibrate in detail how they operate to suit their process/IT preferences, process by process. Paying for the solution may be similarly blunt and bundled up with overall CMOS costs, regardless of an individual party's functional usage.
A dis-benefit of integrating to CMOS data - there are some 'happy path' efficiencies of integrating the data for sure but not all the consequences are positive. We should keep in mind that CMOS is the common language of the market but not the truth, necessarily. There is latency both in terms of getting updates into CMOS and for parties to respond to change notifications they receive so we may see spurious exceptions. Correcting data also starts to overlap with other Code processes, which still need to follow their course. It's neat to be able to flag those 'on the fly' but some companies may be able to do that within their own CRM systems anyway. Pre-population also only benefits those using LVI.
A dis-benefit of harmonising the end-to-end process - again, there are some clear pluses from joining the operational and market processes. Introducing that will create change of its own and in any case may not be needed for all bilateral use cases. The ability to report on performance is good - even if just as a sense check to what companies are submitting independently to MOSL - but a central solution doesn't have to be in CMOS to achieve that.
There's an implementation aspect to the constraint cost, also: putting change into CMOS requires all parties to define the future then build toward it. That can create an impasse that underpins why a central solution has yet to be realised. I think there is a more agile way to build towards solving some of the inefficiencies sooner, perhaps even with a subset of parties, then bringing others along. That way, the market can start to solve other industry issues - like making meter reading more efficient or simplifying incident notifications - while also solving the exam question around bilaterals.
I believe the fundamental premise of the TWR/CGI article is correct: that a central solution is needed. Exactly what that solution looks like is critical to striking a good balance between respecting progress already made by some parties with developing the flexibility to adapt in the future.