Banks have multiple options while setting
up Islamic businesses and need to make technology
applications and infrastructure choices carefully. Most
Islamic organisations require a separate business
division with dedicated Shariah boards and products
and policies/procedures compliant to their board’s
operating guidelines. Banks are also required to maintain
a separate general ledger from accounting, reporting
and to ensure it is fully compliant to Sharia principles.
From a technology standpoint, there are two types
of co-existence systems, which are discussed here.
Typically, these best-of-breed systems are called Product
Processors.
Conventional banking systems include: Customer – Master records; Accounts – CASA and time deposit accounts; Deposits – Term & investment deposits; Limits & Loans - Retail and Corporate Lending; Trade Finance – LC & LG issuance and settlement; GL modules with strong capability around accounting, interest accruals and applications, fees & chargers. At the other end, Islamic banking systems include: Islamic Deposit; Islamic Lending; Asset Management; Profit Distribution; GL modules.
Given regulatory and policy considerations, is there a business case for co-existence or should banks invest in dedicated technology applications? Central Bank Qatar, for example, announced the need for separation of Islamic systems from conventional systems. Conventional FIs had to therefore run down or sell their portfolios to Islamic banks. Oman has restricted its banks and no coexistence of systems is allowed.
As customers are more ‘Value Centric’, the choice of products is made based on perceived value. Conventional customers are increasingly adopting Islamic products for Deposits (Risk & rewards sharing), Loans (Murabaha), Rent to Own Mortgages (Ijara) & Musharaka (risk sharing based lending). This has resulted in the need for banks to provide seamless product and channel experiences through either single banking systems or multiple bestof-breed product processor options. There are typically two co-existence scenarios:
- Single back office systems: Select a common Universal Banking System (UBS) to enable both conventional and Islamic businesses to co-exist from a single technology platform. A case in point is Kingdom of Saudi Arabia (KSA), one of the matured markets for Shariah compliant banking, where 8 out of 12 banks use common UBS for conventional and Islamic banking products. This model is normally preferred in situations where banks have already invested in UBS or are planning an investment. It has its advantages in lower acquisition costs of system and simpler architecture. However, there may be limitations in terms of functionality when compared to best-of-breed systems.
- Multiple system best-in-class product processors: Banks with best-of-breed architecture capabilities prefer a separate conventional and Islamic banking system. Integration is achieved at the customer level with common Master Data Management or Enterprise Services Bus.
In the second case, co-existence requires unique architectural layer transformations and hence is considered to be more complex. However, this provides better functional capability.
Typical considerations that go in the finalisation of the above co-existence model would include:
1. Master Data Management based customer:
identification: For effective multiple product processor based co-existence, it’s important that the customer is identified upfront as Common/Conventional/Islamic. The routing to the product processor is then managed effectively, based on the tag.
2. Omni-channel layer (Digital Banking, Contact Centre and IVR):
Digital and channels available in omnichannel architectures need to have the capability to route the customer request based on customer/account numbers to correct product processor.
3. Flexible service layers:
Shariah boards have divergent views on the common customer service layer between Islamic and conventional banking customers, resulting in common branch infrastructure and front end applications. Where flexibility exists, the customer layer is shared between both business units. The servicing layer is optimised with CRM or best-of-breed digital branch front ends.
4. Strong Online Middleware/Enterprise Services Bus:
Service Oriented Architecture (SOA) capability acts as a backbone for the integration between conventional and Islamic product processors. Strong integration between conventional and Islamic product processor ensures 100% confirmed delivery of transactions and provides a batch framework to synchronise key data elements such as customer account number.
5. Real-time integrations between “Product Processors”:
Most banking models commence with conventional operations, followed by Islamic products. This is enabled in real-time in the second model, which provides a faster time to market advantage.
6. Enterprise General Ledgers:
Banks also need to make a call between Enterprise GL and conventional systems acting like Enterprise GL, and having an Islamic product processor posting the daily entries. The choice between the two models varies based on this factor. The alternative, of course, is a manual consolidation.
As a general rule, the single system approach may be more suitable for greenfield and small size banks. Multiple product processor approaches could be more applicable to medium to large size banks. However, a lot also depends on geography (and regulatory constraints), availability of solutions and suppliers to support the model, approval from Shariah boards and, indeed, the six factors we have discussed here
To read more such insights from our leaders, subscribe to Cedar FinTech Monthly View