Rotten to the Technology Core

Last week, the Reserve Bank of Australia (RBA) released a comprehensive report on the performance of the New Payments Platform (NPP) on its first birthday.

For a piece of financial infrastructure that had the potential to go horribly wrong, the NPP has performed extremely well on a technical level but there are niggling problems, best summarized by the RBA

 “the slow and uneven roll-out of NPP services by the major banks has been disappointing and that this has likely slowed the development of new functionality and contributed to stakeholder concerns about access to the NPP.”

So, who’s to blame – the same old, same old, Big Four banks!

Unfortunately, the RBA has not named names, as it certainly should have done, but does highlight the fact that the so-called ‘Core Systems’ of some of the major banks are not fit for purpose.  In an ideal world (that is one not without a Four Pillars policy) banks would be forced by the market to keep up to date with then latest technological innovations.

One of the key objectives of the NPP was to “promote competition and innovation in the development of overlay services without the need to make frequent or significant technical changes to the BI [Basic Infrastructure]”.  But the feet-dragging banks have become a drag on innovation across the industry, as the RBA notes

“Given that payment systems are networks that often require a critical mass, the slow progress within some participants has delayed the development of some of the planned ‘central’ functionality – for example, no decision has yet been made regarding the request-to-pay and payment-with-document overlay services. The slower than expected roll-outs by some participants appears to reflect the complexity of their systems and underestimation of the degree of investment needed to meet delivery timeframes.”

In other words, the largest banks are holding the other (nimbler) banks and the whole industry to ransom, with real progress only taking place at the pace of the slowest of the Big Four.

The joke is that all of the major banks make a very big deal in their annual reports of becoming ‘digital’ banks.  For example, Westpac: aims to ‘create a 21st century, digitised bank with multibrand capabilities”; ANZ: “One of our strategic priorities is to digitally transform the bank”; CBA: “We apply world-class technologies to meet the ever-evolving needs of our customers and our people”; and, NAB:” become increasingly “digital-first”.

Fine words for investors but, apparently, little action on the ground.

If the banks cannot handle the first step in digitization – the support of real-time small retail payments – how are they going to handle the tough stuff – like on-line lending and, since the Royal Commission, a very touchy subject – online financial advice?

Core systems are those systems that give an institution its license to operate, and include payments, mortgages, credit cards, statements, deposits, funding and so on.  These are the basic services we expect from any institution that wants to call itself a bank.

All major banks provide those services but what we cannot see is the plaster and sticky tape that is holding these services together inside the banks’ core systems.  Sometimes, thankfully not often, the core systems patchwork becomes apparent when a major bank, such as NAB,  goes offline and ATMs and merchant terminals stop working for a time, inconveniencing customers and businesses.

The Core Systems of any financial institution are complex and usually a hodge-podge of many systems developed over decades using different computer languages, hardware and software. Individual components are constantly being changed as new banking products are developed and regulators push for implementation of new reporting. After a time, core systems become inflexible and more and more expensive to maintain and ideally should be replaced.

But Boards are often reluctant to undertake Core System Replacement (CSR) programs because they are costly, time consuming and very risky.  A timid board will always find something else, less risky, to spend this year’s budget on, kicking the can down the road for their successors, until after they have retired.

Undertaking a full-blooded CSR program is one of the riskiest strategic decisions any board can take since success is far from guaranteed and can even be disastrous, as in the case of the failure of the Co-Operative bank in the UK amply illustrates.

It is examples like NPP that show how Australian bank boards have failed over decades to address the necessary refurbishments of their core systems environments to bring them to a level needed to support the requirements of a modern banking system. And it is going to get worse as technological innovations change the nature of financial services.  Australian banks are already falling behind as regards use of technology, for example the Australian bank voted ‘best’ (by experts from  Mozo) was ING – a digital only bank owned by a Dutch parent.

The Four Pillars policy protects the four biggest  banks from real market competition but,  as the Hayne Royal Commission showed aplenty, it also makes the largest banks lazy, arrogant and stuck in an old business model with antiquated technology and obsolete core systems.

It is way past time that the ACCC was tasked with investigating whether the Four Pillars policy can operate effectively in a rapidly changing technology world and the largest banks have become too bloated to be fit for purpose for 21st Century banking.

 

The Technology Standards Conundrum

The world of technology standards[1] is a mess, populated with well-meaning attempts to come to grips with some of the biggest problems in IT management, at the international, national and industry levels.

The mess is created because as each new problem, such as ‘Information Security’, arises, the solution tends to be addressed in isolation, by knowledgeable technicians rather than management experts, who can see commonalities across different standards.

This can be illustrated by considering three relatively recent but important standards on ‘information security management’ and ‘cyber risk’, which address roughly the same problem:

  • ISO 27001[2] – ‘IT Security Management Systems’;
  • NIST 800-53 – ‘Security and Privacy Controls for Federal Information Systems and Organizations’; and
  • BS 31111[3] – ‘Cyber Risk and Resilience’, a new standard developed by the British Standards Institute (BSI) Risk Management Committee, and published in 2018.

Each of these standards comes at the problem of ‘cyber risk’ from different angles and each group responsible for a particular standard, has developed a different ‘risk management framework’ (RMF) for tackling the problem of cyber risk in a financial institution or government department. For example, in NIST 800-53[4], the US National Institute of Standards and Technology (NIST) develops a framework of six steps:

  • Categorize: “the information system based on a [another standard] impact assessment”;
  • Select: “the applicable security control baseline based on the results of the security categorization …”;
  • Implement: “the security controls and document the design, development, and implementation details for the controls”;
  • Assess: “the security controls to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for the system”;
  • Authorize: “information system operation based on a determination of risk to organizational operations and assets, individuals, other organizations …”; and
  • Monitor: “the security controls in the information system and environment of operation on an ongoing basis to determine control effectiveness, …”.

It should also be noted that NIST also developed a more general ‘cybersecurity framework’ [5], in conjunction with NIST 800-53, which consists of five risk management steps: identify, protect, detect, respond, and recover.  These steps align with the ISO 31000 risk management[6] standard but are in a different sequence and key processes are merged.

By itself, there is nothing wrong with any of these NIST frameworks, which are based on the well-known Plan-Do-Check-Act (PDCA) management paradigm, except that the standards are standalone, aimed at a specific problem and, as a result, will cause unnecessary duplication when employed alongside other standards such as ISO 31000 or COSO[7].

On the other hand, the BS 31111 standard is organized on six key themes, which closely follow risk management standards such as ISO 31000:

  • cyber governance policies with strong structures, operating models and supporting resources;
  • demonstrating commitment to recognised security and risk management frameworks that include mitigate, accept, respond and transfer capabilities;
  • clear risk reporting that shows the commercial and operational impact of the risks based upon actionable and real-time intelligence;
  • ability to learn from experience including starting from first principles to a more innovative, adaptive response as a situation changes;
  • the need to recognise that cyber risk and resilience be incorporated into all new programmes and initiatives;
  • having a threat intelligence capability and information sharing programmes to ensure that the organization and any appropriate third parties are quickly kept up-to-date with the level of risk including the ability to quickly adoption of any external guidance necessary to control identified risks.

The ISO 27001 standard also proposes a similar PDCA model which has six stages that are different to BS 31111 but cover similar processes: policies, planning, risk assessment, manage, control and monitor. Again similar (but a different order to) ISO 31000 and COSO.

These three standards are well-considered and comprehensive but are incompatible at the process level and could not all be implemented within an organisation, without significant duplication and inevitable conflict.

These standards are not contradictory, they merely place emphasis on different aspects of the problem – NIST on detailed implementation leading to management, BSI and ISO on management leading to implementation.  However, although these standards are quite different, because they have been developed by experts in a formalized process that encourages consultation and agreement, they do provide a comprehensive, if difficult to entangle, coverage of the problem being considered.

It is obvious that a well-developed standard is likely to be better than one developed from scratch by a firm itself, as a firm will just not be able to access the breadth of expertise available to a standards committee.

This is the ‘standards conundrum’ – any formal standard will invariably be better than one developed internally by a firm, but which one to standardize on?

And there is no easy answer to this conundrum.

Adopting any standard, even if only in part, is in effect a risk-mitigating decision, allowing a firm’s strategic decisions to be audited against external expertise. And it should be remembered that being ‘fully compliant’ with a standard is not an end in itself, but rather a way of testing the firm’s processes against so-called ‘best practice’.

It means that business and support units, such as Risk Management and IT must take a pragmatic approach towards adopting new standards; and must do so within well-developed framework(s), that are agreed and understood by all. They must then map new standards onto their frameworks, attempting to understand what each new standard brings to the industry (it will inevitably bring something) and recognizing that a new standard will mean inevitable changes to their frameworks.

This also means that a board, when considering technology strategy, must be aware whenever new standards are emerging in particular areas and make strategic decisions based on the ‘maturity’ of a particular set of standards, not on their novelty!

It also means that standards developers must also be pragmatic and recognize that their (precious) standards must be capable of being integrated with other standards and that it is the principles not the details of a particular standard that are important.

Unfortunately, we are a long way from achieving those ideals.

[1] Adapted from McConnell P.J. ,2017, Strategic Technology Risk, Risk Books, London

[2] ISO, 2013, ‘ISO/IEC 27001:2013 Information technology — Security techniques — Information security management systems – Requirements’, International Standards Organization, Geneva, http://www.iso.org

[3] BSI, 2018, ‘BS 31111:2018 – Cyber risk and resilience. Guidance for the governing body and executive management’, British Standards Institute, London

[4] NIST, 2013, ‘Security and Privacy Controls for Federal Information Systems and Organizations’, National Institute of Standards and Technology, Washington, D.C., http://dx.doi.org/10.6028/NIST.SP.800-53r4

[5]NIST, 2014, ‘Framework for Improving Critical Infrastructure Cybersecurity’, National Institute of Standards and Technology, Washington, D.C., https://www.nist.gov/document-3766

[6] ISO, 2009, ‘ISO 31000:2009, Risk management – Principles and guidelines, Geneva (International Standards Organisation).

[7] COSO, 2016, ‘Enterprise Risk Management – Aligning Risk with Strategy and Performance’, Committee of Sponsoring Organizations of the Treadway Commission.