Core Banking Transformation – Where to Start?

Where to start? When you tackle something as large and scary as a core banking transformation the question of where to start can be perplexing. In the history of my core banking transformation career I have seen different models used for different reasons. I have seen a big bang approach justified based on a belief that legacy systems could not be easily decoupled. I have seen process centric approaches based on assessed value and expected business benefits. I have seen purely technical transformations based on portfolio analysis of legacy systems and applications. I can’t say that I have seen it all. At this point I think there are so many ways to skin the core banking transformation cat that there will not be enough transformations in my life time to see it all.

The question however still persists…where to start?  I have written previously about renovating your way to a core banking transformation and the current trend of large management consultancies to focus a banks direction on operational efficiencies and cost reduction. I am an advocate of transformation by process and that the prioritization of these process transformations has to be linked to tangible benefits related to growing a banks market, as apposed to simple process efficiencies and cost reduction. However I do not think that this is where a core banking transformation should start.

For me the development of the process centric road map and the renovation plan is important however if it were up to me the starting point for any core banking transformation would be master data.  It’s not sexy, it can lead to rework and in some cases throwaway work, if done right the transformation of master data is invisible to your end user, but master data is for me the logical starting point in the transformation of a bank. It provides your organization with a solid foundation, which will accelerate the implementation of your process road map.

Master data is any information that is considered to play a key role in the core operation of a business. In the case of a bank my master data list includes:

  1. Customer information
  2. Account detail and transactional information
  3. General and sub-ledger detail
  4. Organization Structure

For me this is where you should start a core banking transformation. At minimum the transformation should start with customer and account detail. Most packaged banking solutions will rely heavily on these objects and an integration strategy with legacy systems will normally limit the functionality of the new platform. In my opinion customer and account details should be converted to the new platform as soon as possible and applications consuming this data should be adjusted.

Running a close second for me is the early integration of the transformational general and sub-ledger functionality. Reporting requirements, compliance, and the running of day-to-day operations based on better/clearer financial data is extremely important.

Finally for me the ability to define a go forward organizational structure that reflects the realities of the current as-is model and flexible enough to address the requirements of the to-be model is extremely important.

Starting with master data not only provides a solid base to start building new processes against it also provides an opportunity for a bank to develop competencies with new platforms. The ability to develop competencies with a new platform without impacting end user functionality in the early phases of transformation can provide both the transformation team and executive with the confidence they need and the commitment to the new platform that will make the transformation of existing processes less stressful and more successful and will allow the enterprise to take full advantage of the new platforms functionality.

Want to leverage the complete functionality of your new platform while developing your organizations competencies with your new platform with limited visibility to the organization? Then you should think about starting with master data.


10 Responses to Core Banking Transformation – Where to Start?

  1. I agree, George. Great post. Having a target state vision for master data as well as an understanding of the current state really helps to encapsulate the challenge ahead when beginning a transformation initiative.

    The current state of master data will often depict some of the true challenges, and the target state should identify the solutions to these challenges.


  2. Hi George
    I love the way you brought out the intricate points of how to get started in CBS transformation.

    The points being precise give us clearer insight into how to go about things.


  3. Great Post!

    My two cents: B2B (other financial Institutions) and Gov. Regulatory Bodies should also be included in master data, as they play critical roles as well.


  4. George,

    I share your view and master data is the most critical function in a banks IT landscape.

    To me master data is like the spider in the web. It sits in the middle of the IT landscape and is connected to almost everything else. If it does not work – nothing works …

    Once you get master data right (transformation & migration), the rest of the IT landscape can and must follow your (new) master data definitions & (hopefully flexible) structures.


  5. Yes,

    Without a Master data foundation, applications can not integrate, for example the customer Master data must have a unified customer view, the same view for every application or channel.
    This is why I don’t believe in external CRM packages. CRM needs to be built on top of customer Master Data.
    But MD is necessary, but is not enough by itself, you also need:
    – applications architecture (based on TOGAF) that let your systems share the same code on for the same business function on every channel, and share an unique view of the common architecture services in the backend side that lets:
    – identification, autentication, autorization.
    – central management of applications and functions (business control panel)
    – event registering able to generate ledger and other accountable functions as regulatory, Basel III, money laundry, etc.
    – multichannel, multicountry, multicompany, multilanguage architecture, from backend level to every channel front-end.
    – a message system able to send the correct message on every channel and business function. For sample, on a branch terminal, your employee can see a message as “customer unauthorized to operate”, but you cannot send the same message when the business funtion is called on a selservice channel as internet, ATM o mobile. Your customer wouldn’t like it.
    – and other several common services that you will have to get out from legacy applications to put then onto the architecture.

    And joining the channels with the transactional backend, as a glue, a java based middleware able to call several backend transactions on a bpm process linked on a single transaction from the database point of view.

    Of course without a Master data strategy you can not build this applications architecture and can not have an unique view of customer accounts.

    Do you know how many banking institutions don’t have their on-line channels integrated? While working in Italy in 2003 for a well known german bank, customers had to wait for batch night process to consolidate their account transactions, and in 2005 a very large brazilian bank still had functionality that let their clients get the same money out of an account two times: in ATM outside and in the branch office, but after their end-of-day processes, the customers discovered that their accounts were in a negative.

    These banks knew they needed a Master data strategy and an applications architecture if they want to avoid these problems in a corporate strategy.


  6. I think the big bank approach can work well for small institutions but is too risky for larger banks. With such high risk at stake, piloting one product on a new platform is a reasonable approach. It should be done with an overal plan of how that software could replace/integrate with multiple systems throughout the organization.

    – Benjamin Winegarden

  7. Dear Ben, you are wrong:

    Due to the big amount of data that big banks need to process continuously, big bank need also more these resources and architectures.

    The Brazilian bank I designed its applications architecture have more than 150000 employees, and more than 10 million customers, and these customers aren’t from “favelas”, are nearby private banking customers.

    In Barcelona, “La Caixa” (, have more than 5 million customers.

    I know that these banks are greater than USA banks, but maybe your banks should start joining between them.

    Risks need to be avoided on every bank and the best method is to have enough information and alerts on the managers desks.

    AlexG (rocral)

  8. Hi all,i am new to Cbs.can you help me with some useful links and the chain of important certifications that could help me with my future? Thanks in advance.

  9. Hi,
    I unserstand your points. And i am agree that master data is the first thing to define in your transformation. But as you mentioned most of the data came from process And functionality that we cannot underestimate it. As a second conflict which is choosing Account Data And operations first to transform has some troubles. If your legacy codes are not loosely coupled your all functionality kept in one service or program. And mostly other components like rate profile, cash flow, withdraw, deposit, disbursment, collection, etc. depend on account codes. How you can decouple account first is problematic. I have found a solution dor this problem in our transformation project which looks like safe. First decouple other components like cash flow , rate profile, withdraw, disbursment, etc. And leave account to last. It may have disadvantages by the way.

Leave a Reply

Skip to toolbar