Reading the announcement that Huawei will implement an upgrade of cVidya’s fraud management system in a Venezuelan telco, I was struck by one sentence in particular:
To simplify deployments, Huawei has pre-integrated cVidya’s FraudView with its leading CBS R5 Convergent Billing System and network infrastructure.
On one level, this makes perfect sense. An FMS is just software that analyzes a lot of data. The data is obtained from sources like the network and the billing system. All of these systems run software, so anyone implementing or upgrading these systems might as well install the FMS software at the same time as they install other things. And if the supplier knows they will be installing different things at the same time, they can reduce the burden on the customer, and on the project, by doing some checks to ensure everything works together before the installation begins. So there are lots of advantages to taking this approach. But…
What surprises me is the casual way the pre-integration is presented as a benefit, when I expect some customers would object to this arrangement on principle. I am not saying I share those principles; my preference is to judge each case individually, rather than formulating a general rule and applying it to every instance. In that respect, I sympathize with arguments that say if you are worried about Chinese suppliers compromising the security of a network, you should test the products they supply, instead of simply prohibiting the vendor on the basis they are Chinese. However, gaps in the data made visible to the telco are a contributory cause of fraud. Having everything integrated before deployment begs a question: is the customer being too trusting? Is the customer doing everything they should, to assure themselves the systems work as they should? The telco should be conscious of the possibility that they may buy integrated systems that fail to capture all the relevant data needed to identify fraud. This issue may be disguised or exacerbated by over-reliance and over-confidence in the output from the FMS, when more scrutiny should have been directed towards reviewing the adequacy of the data input to the FMS.
This matter is not just an academic talking point. As a consultant, I was once employed to mediate a contractual dispute between a vendor and their customer, after the telco felt their explicit requirements about supplying independent data had been ignored by the vendor. I will not comment on the conclusions I reached in that case, but I will say that only a terrible consultant would ignore the concerns of a customer. We never eliminate risk, and can never expect to, so there will always be some compromises. However, it is right and proper that the telco should identify every possible risk, including the risk of insufficient independent data to verify that their objectives have been satisfied, before making a decision as to what degree of assurance is needed to mitigate that risk.
What strikes me here is that I can think cooly about this example because it concerns a pre-integrated FMS, when I know that other people’s tempers would quickly rise if we were discussing a pre-integrated revenue assurance system. Both fraud managers and revenue assurance practitioners need to be conscious of threats and failings that are internal to the telco. However, because fraud is perceived to be driven by external actors, sometimes the fraud management community can be reticent to discuss what needs to be done to assure themselves that everything internal to the telco is as it should be. An RA manager, in contrast, may be quicker to raise concerns about segregation of duties, or independence of systems, in an example like this. Put simply, RA systems are usually conceived to be checking if the network and back-end systems are behaving as they should, or if they contain bugs which cause leakage. From that perspective, there is more obvious reason to be suspicious about paying a vendor to implement network and back-end systems, whilst also trusting the same vendor to deliver a pre-integrated system which is supposed to check if the network and back-end systems are working correctly.
I am not authoritarian about how to implement systems or mitigate risks, though I know other people have much stronger views about these kinds of issues. I can certainly think of examples of people who assert that assurance systems must always be independent… but who may go quiet at other times. Not knowing the specifics of this case, I cannot make a judgement about the scale of the risks that the Venezuelan telco may or may not be taking. However, I know that other people would make a judgement, and that interests me. Perhaps Commsrisk should run a poll on this issue, to see if it divides people like some of our previous polls have. And I would love to hear from people who have strong opinions, one way or other. We could even set up an online debate, by encouraging two champions to engage in a virtual dialogue. Debate helps people to think about all the issues. That is why good risk managers encourage debate – by which I mean real debate where different points of view are expressed, not a sham which is engineered to give the ‘correct’ result before the first word is even spoken.
If there is a trend toward the pre-integration of risk mitigating software with networks and back-end systems, professionals should debate the advantages and disadvantages of such an approach, so vendors can take appropriate steps to respond to any genuine and wide-spread concerns. As my opinion sits in the middle, I welcome others to step forward and take the stage…