web statistics
Building AML solution with FraudAway
top of page
surface-of-the-bill-note-filled-with-flow-of--dotted-data-stream-flowing--on-the-black-bac

Building AML solution with FraudAway


Introduction


Building reports for Anti-Money Laundering (AML) solutions involves aggregating and analyzing data to identify suspicious activities and comply with regulatory requirements. This tutorial is a general guide on how you can approach building reports for AML solutions using FraudAway.



Data preparation


Data preparation typically includes gathering data from various sources, including transaction records, customer information, and external data sources. The specifics of how you run the ETL process can vary based on your system architecture and different data sources. ETL tools or custom scripts are use to extract the necessary payment transaction data from the identified sources, so ensure that you capture relevant fields such as transaction amount, timestamp, payment method, and any other required information and different aspects of the payment process.

In the examples below, we have created anonymized test data set that simulates various scenarios, including different payment transactions types, refunds, withdrawals etc.


KPI metrics


In this step, identify the key metrics and indicators that are relevant to AML compliance. These may include transaction volume, transaction frequency, customer risk rating, and others. These KPI's will be expressed as set of rules that will be executed against the transaction data. In one of the previous tutorial "How to run fraud tests in the bulk mode" we have covered that part in detail. For this tutorial we extended it to cover several aspects: fund transfer checks (both for one-off transactions and cumulative transactions over time), withdrawals (in a similar fashion), behavioural checks to search for outliers within the same peer group and possible transfers from dormant accounts.

AML rule based on four sub-rules

As seen from the picture above, this rule also sends the outcomes of the processing to two separate event streams (where rule triggered either a risk event or not), which will then serve as the building block for the next three important aspects of any AML solution:


Transaction Monitoring Reports: Create reports that highlight unusual or suspicious transactions. This involves setting thresholds and rules for monitoring transactions and generating alerts for potentially fraudulent or high-risk activities.


Watchlist Matching Reports: Implement a watchlist matching system to identify customers or transactions associated with individuals or entities on government-sanctioned lists. Generate reports on matches and any actions taken.


Threshold Breach Reports: Report on instances where predefined thresholds for transactions or customer activities have been breached. This could include unusually large transactions, high-frequency transactions, or other suspicious patterns.



Building Analytics Report's Database


In this tutorial, we have opted to ingest events through AWS Kinesis and store them in a Postgres database. The decoupling of rules from the database provides the flexibility to substitute this solution with any other database upon customer request. It's noteworthy that all input and output data, the outcome of the rules processing, is stored in the same database. This not only facilitates the verification of which rule triggered a risk event and its severity but also enables cross-referencing findings with external validation processes if the need arises.


AWS Lamda consumer, responsible for storing events in the database


Building reports


Once you have defined your schema, which will largely depend on the input data (e.g. "columns of the csv file"), you can plug your favourite analytics tools on top, ranging from Tableau, Looker, PowerBi, QuickSight etc..

It is crucial to reiterate that in our illustration, we store the results alongside the input data. This practice holds immense significance because it affords us the flexibility to fine-tune rule thresholds at a later stage, create new rules informed by insights that may have been initially overlooked, seamlessly integrate novel ML algorithms into the existing rule set, and, of equal importance, establish a seamless connection between risk reports and an external case management tool.


In this instance, I'll be utilizing QuickSight—an intuitive tool that simplifies data analysis to such an extent that it becomes easily accessible for both data scientists and business users alike.


AML reports with QuickSight

Putting it all together


In this video, you'll see how we manage a large transaction file, send it to the AML transaction rule, and visualize the whole process and results in real-time using QuickSight.


If you'd like to learn more, feel free to reach out to us to schedule a demo.



88 views0 comments
bottom of page