Spreadsheet Risks in Banks

No other industry perhaps handles such large volumes of critical financial data more than the banking industry. For decades now, spreadsheets have become permanent fixtures in the front-line reporting tool sets of banks, providing organised information when and where needed.

But as banks enter into a period of heightened credit risks, elevated levels of fraud, and greater regulatory scrutiny, many are wondering if continued reliance on spreadsheets is a wise decision for banks today.

The downfall of Lehman Brothers which eventually led to its filing for Chapter 11 bankruptcy protection on September 15, 2008, served as a wake up call for many institutions across the globe to make a serious examination of their own risk management practices. But would these reforms include evaluating the security of user developed applications (UDAs), the most common of which are spreadsheets, and putting specific guidelines as to when they can – or cannot be – used?

Banks and Spreadsheet Use

Banks have been known to utilise spreadsheets systems for many critical functions because most personnel are well-acquainted with them, and the freedom of being able to develop customised reports without needing to consult with the IT department offers flexibility and convenience. In fact, more than having a way to do financial budgeting and analysing customer profitability, even loan officers and trade managers have become reliant on spreadsheets for risk management reporting and for making underwriting decisions.

But there are more than a few drawbacks to using spreadsheets for these tasks, and the sooner bank executives realise these, the sooner they can adopt better solutions.

General Limitations

Spreadsheets are far from being data base systems and yet more often than not, they are expected to act as such, with figures constantly added and formulas edited to produce the presumably right set of reports.

In addition, data integrity is always a cause for concern as most values in spreadsheets are entered as manual inputs. Even the mere misplacement of a comma or a negative sign, or an inadvertent ?edit? to a formula can also be a source of significant changes in the outcome.

Confidentiality risk is also another drawback of the use of spreadsheets in banks as these tools do not have adequate?access controls to limit access to only authorised individuals. Pertinent financial information that fall into the wrong hands can lead to a whole new set of problems including the possibility of fraud.

Risks in Trading

For trading transactions, spreadsheets can prove to be of immense use – but only for small market volumes. As trade volumes increase and the types vary, spreadsheets are no longer a viable solution and may likely become more of a hindrance, with calculations taking longer in the face of bigger transaction amounts and growing transaction data.

And in trading, there is always the need for rigorous computational functions. Computing for the Value at Risk (VaR) for large portfolios for instance, is simply way beyond the capabilities of spreadsheets. Banks that persist in using them are increasing the risk of loss on those portfolios. Or, they can be opening up?opportunities for fraud?as Allied Irish Bank (in the case of John Rusnak – $690 million) learned the hard way.

Risks in Underwriting

Bankers who use spreadsheets as their main source of information for underwriting procedures also face certain limitations. Loan transactions require that borrowers? financial data be centralised and easily accessible to risk officers and lending officers involved in making decisions. With spreadsheets, there is no simple and secure way of doing that. Information can be pulled from different sources – individual tax returns, corporate tax documents, partnership documents, audited financial statements – hence there is difficulty in verifying that these reports adhere to underwriting policies.

Spreadsheet control and monitoring

Financial institutions which are having difficulty weaning themselves from the convenience and simplicity that spreadsheets offer are looking for possible control solutions. Essentially, they want to find ways that allow them to continue using these UDAs and yet somehow eliminate the?spreadsheet risks?and limitations involved.

Still, the debate goes back and forth on whether adequate control measures can be implemented on spreadsheets so that that the risks are mitigated. Many services have come forward to herald innovative solutions for better spreadsheet management. But at the end of the day, there really is no guarantee that such solutions would suffice.

More Spreadsheet Blogs


Spreadsheet Risks in Banks


Top 10 Disadvantages of Spreadsheets


Disadvantages of Spreadsheets – obstacles to compliance in the Healthcare Industry


How Internal Auditors can win the War against Spreadsheet Fraud


Spreadsheet Reporting – No Room in your company in an age of Business Intelligence


Still looking for a Way to Consolidate Excel Spreadsheets?


Disadvantages of Spreadsheets


Spreadsheet woes – ill equipped for an Agile Business Environment


Spreadsheet Fraud


Spreadsheet Woes – Limited features for easy adoption of a control framework


Spreadsheet woes – Burden in SOX Compliance and other Regulations


Spreadsheet Risk Issues


Server Application Solutions – Don’t let Spreadsheets hold your Business back


Why Spreadsheets can send the pillars of Solvency II crashing down

?

Advert-Book-UK

amazon.co.uk

?

Advert-Book-USA

amazon.com

Contact Us

  • (+353)(0)1-443-3807 – IRL
  • (+44)(0)20-7193-9751 – UK

Check our similar posts

How DevOps Could Change Your Business

Henry Ford turned the U.S. auto industry on its head when he introduced the idea of prefabricating components at remote sites, and then putting them together on a production line. Despite many industries following suit, software lagged behind until 2008, when Andrew Clay Shafer and Patrick Debois told the Agile Conference there was a better way to develop code:
– Write the Code
– Test the Code
– Use the Code
– Evaluate, Schedule for Next Review

The term ?DevOps? is short for Development and Operations. It first appeared in Belgium, where developers refined Shafer and Depois? ideas. Since then, DevOps became a counter movement against the belief that software development is a linear process and has largely overwhelmed it.

DevOps – A Better Way

DevOps emerged at an exciting time in the IT industry, with new technology benefiting from a faster internet. However, the 2008 world recession was also beginning to bite. Developers scampered to lower their human resource costs and get to market sooner.

The DevOps method enabled them to colloborate across organizational boundaries and work together to write, quality assure and performance test each piece of code produced in parallel.
DevOps? greater time-efficiency got them to market sooner and helped them steal a march on the competition.

There are many advantages to DevOps when we work in this collaborative way. Cooperation improves relationships between developers, quality assurers and end users. This helps ensure a better understanding of the other drivers and a more time-effective product.

Summary of DevOps Objectives

DevOps spans the entire delivery pipeline, and increases the frequency with which progress is reviewed, and updates are deployed. The benefits of this include:

? Faster time to market and implementation

? Lower failure rate of new releases

? Shortened lead time for bug fixes and updates

The Psycho-Social Implications of DevOps

DevOps drills through organization borders and traditional work roles. Participants must welcome change and take on board new skills. Its interdepartmental approach requires closer collaboration across structural boundaries and greater focus on overarching business goals.

Outsourcing the detail to freelancers on the Internet adds a further layer of opportunity. Cultures and time zones vary, requiring advanced project management skills. Although cloud-based project management software provides adequate tools, it needs an astute mind to build teams that are never going to meet.

The DevOps movement is thus primarily a culture changer, where parties to a project accept the good intentions of their collaborators, while perhaps tactfully proposing alternatives. There is more to accepting a culture than using a new tool. We have to blend different ways of thinking together. We conclude by discussing three different methods to achieve this.

Three Ways to Deploy DevOps in your?Organisation

If you foresee regular DevOps-based projects, consider running your entire organisation through an awareness program to redirect thinking. This will help non-participants understand why DevOps members may be ?off limits? when they are occupied with project work. Outsourcing tasks to contracting freelancers can mitigate this effect.

There are three implementation models associated with DevOps although these are not mutually exclusive.

? Use systems thinking. Adopt DevOps as company culture and apply it to every change regardless of whether the process is digital, or not

? Drive the process via increased understanding and feedback from key receivers. Allow this to auto-generate participative DevOps projects

? Adopt a continuous improvement culture. DevOps is not only for mega upgrades. Feedback between role players is paramount for success everywhere we go.

You can use the DevOps concept everywhere you go and whenever you need a bridge to better understanding of new ideas. We diminish DevOps when we restrict its usefulness to the vital role it plays in software development. The philosophy behind it belongs in every business.

Succeed at Transformation

Despite the pomp and fanfare associated with launching corporate transformation programs, in reality very few of them succeed. According to a recent report by McKinsey the success rate is pegged below 40%. In addition, the same research indicates that defensive transformations – those undertaken as part of crisis management – have lower chances of success than progressive ones – those launched to streamline operations and foster growth. However, adopting certain strategies, like setting clear and high goals, and maintaining energy and engagement throughout the implementation phase, can really boost the project’s success rate. A key aspect of business transformation is IT transformation. This can be attributed to the fact that significant business change is either driven or influenced by technological change.

So what is IT Transformation?

IT transformation is basically a holistic reorganisation of the existing technological infrastructure that supports the company’s mission critical functions. In essence, IT transformation is not all about effecting change for the sake of change but involves systematic steps that align IT systems to business functions. To appreciate this approach, it is important to explore current trends in the business world where human resource, finance and IT transformations are being carried out in unison. This is being done to develop strong corporate centres that are leaner, agile and more productive that enhance greater synergies across all business functions.

IT transformation inevitably results in major changes of the information system’s technology, involving both hardware and software components of the system, the architecture of the system, the manner in which data is structured or accessed, IT control and command governance, and the components supporting the system. From this scope of works it is evident that IT transformation is a huge project that requires proper planning and implementation in order to succeed.

Tips to Improve Success in IT transformations Projects

1. Focus on Benefits not Functionality

The project plan should be more focused on benefits that can be accrued if the system is implemented successfully rather than system functionality. The benefits should be in line with business goals, for instance cost reduction and value addition. The emphasis should be on the envisaged benefits which are defined and outlined during the project authorisation. The business benefits outlined should be clear, feasible, compelling and quantifiable. Measures should be put in place to ensure that the benefits are clearly linked to the new system functionality.

2. Adopt a Multiple Release Approach

Typically most IT projects are planned with focus on a big launch date set in years to come. This approach is highly favoured because it simplifies stakeholder expectation management and avoids the complexity associated with multiple incremental releases. However, this approach misses the benefit of getting early critical feedback on functioning of the system. In addition, the long lead times often result in changes in project scope and loss of critical team members and stakeholders. IT transformation projects should be planned to deliver discrete portions of functionality in several releases. The benefit of multiple release approach is that it reduces project risks and most importantly allows earlier lessons learnt to be incorporated in future releases.

3. Capacity of the Organisation to confront Change

As pointed out, IT transformations result in significant changes in business operations and functions. Hence it is important that all business stakeholders should be reading from the same script in regards to changes expected. In addition, key stakeholders should be involved in crucial project stages and their feedback incorporated to ensure that the system is not only functional but business focused.

FUJIFILM Cracks the Energy Code

FUJIFILM was in trouble at its Dayton, Tennessee plant in 2008 where it produced a variety of speciality chemicals for industrial use. Compressed-air breakdowns were having knock-on effects. The company decided it was time to measure what was happening and solve the problem. It hoped to improve reliability, cut down maintenance, and eliminate relying on nitrogen for back-up (unless the materials were flammable).

The company tentatively identified three root causes. These were (a) insufficient system knowledge within maintenance, (b) weak spare part supply chain, and (c) generic imbalances including overstated demand and underutilised supply. The maintenance manager asked the U.S. Department of Energy to assist with a comprehensive audit of the compressed air system.

The team began on the demand side by attaching flow meters to each of several compressors for five days. They noticed that – while the equipment was set to deliver 120 psi actual delivery was 75% of this or less. They found that demand was cyclical depending on the production phase. Most importantly, they determined that only one compressor would be necessary once they eliminated the leaks in the system and upgraded short-term storage capacity.

The project team formulated a three-stage plan. Their first step would be to increase storage capacity to accommodate peak demand; the second would be to fix the leaks, and the third to source a larger compressor and associated gear from a sister plant the parent company was phasing out. Viewed overall, this provided four specific goals.

  • Improve reliability with greater redundancy
  • Bring down system maintenance costs
  • Cut down plant energy consumption
  • Eliminate nitrogen as a fall-back resource

They reconfigured the equipment in terms of lowest practical maintenance cost, and moved the redundant compressors to stations where they could easily couple as back-ups. Then they implemented an online leak detection and repair program. Finally, they set the replacement compressor to 98 psi, after they determined this delivered the optimum balance between productivity and operating cost.

Since 2008, FUJIFILM has saved 1.2 million kilowatt hours of energy while virtually eliminating compressor system breakdowns. The single compressor is operating at relatively low pressure with attendant benefits to other equipment. It is worth noting that the key to the door was measuring compressed air flow at various points in the system.

ecoVaro specialises in analysing data like this on any energy type.?

Contact Us

  • (+353)(0)1-443-3807 – IRL
  • (+44)(0)20-7193-9751 – UK

Ready to work with Denizon?