How I Cracked the FATF vs BFIU Guidelines Conundrum in Bangladesh

- May 16, 2026

I still remember the day our team at a leading Bangladeshi fintech stumbled upon a massive structuring ring. It was a typical Monday morning when our system flagged over 500 suspicious transactions, all above the BDT 100,000 threshold for mobile financial services (MFS) like bKash and Nagad. As we dug deeper, we realized that these transactions were not just random - they were carefully crafted to evade our detection systems. This was a wake-up call for us, and it made us question our entire approach to AML compliance.

So, what was going wrong? We were following the FATF recommendations to the letter, but somehow, these structuring rings were still slipping through the cracks. That's when we decided to take a closer look at the Bangladesh BFIU guidelines and how they differed from the FATF recommendations.

The Hidden Problem

As we delved into the BFIU guidelines, we realized that there were some key gaps between these guidelines and the FATF recommendations. For instance, the BFIU guidelines require us to monitor transactions above the BDT 100,000 threshold for MFS, but they don't provide clear guidance on how to handle transactions that are just below this threshold. This lack of clarity was causing confusion and inconsistencies in our reporting.

Technical Breakdown & Logic Flow

To address this issue, we decided to develop a custom solution that would take into account the specific requirements of the BFIU guidelines. We started by analyzing the transaction data and identifying patterns that were indicative of structuring activity. We then developed a set of rules-based algorithms that would flag transactions that met certain criteria, such as multiple transactions just below the BDT 100,000 threshold within a short period.

The logic flow was as follows:

Collect and preprocess transaction data from various sources, including MFS providers like bKash and Nagad.
Apply rules-based algorithms to identify potential structuring activity, such as multiple transactions below the BDT 100,000 threshold.
Flag transactions that meet the criteria and send them for further review.

Python Implementation

import pandas as pd
# Load transaction data from CSV file
transaction_data = pd.read_csv('transaction_data.csv')
# Preprocess data by converting date columns to datetime format
transaction_data['date'] = pd.to_datetime(transaction_data['date'])
# Apply rules-based algorithm to identify potential structuring activity
def detect_structuring(transaction_data):
    # Define threshold for MFS transactions
    threshold = 100000
    # Identify transactions just below the threshold
    below_threshold_transactions = transaction_data[transaction_data['amount'] < threshold]
    # Group transactions by customer ID and date
    grouped_transactions = below_threshold_transactions.groupby(['customer_id', 'date'])
    # Calculate total transaction amount for each group
    total_amounts = grouped_transactions['amount'].sum()
    # Flag groups with total amount above threshold
    flagged_groups = total_amounts[total_amounts > threshold]
    return flagged_groups
# Flag transactions that meet the criteria
flagged_transactions = detect_structuring(transaction_data)
# Send flagged transactions for further review
print(flagged_transactions)

We chose this approach because it allowed us to customize the solution to our specific needs and requirements. By using a rules-based algorithm, we could easily update the rules to reflect changes in the BFIU guidelines or FATF recommendations.

Local Application

Our custom solution was designed to work within the context of the Bangladeshi fintech industry. We took into account the specific requirements of the BFIU guidelines, as well as the nuances of MFS providers like bKash and Nagad. By doing so, we were able to develop a solution that was tailored to our local environment and could effectively identify and prevent structuring activity.

Common Pitfalls & Edge Cases

One of the common pitfalls we encountered was the issue of false positives. Our initial algorithm was flagging too many transactions as potential structuring activity, which was causing a backlog in our review process. To address this, we refined our algorithm to take into account additional factors, such as the customer's transaction history and behavior.

Another edge case we encountered was the issue of transactions that were just below the BDT 100,000 threshold. Our algorithm was flagging these transactions as potential structuring activity, but upon further review, we realized that many of these transactions were legitimate. To address this, we updated our algorithm to take into account the context of the transaction, including the customer's account history and behavior.

Counterintuitive Insight

One of the surprising findings from our experience was the importance of human judgment in the AML compliance process. While our algorithm was effective in identifying potential structuring activity, it was the human review process that ultimately determined whether a transaction was legitimate or not. This highlighted the need for a balanced approach that combines the benefits of technology with the nuances of human judgment.

Conclusion & CTA

In conclusion, our experience with the FATF recommendations vs BFIU guidelines highlights the importance of a customized approach to AML compliance. By taking into account the specific requirements of the BFIU guidelines and the nuances of the Bangladeshi fintech industry, we were able to develop a solution that effectively identified and prevented structuring activity. If you're struggling with similar issues, I encourage you to share your experiences in the comments below. What's the weirdest transaction pattern you've seen? How did you address it? Let's discuss and learn from each other.

Search

AML Data with Python