RA and Banking

While working with a Commercial bank in South Africa and Namibia I tried to draw a comparison between revenue assurance in a telco environment and how I imagine it could be done in a banking environment.  Take note of the reference to “tried” here. I have to warn the readers that engaging with a commercial bank to roll out new banking infrastructure in Africa during these financial times takes some doing. There was very little energy left to day dream about revenue assurance.

Limiting this observation to the process of product and system implementation, what is the difference between implementing Amdocs, Singl.eView and Flexcube? Not much except that Flexcube is implemented in the banking industry and not in a telco.  

System stability

A headache for any RA team is tracking usage through unstable systems. Inevitably the finger pointing ensues between 2 departments without either taking accountability for system integrity. When the platform integrity was not assured during the implementation of the system, it is almost impossible to rectify this during production without at least several scars.  The bank’s implementation of the core banking system was no different.  It did however make me realise how often the Revenue Assurance Department picks up the accountability to ensure that system development staff is following Project management 101 principles.

System architecture

I have yet to work for a telco that has the entire system architecture documented in enough detail to follow the basic flow of data. The bank experience again was no different. I did OD work for banks before but this was the first time I was involved in banking operations. As a novice it would have been nice to work through the operating model down to a functional architecture and then consider how the system architecture would support or enable the business objectives. Only a small number of people understood what I was trying to do and I was left again realising the huge gap between technology and human capability. The gap just widens.

Solution design

Many organisations regardless of the industry are forced to do solution design in parallel. This is achieved by continuing work in isolation with the intention of integrating later. The designs are based on assumptions and generally high-level directives usually in the form of an MS Powerpoint slide presented to Exco.  We build the solution from multiple points working in multiple directions and become confused when they don’t tie up.  This again is not telco specific. Banks do it too.

Developing specialised functionality in-house

We are familiar with a few telcos which are forced to (or elect to) design and build their own telco systems, be they an RA automation / verification tool or strangely, a rating and billing engine. I am not a fundi of banking payment systems, but I felt the business architect’s pain when he wrestled with the concern of underlying functionality. Although he did not specifically mention complete and accurate billing, this is what he meant. I guess the term “complete and accurate” is telco specific lingo but the concern is industry independent.  The sheer size and complexity of inter bank, inter country payment settlement would make me think twice before embarking on the in-house development of a payment settlement solution.  The closest I could come to offer help was to suggest we get a system auditor in and that took some explaining.

Project management and communication

Coming back to project management, it is alarming to follow the demise of large programmes (and those chunky budgets gone) due to ineffective project and programme management. The Governance and Internal Audit guys make plentiful visits to check up on the health of the programme but somehow the message misses its audience or perhaps the audience has other realities simply not understood by reality-protected desk job executives…..executives meaning glorified middle management without subordinates.

Product development

Understanding your market and their appetite for certain products is vital to the costing and offering model. Similar to what we know as margin analysis, we would also look at the profitability of certain segments or go further to inform subscribers of more suitable packages to optimise their “bang for the buck”. Products working for one country may not necessarily work in another country and this is not a function of GDP or disposable income. There are nuances to what you sell, which can make or break the bottom line.

On the upside

The volume of customers and complexity of parameters per product do not come close to a telco I worked with so far. Yes, we do have the difference in the size of countries I am referring to here but still, once operational the speed and size of change do not require fulltime revenue assurance people onboard. The company involved has an awesome Fraud department with near real time monitoring of transactions. This knowledge and infrastructure can be replicated into Africa. You can also train a businessperson in the basics of banking without having to turn them into technical superbeings. It is one of the few companies where procedure manuals actual mean something.

As to how they ensure that service charges and interest are calculated correctly, the answer was “I am not sure”. It appears that the customer relationship management is adequate to know your assigned client accounts well enough to know if there is a problem on the account or not.

Personal reflection

A famous quote in impoverished African countries is “Complaining with a white bread under the arm”. This refers to valuing or appreciating what you have. Here is an observation from the revenue assurance starved (moi). We often complain about working with telco execs that battle to grasp the basics of revenue assurance. We spend days dissecting their uninformed decisions and their inability to zoom in and out. When you are unfortunate in the nature of assignment the gods designed for you and you exchange the RA world for something else, you come to miss those dumb executive decisions. You try for a while to marvel in other’s experiences but somehow this is like trying to share a romantic meal for two with your parents.  Value the opportunities you have and help to build this profession into something that other industries will want to copy.

Güera Romo
Güera Romo
Güera has many years of experience in business transformation in the engineering, defense, government, banking and telecommunication industries. She has experience in mergers & acquisition, rightsizing, re-deployment of personnel, business process re-engineering, system selection and implementation.   Güera holds a BCom Hon (Industrial and Organizational Psychology) degree and is currently pursuing a doctorate that draws on her practical experience of developing human resource capabilities within large corporations.

5 Comments on "RA and Banking"

  1. Tremendous post, Güera. I’m glad you found time to reflect and compare your recent banking project to your telco experiences.

    I find it fascinating how many similarities you found between banking and telecoms. I have a question for you to think over and would love to hear what you think. Purely speaking as a customer, I have never found any errors with my bank statements, but over the years I have maybe seen a dozen mistakes on my own personal telecoms bills. Starting out as a financial auditor, I soon learned that the reconciliation of a company’s accounts to cash – effectively to the information represented on bank statements – is the cornerstone of an audit. I dare not imagine what a financial audit would be like if you could not trust the numbers from the bank. Based on these various experiences, and comparing them to what I have seen of the telco world, I have always had a firm belief that the transactional information presented by banks to customers was significantly less likely to be in error than the equivalent information presented by telcos.

    My question comes in a few parts:

    First, do you agree with my opinion that telco statements/bills are more likely to contain errors that banking statements?

    Second, if you do agree with me, what is the reason for the difference in error rates – does it come down to what you observed about volumes of customers and complexity of products? If you do not agree, and you think banking transactional data integrity is on a par with telco transactional data integrity, what implications do you draw for the customer’s perception of both industries (mine included)?

    Finally, what if the telco industry can learn from the finance industry about how to improve integrity, what would be the first and most important lesson it should learn?

  2. Lee Scargall Lee Scargall | 17 Feb 2009 at 7:28 pm |

    On a similar theme, anyone who regularly travels on the London Underground (LU) and also works in revenue assurance may have spotted the similarity with the telecoms industry.

    Like telecoms, the LU generates a large amount of transactions with relatively low monetary value. But the similarity does not just end there. The LU charging methodology has pre-pay cards, more commonly known as Oyster cards, which can be topped up / reloaded. There’s also peak and off peak charging periods (time bands), and zonal charging depending on the origin and destination. And if I make several trips on the same the day, then I pay a flat rate. Hmm, sound familiar?

    If I were a salesman at one of the RA software suppliers, then I’d be taking Tim O’Tool (CEO at LU) out for lunch.

  3. Hi Guera,

    I was waiting for some time to hear about a RA practitioner talk about banking systems, and your post did not disappoint.Some of the key sentences for me from your post are :

    a) “You can also train a businessperson in the basics of banking without having to turn them into technical superbeings. It is one of the few companies where procedure manuals actual mean something.”

    b) “It appears that the customer relationship management is adequate to know your assigned client accounts well enough to know if there is a problem on the account or not.”

    c) “We build the solution from multiple points working in multiple directions and become confused when they don’t tie up.”

    The reason why I specifically love these three points is because they highlight some key concerns that everyone in the RA field has been grappling with for some time.
    For example, we often wonder about the pre-requisite skill sets for a RA professional. We often wonder about the level of practical monitoring of customer information and identifying pain-points.

    And my personal favorite…we create/envision disjointed systems in silos, and later wonder where we went wrong (thinking along the lines of traditional networks being upgraded to NGNs).

    I’m just glad to get this insight into banking systems, because there is a lot that we can learn as RA practitioners. I personally agree with Eric about the banking statements being error-free as compared with bills from my operator. Although I agree with you regarding volumes of transactions being lesser in banks as compared to telecom operators, I also believe in the value of an efficient and strong process. Volumes to me are a secondary concern. In this day and age of super-automation and heavy-duty hardware, crunching volumes is not the issue.

    The issue still resides in an incomplete RA process. To illustrate my point, if we are able to do something simple, like a file sequence validation with well-documented business checks in place, then it shouldn’t matter if I have 10 files or 10,000 files. The checkpoints we have enforced should still hold good. The only thing we might require is a system that helps the analyst to automate such large volume data-crunching.

    And I was particularly interested in Lee’s post. It seems to be a near-perfect mirror of a telecom scenario. However, the underlying support system would be far simpler in comparison to the typical telco’s infrastructure (or so I believe).

    I think Einstein got it right when he said – “No problem can be solved from the same level of consciousness that created it.”

  4. Yes, I do agree that bank statements contain fewer errors than telco bills. This is my personal experience too. Errors on my bank statement are always corrected within 24 hours without me having to contact the bank, log a query and follow it up. This says something about the process of assurance being followed by the 2 parties.

    I thought about the complexity of a bank transaction vs a mobile transaction. It is perhaps not accurate to say that telco is more complex than banking. What is the difference between an international fund transfer/investment and roaming call settlement? Similarly a withdrawal at an ATM and sending an SMS. An ATM withdrawal can be at the same bank ATM or another bank’s ATM. Same with SMS. It could be on-net or off-net. In telco we would deal with interconnect charges but the bank must have something similar in place to assure accurate settlement. I think we are dealing with similar complexity. I have made contact with a few banking people whom I would like to soundboard these questions and get a better idea of a typical banking solution architecture. We may be looking at a similar number of systems involved.

    There may be a difference in volume but it would be interesting to compare stats. I do not transact on my bank account every day but use my cell phone at least 10 times. But then again, I have 1 fixed line, 1 mobile voice and 1 data service but 8 banking products. I agree with Ashwin about the number crunching machine available to deal with the volume. If the banking industry has automated control point verification then volume is really not the reason why they issue more accurate statements.

    I think the answer can be found in the process integrity, product parameterisation and staff compliment & competence. My observation while working with Investment banking staff is that they all followed the same process, used the core banking system (transactional capturing) in the same way. Let me qualify this. I implemented a new operating model for this business function nationwide and visited a number of regional offices during this period. Each office regardless of location, did everything the same way. If I compare this to a recent mobile call centre I was involved with, the call centre agents could not do this. Half of them did not know how and the other half did as they were trained by a predecessor using a “buddy-training-system” or over the shoulder training. So there is no consistency or uniformity in the quality and content of the training. Garbage in, garbage out. Data integrity starts with that agent or bank admin person capturing the transaction.

    We could take this discussion to performance management. It is much easier to performance manage the banking employee if he/she repeatedly capture an investment transaction incorrectly but it would be more difficult to reprimand somebody who has not had formal classroom training and who were not monitored after the training for adequate knowledge absorption and application. Perhaps something can be said for the technical nature of telco processes but only to a certain degree. A Call centre agent does not need to know as much as an RA analyst needs to know about the process but they must know their products and what features can be activated with this service. A telco product has more permutations and user definable parameters than a banking product.

    This brings us to system integrity. The scenario about the feature activation refers to an operator where the retail billing system did not block certain features that were not available on the client selected package. The agent did not know any better, so if the client asked for a 200 sms bundle to be added to a data service, the agent selected it and processed the order. Needless to say it could not be activated in the network however the return message to the retail billing system was “successfully activated” because the data service was. Agent does not check the detail, he just sees “successfully processed” and hops onto the next client. An MRC is raised for the sms bundle but the client does not have the service. I did not experience this ambiguity in the banking system. Each product was properly supported by the frontend functionality and a client could not ask for something different. At most the Client Relationship Manager could change the interest rate within his/her delegation and this had to be approved in writing by the Branch Manager. There was a specific field where the “change percentage” would be captured to be recalculated with the system generated percentage (1% lower would be captured as -1). I have limited experience with the implementation/configuration of banking products but I would be surprised if the product catalogue looks anything like a telco’s.

    I am trying to get stats on staff compliment. I noticed that the investment banking staff ran listings every morning which they would review for all transactions of the previous day. Each person was doing his own revenue assurance checks. 100% checking not sampling of telco statements every so now and then we have some time available. During month-end they were busy but these tasks were compulsory and you asked somebody else to assist if you could not manage. Each person was held accountable for errors and could be fired on the spot. Imagine firing the Call centre supervisor for incorrect bills. Implement that and you would see dramatic improvement of telco bills.

    So to answer Eric’s question on what we can learn from banks, it is accountability. Telco managers do not take accountability. They fight in project meetings about who the business owner of the wholesale billing system replacement project should be.

  5. It’s a while since you posted about comparing banking to telecoms through the prism of RA, but this story about a bank incorrectly calculating interest is very relevant:


Comments are closed.