Avoiding catastrophe: Selecting the right banking platform

The word catastrophe might sound sensationalist — but platform selection is key and if the wrong platform is selected this can be a very bad scenario.. a catastrophe..

So, how can this type of situation be avoided?

Most banks release prodigious RFPs with thousands of difficult questions some looking for functional fit (Can your product do x?) and others attempting to peer into the very soul of the vendor (What is the greatest weakness of your product, and how are you addressing it?)  What these questions can miss is the fundamental fit of the product in the context of the bank.

Most core banking projects are transformational in nature – the processes are expected to evolve rather than legacy processes implemented in a modern package.  Yet some packages are easier to work with than others and the difference is with the concepts behind the package and how they align with the concepts prevalent in the bank.  Banks will expect to adopt new processes but they may not be able to accept new concepts.

Processes are flexible, they can change and platform features come and go — but concepts inherent in packaged products are often at the core of the solution and encapsulated in these concepts are assumptions on how a bank should be run.  If these assumptions prove to be invalid for your bank, adopting the package is more difficult.  If the concepts align, many aspects of the project become easier.

Concepts are actors and objects expected to be participating in a process.  The behaviour and attributes of the actors and objects have been defined within the package based on the assumptions of the scenarios they will participate.  If these prove false the result can be either a heavy customization (changing the fundamentals of the package) or major changes in concepts in the bank.

A great place to start in banking software selection is to assess the concepts inherent in the key processes in the organization?  How do these conceptual entities interact and what are the rules and flows associated with their interaction?

For the vendor, what is the conceptual flow inherent in the package (for the same processes) and are there any new concepts?  Are any of the current concepts missing?

One of the first things that many banks notice is that modern banking platforms have a customer centric rather than account centric design.  Customer centricity means that the customer entity is associated with data and activities previously associated at the account level.  Some modern platforms include new concepts such as offer, contract, bundle:  how will these new concepts mesh with the existing landscape — what are the corollaries?  Some of the existing concepts only exist because of legacy constraints.  When these concepts are no longer relevant what are the impacts?  Downstream systems are expecting these concepts to be present, what happens when they are missing?

The challenge with conceptual misalignment is that it’s really difficult to mask and the associated effort and complexity associated with compensating for the mismatch adds up.

I suggest developing a conceptual view on the bank side and requesting a similar view from the vendor and then discussing the differences.  It will be clear what assumptions were made in the creation of the package, and the legacy bound concepts should also be apparent on the bank side.

When the concepts are aligned, the platform is a good fit from many perspectives and when concepts are not aligned everything becomes more difficult.

6 Responses to Avoiding catastrophe: Selecting the right banking platform

  1. kris,

    I like your approach and the questions you raise!

    now, I would be interested in your views:

    which one of the several available vendor packages is the most flexible in terms of process change?

    which one of the several available vendor packages is the most flexible in terms of data structure adaptation?

    which one of the several available vendor packages is the most flexible in terms of new product development without coding?

    any opinion?



  2. Interesting discussion, Kris. I mostly agree with you, although the package concepts, or business objects, can be mapped to the bank’s business objects. Some level of mapping is likely to be necessary, but if the mapping is too widespread and excessive, then it is clear that the package in question and the bank are “talking very different languages”. That situation clearly means there is poor fit.

    It is also interesting that you touched upon the process aspect. True, business process need to be flexible. However, all too often, the package solution comes with an inherent inflexible business process. The package tries to “fit” the bank into its inherent business process, rather than try to fit into the bank’s existing business process. That situation can also be detrimental (catastrophic?). There needs to be flexibility on both sides.

  3. Thanks for your comment, Frank!

    While I do have some opinions on the core banking packages currently available I am not current on all of the packages as I did my selection analysis a few years ago.

    These are very key questions that you raise, and aside from the conceptual fit other package attributes need to be considered. Flexibility and adaptability to change are key!

  4. Thanks for your comment, Nitesh. I think it is important that when COTS packages are adopted there is a conscious decision made to work with the software concepts and processes. If the package is not a good conceptual or process fit extensive customization is the result and this should be known up front so that this is not a surprise.

  5. I believe there is too much stress and focus on what is commonly known as a core banking system (CBS)and the expected panacea. The traditional role and nature of the CBS is evolving from a set of integrated modules covering all divisional requirements into a core transaction processing engine. Some CBS are evolving at a faster pace than others. Once this realisation is made the selection of a CBS is much simpler.
    Redefine your business and logical architecture using common (cross LOB) enterprise wide components

  6. I agree with Neil that some core banking systems are evolving faster than others. In a few years there will only be a few majors who will have survived–I do see some space for competition amongst systems tier 3 banks.

    – Benjamin Winegarden

Leave a Reply

Skip to toolbar