Case Study - Fraudulent Transaction Detection, Prevention and Building a Behavioral AI Model Through HCL Workload Automation

In this case study, we’ll look at a banking use case, wherein the goal is to detect a suspicious transaction in real time. A notification will be sent to the customer to evaluate and block it. At the same time, we’ll build behaviour models from historical data and current transaction data to detect future events based on the relevance of the issues detected.

Case study: A banking customer has its core banking application deployed on-premise at its own data center while leveraging AWS for all modern Analytics Applications built in-house within the bank.

The bank is envisioning a process as highlighted in the diagram below and is in need of a Workload Automation Solution that can Orchestrate across On-Premise. AWS Services will achieve the Automation Out of the Box (OOB), while also having ready-made plugins/connectors to connect with all AWS Services. An advanced event detection features for AWS Events to not only detect an event in real time but also to orchestrate it based on the event detected in real time.

Solution:

HCL Workload Automation as a Meta Orchestrator fits the bill perfectly, as not just a Workload Automation product that can Orchestrate across On-Premise and AWS Services, but one that can also orchestrate across Kubernetes/K8’s Workloads while having direct Out of the Box Plugins with many AWS Services.

1. Detect a message of a Suspicious transaction in an AWS SQS Service and run an AWS SQS Receive Job to receive a Suspicious Transaction in real time through an AWS SQS Job.
2. Call the AWS SNS to notify the Customer on the Suspicious Transaction immediately through an AWS SNS Job.
3. Extract the Account Number, Transaction Amount and Transaction Type from the Suspicious Transaction through simple Unix jobs.
4. Query the On-Premise DB hosted on the Core Banking Application to extract the historical data of all Transactions of the Customer basis the Account Number (the On-premise DB would include all previous Historical Transactional data of the Customer) through an Out of the Box DB Job Type.
5. Upload of all Historical Transactional Data pertaining to the Customer to an AWS S3 Bucket.
6. Upload of current Transaction data to an AWS S3 Bucket.
7. Run an AWS Lambda Function called VerifyTransaction to detect the Suspicious Transaction as an Anomaly or not based on historical trends.
8. Run an AWS Lambda Function called BehaviourModels to train the AI Model based on Customer Action that declines the Transaction/Accepting the Transaction as genuine.

TRANSACTION_SQS_RECEIVES_ANAMOLY Job:

This job is defined as an AWS SQS Job that can detect a message from Simple Queue messaging Service in AWS and detect it as an Anamoly or a Fraudulent Transaction.

The job makes a connection to the AWS Subscription with the below Subscription details in the connection Tab and subscribes to a Queue URL to receive messages and store the output in an output file called /tmp/AnamolyTransaction.

ABNORMAL_TRANSACTION_DETECTED Job:

The second job is an AWS SNS Job that detects that a suspicious transaction is detected. Hence, it sends an AWS SNS Notification through an AWS SNS Job:

EXTRACT_HISTORICAL_TRANSACTION_FROM_DB Job:

This job queries the DB on the Core Banking Application and extracts all historical Transactions about the Customer as output:

GET_TRANSACTION_AMOUNT, GET_TRANSACTION_TYPE and GET_ACCOUNT_NUMBER Jobs:

These jobs extract the Transaction Amount, the Transaction type and Account Number from the file /tmp/AnamolyTransaction generated as output of the first job. The jobs are realized as Unix Jobs:

UPLOAD_HISTORICAL_TRANSACTION_DATA Job:

The job is an AWS S3 Job which uploads all Historical Transaction data extracted from Core Banking DB to an AWS S3 Bucket, ensuring only the Transactional data without Customer Personal information is uploaded to the S3 Bucket:

UPLOAD_TRANSACTIONAL_DATA Job:

This job would upload the Transaction data pertaining to the current suspicious transaction to an AWS S3 Bucket called transdata1:

COMPARE_ANAMOLY_HISTORICALMODEL Job :

The job COMPARE_ANAMOLY_HISTORICALMODEL is realized as an AWS Lambda Function to compare the Anamoly detected with the Historical Data through a Python Function called VerifyTransaction run in a Serverless Function:

BUILD_BEHAVIOUR_MODELS Job:

The Final job runs an AWS Lambda Function called a Python program, taking into account the customer behavior with respect to current notification sent: If he accepted/rejected Transaction and builds the AI Model by training it based on current Customer behavior and model is revised, this is also realized as an AWS Lambda job:

The Full Flow when realized in HWA would look like below and would accomplish the Scenario seamlessly:

Advantages of Implementation in HWA :

• Seamless Orchestration across wide range of AWS Services and OnPremise Core Banking Application.
• All Steps realized natively through Out of the Box Job Types without needing any coding at all.
• End to End Visibility of the Flow under one roof while tracking each step in the flow.
• Automation and retrain of the Model seamlessly.
• Detection of Suspicious event in real time.

About:

HCL Workload Automation has been at the forefront of innovation and being recognized as the “Best AI Assisted Automation Tool” by the Analyst EMA in the recent “EMA Report on Workload Automation and Orchestration 2023.” We also continue as a “Value Leader” in the context of the “EMA Report on Workload Automation and Orchestration 2023.”