Architecture around digital banking

This is the third part of my multi-part series on digital banking

The architecture of digital banking is more driven by internal and external factors. These factors force the architecture to be:

• More agile
• Accelerated speed to market.
• Innovation as a way or working.
• Cloud-native hybrid-based architecture.

The external factors which force the digital banking platform to adhere to the above-mentioned capabilities are:

• Increased customer expectation
• Brick and mortar banking is history and customers expect a lot more than just banking.
• Inventible fintech threat
• Dwindling interest and fee income and bank must look for additional avenues of income (Partner ecosystem)

Also, from the persona standpoint unlike multi-channel architecture which is only enabling customer engagement the expectation around new generation digital platform is to ensure the following:

• Customer
• Employee
• Sales partner
• Eco-system partner

Now let us get into the bras sticks of digital architecture. The following schematic provides an overview the capabilities in nomad language however we will get into the details in the subsequent sections:

Let us dig deep into each layer from functional and domain capabilities.

Digital banking architecture (Logical level)

Channel engagement layer

Channel engagement layer is the most complex layer which handles the following aspects:

• First point of entry for all personas (Customer, employees, partners).
• It performs the first line of entry technical and business validation.
• Manages the user experience for different pervasive devices.
• Manages the experience (north bound) API’s.

It is not a passive layer but performs real-time analysis based on which certain actions are triggered (Engage à Analyse à Act). This layer is keen on user adoption as it may make or break the digital transformation of the bank. Banks spend considerable time designing this layer. This layer aligns with the digital transformation strategy of the bank. Business units and product owners play a significant role in how this layer will be designed, including features which would be market differentiation to the bank.

Domain process layer

As is common in banking everything is driven around process like the way brick and mortar banking business is driven. However, the domain process of banking is slightly different and does not mimic the branch process. The thinking and implementation of products as well as processes must be completely different for digital platforms. It would be a complete disaster if banks tried to implement the branch process onto a digital platform.

The process needs to have capabilities significantly around:

• Self-service oriented
• Straight through processing
• Paperless
• Assistance in making informed decisions.
• Broad brush stroke to cover Gen-X/Y, Gen-Z, and baby bloomers to the extent possible

Domain services layer

This layer is the foundational building block for the domain process layer. This layer provides atomic functions exposed as API’s which are orchestration or choregraphed by the domain process layer to realize a specific process or user journeys.

The current defector standard in designing these API’s is BIAN (www.bian.org) which provides a Symantec representation of API segregated into business area, business domain and service domain.

Though there is an attempt in the banking industry to standardize domain model, event model and data model using BIAN still lot of systems or record use their own data model. Due to which there is a need to convert the proprietary canonical data model to a BIAN based implementation model. This layer handles that translation capability.

Integration services layer

As the system of records does not have a standard technology implementation, protocol management and integration service layer become inevitable. This layer abstracts the data access mechanism with the System or records and provides a uniform consumption option REST protocol-based API’s. All complexities are abstracted out such as:

• Implementation of CRUD function
• Aligning to ACID
• Protocol conversation
• Domain aggregation if needed.
• Data Persistency

Data fabric

Data fabric is an important function of digital platforms. The “Analyse” function which was explained in the customer engagement layer is primarily driven by this data fabric. Data fabric core functions are the following:

• User experience analytics
• Real-time streaming
• Real-time analytics
• Data services
• Data proximity services

Platform services

Platform services is a broad function and comprising to the minimum of the following:

• Developer services
• Continuous integration services
• Continuous deployment services
• Platform services
• Infrastructure services
• Security services

Briefly, outside the application and data services the rest of all the services fall into this category.

This blog has been deliberately kept at a logical level for appreciation of a larger audience. The next blog will go deeper into each of the layers and the potential implementation using AWS and Redhat OpenShift.