Event driven architecture in Banking — A practical approach

Periasamy Girirajan Irisappan
6 min readFeb 25, 2022
Events driven is an aggregation of events, patterns and actions

Banks have evolved at a faster pace due to the advent of technology adoption in various areas. The customers demand fulfilment and risk management which has been a batch based moved towards a straight though processing mechanism however the key decision which are analytics based were still run as batch jobs.

In the advent of customer demands and to mitigate fintech threats the customer demand fulfilment has almost become real-time. Two key aspects of fulfilment have become real-time, one is decision engineering and to provide variance of certain business attributes (such as fees, offers etc.).

Event driven architecture is complex in design and implementation. The concept primarily revolves around the following four attributes:

Attributes of event driven architecture

The combination of these four attributes determines the technical event through pattern matching algorithms which then converted in business event and the respective system actions are performed accordingly. The event driven has its own lifecycle as explained below:

EDA life cycle

· Event generation — Event generation is both users initiated as well as system-initiated activity. In the case of user generation, it could be a user selecting a particular option such an expression of interest for a credit facility or initiation of a utility bill payments. System generated ones are targeted marketing though micro-segmentation of customers. These events are technical events and get converted into business events using complex patterns matching algorithms.

· Event propagation — These events which are generated from engagement layer needs to be propagated into down streams systems for in-memory analytics and pattern matching. This is achieved usually by a micro-broker (Kafka etc.) which operates in a pub-sub mechanism

· Event intelligence — Event intelligence is a fabric which applies necessary prescriptive or AI algorithm to convert them into a relevant business event

· Business events — Business event is the actual events which are derived from technical events and application of event intelligence. Business events follow a common ontology across the data fabric so that every participating component can understand

· Event action — Event action are predefined actions or derived actions based on prescriptive or AI model based on the business event and the associated parameters

· Event store — Event store is implementation of event sourcing pattern for ensuring reliability and option to replay the event in case of a need

· Event bereavement — Event bereavement is the smooth purging of the current event so as the engagement layer can start capturing subsequent events and perform the necessary action. In a few cases the events could be complex and would accumulate until a desired business event is generated

The sweet spot for implementing EDA is the constraint and the value-add steps in the user journey value chain. These sweet spots offer maximum business benefit out of implementing EDA touch points

User Journey value chain and EDA sweet spots

In an event-driven architecture applications interact by producing and consuming events. An event is an immutable notification of the change of state of a business entity or user action within an application. One or more applications may subscribe to events of interest. Events are typically communicated via a messaging system.

Several application architecture patterns may be built upon events including:

Events — basic form of communicating events between applications via a messaging system and typically does not persist events in the long term.

Event Streams — a continuous flow of events that may be used to derive valuable business insights utilizing event processing, analyzing, combining, and enriching event data from which a subsequent stream may be derived, or an action may be performed.

Clickstreams — events representing user interactions with a user interface including clicks, mouse-movements and gestures that may be analyzed to gain a deeper understanding of user behavior. Analysis may be offline or in real-time that results in actions.

CQRS — Command Query Responsibility Segregation establishes different models for reading and writing information, gaining the opportunity to independently optimize each path. A combination of API style integration (for reads and commands) and Messaging style (for updates between write and read models) are typically used with this approach.

Event Sourcing — each change of state of a business entity is stored as an immutable event from which an aggregate may be formed by reading back the events in a sequence to derive the final representation.

The purpose of the event driven architecture can be one of the following categories:

· Integration — Used to trigger action in other applications.

· Activity history — Show a historical interaction history. Used by call center. Various granularities may be deployed; high level events such account opened, password changed, customer called call-center or fine-grained events such as clickstream, used clicked payment view, user clicked settings

· Replication — Used to propagate data to other systems to hold data locally that they need. This supports autonomous microservices that access their own copy of the data.

· Real-time stream processing — Analyze and derive insight from which action or new stream may be produced.

Let us drill down the using a real banking user journey:

User story one

A young 25-year-old is looking for a personal loan and navigates in a banking aggregator site as his current banker does not provide personal loans and looks out for options. He traverses through site providing KYC and his current banking information and consent for inquiry transaction on his savings A/C with the current bank. The aggregator platform hits Bank platform with the necessary information. Based on the KYC details, a credit bureau check is performed and as the customer does not have any asset products there is no credit score. Immediately the bank triggers an alternate credit score mechanism and inquiries his current relationship bank and gets the past 6 months statement and calculates income/expenditure ratio and his repaying capacity. An AI algorithm is involved for credit decision making, Terms & conditions, tenure and interest rate and fee and presented to the aggregator platform in Realtime

Loan approval process

Representational architecture

Representational architecture

1. Customer requests for personal loan options and then provide the KYC information and consent for open bank inquiry in case it is required to do further inquiries to calculate credit rating

2. As part of the risk management process fraud check is initiated against the fraud database both internal and external

3. KYC details are checked against the necessary entity based on the type of KYC

4. To make the decision around lending decision credit bureau check is initiated for customer based on the KYC information provided

5. If credit bureau details are not satisfactory as alternatively the inquiry transactions against the existing relationship bank provided by the customer through the open banking platform where their necessary data are collected

6. The income expenditure ratio and spending analysis done to calculate the

7. A credit decision is made based on the calculated income expenditure ratio and the aggregated score based on the credit Bureau rating

8. If the credit rating is green, then try the pricing & billing is invoked to calculate the service fees charges and notified back to the customer for further processing

--

--

Periasamy Girirajan Irisappan

Im an IBM Dintiguished Engineer with 27 years experience in design and delivery of banking transformation projects in the areas of core modernization, digital