In 2022, it will be 25 years since I started working in technology consulting, developing Corebanking Systems.
I spent almost 10 years developing those Corebanking systems that nowadays are considered or named “Legacy” systems. Later, we had to start transforming those systems because of the Digitalization of the Financial Institutions and, more recently, the aspiration to leverage Cloud Infrastructure. And those are challenging aspirations for the very traditional and complex organizations that most Financial Institutions are.
If you think about it, a traditional Bank is like one of those brick & mortar large department stores where you could find anything but, for that, you had to go to the right department. If you wanted men’s clothing you had to go to the men’s clothing department and if you wanted an appliance you would have to go to the appliance department. We can compare this scenario with the large internet retailers, where you have a single interaction point with customer, for any product. We can say that Digital retailers are “Customer Centric” while the traditional ones were more “Product Oriented”.
In the traditional banks, and here is where the comparison comes in, most of the business processes are “Product Oriented”. If you need a Loan, there is a loan opening process; if you want an account, you have an account opening process, and so on. However, the way that both industries faced the digitalization has been very different. While Department Stored emulated the native digital retailers when developing their digital channels and became more customer-centric, the bank replicated the same product oriented approach in the new channels.
The fundamental problem with this product orientation is that it greatly constrains the adoption of new business models that are required in the new digital world. For example, the Euro Banking Association & Innopay published some time ago the new roles that Financial Institutions will assume in the future. The report clearly separated the roles of Distribution and Product Processing.
This means that in the future a bank may specialize in the distribution of banking products by selling both their own and other’s products. Other banks may specialize in the processing of products because they do it efficiently and sell them through any combination of their own and external channels, including other financial institutions but also through partners and participation in digital ecosystems.
Product Oriented Processes are a constrain to the new models because they strongly couple Distribution and Product Processing in e2e processes. This coupling in the processes is reflected in the core systems, with single large monolith applications supporting the end to end processes.
The Digital Transformation requires breaking these end2end processes into different stages of the value chain. This means transforming the supporting Corebanking systems, breaking them down into separated components that will support each of the roles in the value chain. The components have to be completely decoupled from each other so that a distribution functions can work with different processors, and the other way around. Some practices are recommended such as Domain Driven Design, and to consider that each role in the value chain are going to be provided by entirely different organizations that should not depend on each other in their daily operations.
Hopefully we have a great asset to help in the challenging endeavor: the BIAN Banking Industry Standard (BIAN.org)
BIAN proposes that business processes are supported by elemental capabilities named Service Domains. Each Service Domain has a unique business purpose, are elemental (not composed of other Service Domains), and collectively comprehensive (any business activity can be model using Service Domains). Service Domains should be implemented, integrated, deployed and/or consumed as Self-Contain Systems. They provide business capabilities exclusively through standard API and Business Events and remain very loose coupled with other service domains
BIAN organizes these service domains into business areas such as Sales and Service, Product Specific Fulfillment, or Cross Product Operations. And here it is, exactly the business component model we are looking for, with strict separation of Distribution (Sales and Services) from Product Processing (Product Specific Fulfillment, in BIAN language).
Also, while Product Specific Fulfillment area is made of Service Domains supporting the processing of each individual type of product or service such as Deposits, Consumer Loans, Cards, or Investment Accounts, both Sales and Service and Cross-Product Operations are product agnostics. This means that they provide capabilities to be used for any kind of product. This is great because if you follow BIAN, you can avoid creating again product oriented processes. There are not Loan Origination, or Account Opening domains in BIAN, but Customer Offers, Sales Product Agreements, etc. which are cross products and will lead to a customer centric approach.
A great advantage of this model is that it addresses one of the most important pain points in most of Financial Institutions, the famous time-to-market, or the time if needs the organization to launch a new product or services. With product oriented processed it clear that any new product launch will impact the entire value change and will probably require modifications to the IT applications supporting the process. If we search inspiration of the the large digital retailers and platforms and imagine we have a product to sale, our onboarding as product vendor on those platform will be extremely easy, and we will be ready to sale our product in the platforms very quickly. The trick is that those platforms have robust distribution (usually the website) and operations (logistics, payments, claims…) that will work for any new product or vendor.
A BIAN based architecture can help the bank to adopt this kind of business models, where adding new products or services (internally developed or externally supported) would be much easier, more efficient and with a greater time-to-market.
I have used BIAN for many years now. I’m aware of the interest that most financial institutions are paying on BIAN. But I’ve also seen how the model is misunderstood and poorly used in many cases, for example when it’s used just to define some integration APIs on top of the legacy core systems. This is not very useful because the underlying systems are not aligned to the business model that BIAN intents to provide. The result is that we are creating additional architecture layers, which means more complexity, point of failures and maintenance cost for the already complex and costly banking systems.
Last year I had one of my most gratifying professional experiences with one of my clients because for the first time I have seen a conviction, a realization of the necessity to break down current processes and underlying systems to change the business models, breaking the value chains and separating distribution and product fulfillment processes. And doing so through simplification of the systems and processes and not adding more complexity, aligning the IT organizations to business domains and not to technical capabilities, making the teams more self sufficient, less dependent on other. And I’m really convince the results will be astonishing in terms of time-to-market, cost efficiency, really making IT the great enabler of business value for the organization, and becoming a good example for others to follow.
