Retail Banking - Real time Use cases

This is Episode 3 of data engineering where I will be covering real-time use case in the retail banking sector. This forms the core topic of this series, something that I have worked extensively in my past.

In this episode, I would like to define the problem statements & Agile overview. The next episode will focus on solution architecture and extensive story building methodologies to achieve the desired outcome.

This one in particular, is my favorite episode as it sets up the tone to the entire series.

Before I commence, I would like to thank the product owners, business analysts, Agile coaches, and scrum masters with whom I have worked throughout my career and the amount of knowledge I have gathered with numerous personals with similar interests, during coffee catch-ups and external meet-ups over a period of time.

From now on, the key focus is more on problem statements and solutions. To keep it more interactive, I would request the readers to kindly comment and ask questions wherever they see fit.

Overview on Agile

Before getting into more details, I would like to give a brief introduction to some of the agile jargons

The hierarchy of Agile works like this: Epic -> Features -> User Stories/Backlog Items -> Tasks

An Epic is a big chunk of requirement that business wants to accomplish.

A Feature is a subdivision of an Epic which will define the MVP business wants to achieve. MVP is nothing but a minimum or most viable product that can be shipped or can be used by Business.

An User story or a Backlog Item will be smaller pieces of a feature breakdown, which will help shape up or complete a feature.

A real world example can be:

Epic - Business wants to build a car.

Feature#1 – Build the Interior Components
- Story#1 – Design the car seat layout
- Story#2 – Design the car seat belt mechanism
- Story#3 – Design the color of the car seat
- Story#4 – Design the floor mat
Feature#2 – Build the exterior Components
- Story#1 – Design the car locking mechanism
- Story#2 – Design the car’s wiper system
- Story#3 – Design the color of the car
- Story#4 – Design the roof antenna system
Feature#3 – Build the Electrical system/components
Feature#4 – Build the Engine Components

Features can be worked in parallel and integrated. Better control, flexibility, superior quality, continuous improvement, efficiency, and high team morale are some of the key benefits of working in an Agile driven project.

Now that we’ve got ourselves familiarized with the Agile Jargons, it is time we see some examples from risk, compliance & KYC perspective.

Real time use case

In the below section(s), I have defined a few Epics, from a business point of view, with the assumption that you will be having discussions with your respective AML and CTF, Marketing and Campaign and KYC teams.

Anti-Money Laundering and Counter-Terrorism Financing

As the Transaction due diligence manager,

I want to track transactions real time which meets the following two criteria:

a. Cash withdrawal using credit card

b. Money transfer to ultra-high- or high-risk countries as per FATF (Financial Action Task Force)

So that we can mitigate Fraud, AML and CFT activities.

Marketing and Campaign

a. As the marketing and campaigns manager,

I want to identify the customers who were on-boarded in the last 3 months, who can be potential candidates and are open for discussions about new product and services through phone calls or emails,

So that these customers will benefit from new product offers and recommendations, thus improving the overall customer experience.

b. As the marketing and campaign manager,

I want to list customers who closed their accounts in the last 3 months

So that we can reach out to seek their feedback on the reason for closure

Know Your Customer

As the KYC Country lead,

I want to find out how many (summary) and detailed customers missing residential, mailing, and digital (mobile and email id) addresses which are critical for any customer due diligence process,

So that a DQ remediation plan can be worked out by an appropriate team to help improve the DQ and thus the E2E process itself.

We now have a very good understanding of the source system (from Episode 2), and problem statements are well defined with the current episode.

The original plan was to have the problem statement and solution architecture covered in a single episode.

However, I realized it would become cumbersome to cover them both in one go.

Hope you enjoyed this episode and got a better understanding of how Agile works by going through some of the real time use cases.

In the next episode we will focus more on solution design architecture and write the corresponding user stories to fulfil the required business requirements.

In case you have missed out on my previous episodes refer to https://lnkd.in/giq5YPku