Efficient Financial Pre-Screening Workflows Using AWS Step Functions 1/2

Image by freepik.com

Introduction

Financial institutions need to pre-screen potential customers for credit and other services efficiently and accurately. This requires real-time data aggregation and validation from diverse sources. By leveraging a serverless architecture with AWS Step Functions orchestrating AWS Lambda functions, we can build resilient, horizontally scalable, and maintainable event-driven workflows to manage these operations. In this technical deep dive, I’ll demonstrate how we used AWS Step Functions to design and implement a distributed state machine for asynchronous pre-screening of customer data across multiple micro-services. This solution employs event-driven architecture, parallel processing, and idempotent operations to ensure high throughput and fault tolerance.

This analysis is not intended to serve as a comprehensive guide to AWS Step Functions or as an introductory tutorial. Rather, it’s a case study of how we’ve implemented and optimised this technology to solve specific business and technical requirements in a high-throughput, low-latency environment.

Workflow Overview

Consider the following requirements for a financial institutions’s pre-screening workflow, which gathers and validates data from multiple internal and external sources to determine whether a customer qualifies for the fundings:

  1. Validate Customer Information: Fetch and validate customer’s personal and company’s information.
  2. Validate Bank Statement Reports: Fetch and Ensure the customer has stable spendings and end-of-month balances.
  3. Validate Financial Statements: Check profit and revenue to assess the ability to repay the loan.
  4. Check Credit Reports: Fetch and validate credit scores, existing liabilities and repayment history using credit bureau reports.
  5. Fraud Detection: Detect any fraudulent activities and perform background checks to ensure the customer is not blacklisted or involved in illegal activities.
  6. Ongoing Loan Checks: Assess current loans to determine if the customer can take on additional financing.
  7. Payment History: Verify if the customer has gracefully paid previous internal loans.

Designing the Workflow

Let’s dive into the details of each step in our AWS Step Functions workflow, including how we handle rejections.

All data is captured from service endpoints using API Gateways or Kinesis Streams for asynchronous communication.

Step 1: Validate Customer Information

We start by capturing and validating customer information from various micro-services. Each micro-service provides specific data points such as customer personal information, company legal details, credit reports, and proprietary and partnership information.

{
"StartAt": "ValidateCustomerInformation",
"States": {
"ValidateCustomerInformation": {
"Type": "Task",
"Resource": "arn:aws:lambda:region:account-id:function:validateCustomerInformation",
"Next": "ValidateBankStatements"
}
}
}

Step 2: Validate Bank Statement Reports

The next step is to validate the bank statement reports. We use a Lambda function to process the bank statement reports and ensure the customer has stable end-of-month balances. If validation fails, we stop the execution and post the data to an external service.

{
"ValidateBankStatements": {
"Type": "Task",
"Resource": "arn:aws:lambda:region:account-id:function:validateBankStatements",
"Next": "ValidateFinancialStatements",
"Catch": [
{
"ErrorEquals": ["States.ALL"],
"Next": "Reject"
}
]
}
}

Step 3: Validate Financial Statements

Next, we validate the customer’s financial statements. This involves checking the profit and revenue to determine if the customer can repay the loan.

{
"ValidateFinancialStatements": {
"Type": "Task",
"Resource": "arn:aws:lambda:region:account-id:function:validateFinancialStatements",
"Next": "CheckExternalCreditReports",
"Catch": [
{
"ErrorEquals": ["States.ALL"],
"Next": "Reject"
}
]
}
}

Step 4: Check Credit Reports

We have two steps here: one for external credit bureau reports and another for internal exposure data.

External Credit Report

{
"CheckExternalCreditReports": {
"Type": "Task",
"Resource": "arn:aws:lambda:region:account-id:function:checkExternalCreditReports",
"Next": "CheckInternalExposure",
"Catch": [
{
"ErrorEquals": ["States.ALL"],
"Next": "Reject"
}
]
}
}

Internal Exposure

{
"CheckInternalExposure": {
"Type": "Task",
"Resource": "arn:aws:lambda:region:account-id:function:checkInternalExposure",
"Next": "FraudDetection",
"Catch": [
{
"ErrorEquals": ["States.ALL"],
"Next": "Reject"
}
]
}
}

Step 5: Fraud Detection

Detect any fraudulent activities and perform background checks to ensure the customer is not blacklisted or involved in illegal activities.

{
"FraudDetection": {
"Type": "Task",
"Resource": "arn:aws:lambda:region:account-id:function:fraudDetection",
"Next": "ParallelValidation",
"Catch": [
{
"ErrorEquals": ["States.ALL"],
"Next": "Reject"
}
]
}
}

Step 6 & 7: Ongoing Loan Checks and Payment History (Parallel Validation)

To increase efficiency, we perform ongoing loan checks and payment history validation in parallel. This ensures that the workflow can quickly determine if a customer qualifies for additional financing based on their current and past financial behaviors.

Parallel State Definition

{
"ParallelValidation": {
"Type": "Parallel",
"Branches": [
{
"StartAt": "OngoingLoanChecks",
"States": {
"OngoingLoanChecks": {
"Type": "Task",
"Resource": "arn:aws:lambda:region:account-id:function:ongoingLoanChecks",
"End": true,
"Catch": [
{
"ErrorEquals": ["States.ALL"],
"Next": "Reject"
}
]
}
}
},
{
"StartAt": "PaymentHistory",
"States": {
"PaymentHistory": {
"Type": "Task",
"Resource": "arn:aws:lambda:region:account-id:function:paymentHistory",
"End": true,
"Catch": [
{
"ErrorEquals": ["States.ALL"],
"Next": "Reject"
}
]
}
}
}
],
"Next": "FinalDecision"
}
}

Final Decision State

After the parallel validation tasks, the final decision is made based on the aggregated results.

{
"FinalDecision": {
"Type": "Task",
"Resource": "arn:aws:lambda:region:account-id:function:finalDecision",
"End": true,
"Catch": [
{
"ErrorEquals": ["States.ALL"],
"Next": "Reject"
}
]
}
}

Reject State

If any validation fails, we stop the execution and post the data to an external service regarding the pre-screening results.

{
"Reject": {
"Type": "Task",
"Resource": "arn:aws:lambda:region:account-id:function:postRejectionData",
"End": true
}
}

In this first part of our deep dive, we have outlined the design and implementation of our AWS Step Functions workflow for financial pre-screening. We have detailed each step, from validating customer information to fraud detection and parallel validation of ongoing loans and payment history. This comprehensive process ensures a robust, efficient, and reliable system for determining customer eligibility for loans.

In the next part, we will discuss the architectural challenges we encountered and the solutions we implemented to address them. We will delve into system configuration and management, event-driven step function orchestration, idempotent execution control, and comprehensive logging with DynamoDB. Stay tuned as we explore these critical aspects in Efficient Financial Pre-Screening Workflows Using AWS Step Functions 2/2.

--

--