The Data Visualization Research team is developing Cosmos Explorer, an interface that leverages universe-related visual metaphors to convey information about the billions of transactions processed by Feedzai. Pedro Cruz, professor at Northeastern University, partnered with Feedzai to bring this idea to life by contributing with his creativity and expertise to solve this challenging visualization problem.

When we look out into the universe, we don’t just see emptiness. We see an unimaginable scale: billions of galaxies, each containing billions of stars, each a point of light carrying its own story. No single observer can take it all in at once. Yet with the right instruments, patterns emerge: the structure of the cosmos itself becomes visible.

In the digital realm, there is another universe just as vast and intricate. Every day, hundreds of millions of events flow through Feedzai’s system which assesses them to protect consumers all over the world. Each one is a unique data point (e.g., a purchase, a login, a transfer). Individually, they don’t tell us much. Together they form a living universe of behavior that represents the diversity in people’s lives.

But fraud lurks in everyday transactions, with criminals trying to hide their activities within the sheer volume of transactions. The question is: how can we represent those patterns meaningfully, the normal behaviors and the fraudulent behaviors, the trends and the outliers, to empower data analysts and data scientists in their decision-making processes?

The biggest challenge is scale. No one can look at billions of events one by one. Aggregation helps, but it smooths over the details, which often encode the most interesting signals like the faint outlines of fraud or unusual clusters of activity.

But what if we could see it all at once? Not just a summary, not just a chart, but the entire data universe laid out in front of us?

These are the questions that triggered the project we, in the Data Visualization Research team, call the Cosmos Explorer. Just as astronomers build telescopes to look deeper into space, we are experimenting with tools to look deeper into data. Imagine a screen where billions of transactions appear as points of light. Zoomed out, you see entire galaxies of behavior, the vast shape of normal activity. Zoomed in, you can study the tiniest stars: a single transaction, a single moment in time.

This way of visualizing doesn’t replace dashboards or reports. Those are crucial for fast decision-making and day-to-day operations. What we are exploring is something different: leveraging data visualization to empower the discovery of patterns and outliers. Instead of hiding complexity, we are embracing it and searching for the unexpected shapes that emerge when the raw detail of data is allowed to surface.

Cosmos Explorer is a work in progress, a way for us to research how to push the boundaries of what visualization can do to represent transactional activity. But even now, the potential is clear: to reveal patterns that were previously invisible, and give analysts a new lens to find the hidden structures of fraud and financial crime.

The Origin of Cosmos Explorer

From the beginning, we explored rendering the millions of transactions as semi‑transparent points, and encoding density as brightness so that clusters appear as luminous clouds. But the earliest prototypes looked more like a broken television than a visualization.

In Figure 1, we plotted millions of transactions from a dataset in a long time window; rows encode time while columns encode accounts, and the dense matrix of stripes of circles makes it clear why analysts usually aggregate. Within this maze of points, vertical red stripes correspond to recurring periodic payments, and their regular spacing hints at monthly or weekly cycles.

To explore how the matrix evolves over time we iterated by creating an animated canvas (Figure 2) that gradually fills up as transactions of different amounts, represented by circles of different sizes, arrive. These first experiments convinced us that we needed to go beyond simple point plots, because although we could technically render tens of millions of points, the human eye needs help to see meaningful patterns.

To differentiate high‑value transactions, we tried scaling points by amount. With this choice large transfers appear on the screen as large, semi‑opaque circles that dominate the plot.

These ideas led us to design interactive techniques for browsing transactions. For that, we explored an early version of the interface (Figure 3) where hovering over an account highlights its transactions across months; colored horizontal bars mark unusual bursts of activity. We also tested a fish‑eye lens to magnify a small portion of the dense plot (Figure 4). This approach, inspired by Shneiderman’s “overview first, zoom and filter, then details on demand” mantra, helped analysts inspect specific time windows while still seeing the larger context.

After experimenting with size and focus, we turned our attention to categories. Instead of grouping events purely by time, we aggregated transactions by merchant category or payment type and emphasized each sector with a band of color. In our next iteration (Figure 5), we replaced the earlier category bands with a machine‑like representation: broad swaths of color reminiscent of a spectrogram. The dense tapestry of hues begins to resemble how a computer might “see” the stream of transactions while still highlighting category differences.

Although this emphasized categories, it sacrificed temporal context. So, in Figure 6 we brought the time axis back into view: vertical strips encode hours or days, restoring the sense of chronological progression.

To illustrate the diversity of transactions, we plotted point clouds for six different categories; each panel shows only the points from one merchant sector (Figure 7).

Our final design leap came from embracing a cosmic metaphor. We pinned an image of the edge‑on spiral galaxy NGC 4565 above our desks for inspiration; the photograph, taken by Ken Crawford on 26 May 2012, shows a slender galaxy about 30–50 million light‑years away in the constellation Coma Berenices. The swirling disk and starry background motivated us to treat each transaction as a star (Figure 8). We then sampled star pictures and used them as textures (Figure 9) so that each transaction becomes a tiny star with subtle variations in brightness and color. When applied to the data the result resembles a long‑exposure astrophotograph: bands of light correspond to dense periods and faint streaks reveal outliers.

Visualizing hundreds of millions of transactions

The stages described above culminate in the current Cosmos Explorer (Figure 10). At its heart it is still a scatter plot that displays each transaction by time and amount. Other elements allow for a deeper exploration of the data: a secondary timeline reveals bursts of activity as they unfold by showing the count of events aggregated by minute. On the sidebar, a curated set of filters and insights helps analysts narrow down the information to bring up meaningful details.

We are also exploring the application of natural language prompts. In this context, an analyst can simply type a request asking for “all hotel transactions above two hundred dollars last week” and Cosmos Explorer translates it into precise filters. The scatterplot then highlights those elements in real time, while the insights panel updates with statistics for the new selection. This combination of raw detail and interactive filtering creates a new way of working with data that feels closer to exploration than reporting.

The biggest technical challenge with a tool like Cosmos Explorer lies in rendering so many points at once. Traditional rendering mechanisms that plot every data point in a scatterplot collapse under the weight of millions of entries, let alone billions. To overcome this, we are using octree-based rendering, a technique mostly used for visualizing 3D point clouds of real life scenarios scanned with cameras equipped with LiDAR sensors. The principle is simple but powerful: the dataset is broken down into a hierarchy of cubes, each cube containing either raw points or a sample of their children cubes. When an analyst zooms out, Cosmos Explorer shows a representative sample from higher-level cubes, maintaining the shape of the data without overwhelming the system. As the view zooms in, the system fetches progressively finer detail, until individual transactions come into focus. This level-of-detail approach makes it possible to glide seamlessly from a galaxy of behaviors to a single anomalous star, without losing context.

Representing fraud

In financial datasets, the percentage of fraudulent transactions is usually minuscule, often below 1%. Despite the significant imbalance, fraudulent data points are key to any analysis and, as such, they need to be not only visible, but immediately apparent. To represent this information would be challenging in any visualization due to the significant discrepancy in sample size. The same is true for Cosmos Explorer, only exacerbated by the huge volumes of data. In this project we are experimenting with ways to highlight the presence of such transactions without distorting the visualization.

We have experimented with multiple approaches that led to an implementation that changes the sizes and color of fraudulent points, allowing regions containing fraudulent transactions to pop up on the canvas and take precedence over non-fraudulent transactions (Figure 11). Small guidelines further help locate such elements, aiding the viewer’s navigation through the Cosmos Explorer when they are focused on fraudulent transactions.

At a higher level, looking at the Cosmos Explorer as a whole allows us not only to see each transaction, but also to analyze the overall “health” of the transactions being processed through shades of color: whitish tones show where things are normal, and red highlights areas with fraud, providing a quick sense of which areas are “healthy” and which ones need attention.

We have always looked at the stars to find meaning, to connect dots across the darkness. Now we are learning to look at the universe of data in the same way. The signals are there, but hidden. Cosmos Explorer is the key to bringing them to light.

A special thank you to João Palmeiro, Diogo Duarte, Rita Costa, Pedro Nuno Silva, Pedro Cruz, Max Spencer, Tiago Simão, and Cláudio Correia, who helped in widely different areas of the project. Without them, Cosmos Explorer would not have been possible.

Uncovering the Shape of Fraud with Cosmos Explorer: Visual Metaphors Behind Millions of… was originally published in Feedzai Techblog on Medium, where people are continuing the conversation by highlighting and responding to this story.

When we need to visualize and interact with millions, or even just thousands, of individual points while analyzing data, we typically resort to rendering them in the browser using a canvas. The other common approach for the web, SVG, doesn’t scale when the number of individual elements increases to such quantities. However, while solving one problem, canvas charts introduce a new challenge: accessibility.

Although SVG charts are not accessible by default, they can be by design. Each part of an SVG chart has a corresponding element on the web page, allowing for a programmable, accessible experience for screen reader users. We can simply think of SVG as HTML. On the other hand, a canvas chart is just like a PNG image. If a screen reader user tries to learn more about a canvas chart, unless the developer has prepared a detailed description of it, they will just hear the word “image”. There’s no way to get an idea of what one of these charts represents, let alone extract any insights.

For static charts, the solution can be as simple as preparing a description and integrating it into the rendered chart. However, for platforms leveraging dynamic, large datasets, automatically generating these descriptions is not a simple task, especially for charts like scatterplots where data distributions can assume countless forms.

At Feedzai, we started exploring ways to generate data distribution-aware descriptions for scatterplots from their respective images using recent multimodal AI models. When the raw data is not available, or the datasets are composed of several thousand or million instances, relying on chart images and these models becomes tempting. This combination has the potential to generate such descriptions and serve them alongside their respective charts, significantly improving the accessibility of canvas charts.

That said, we focused on two main directions: using AI models to directly generate the descriptions, and using AI models to extract structured data (imagine a list of clusters and their respective center coordinates, for example) that will populate a predefined description template. The initial results, however, were mixed, and it wasn’t clear if we were on the right track to ensure adequate descriptions.

So, before moving on to further testing, we carefully reviewed the literature. Although benchmarks and other interesting findings are scattered all over the place, they rarely cover scatterplots and their related tasks. We therefore changed the plot and designed a dataset + benchmark to expand the general understanding of AI models when applied to charts, specifically scatterplots. We focused on evaluating the baseline performance of these models in identifying clusters and outliers at scale — both, if present, should be described properly.

The work culminated in the “Benchmark It Yourself (BIY): Preparing a Dataset and Benchmarking AI Models for Scatterplot-Related Tasks” paper, presented at the GenAI, Agents, and the Future of VIS workshop during IEEE VIS 2025. This blog post covers the main results and conclusions after running the benchmark in question.

Dataset and Benchmark

The dataset consists of 18,921 synthetic scatterplot images created from 6 data generators (371 different data samples), 17 chart designs, and 3 image sizes. The number of clusters varies between 0 and 6, while the contamination level, when there are outliers, varies between 0.001 and 0.01. We chose to inject a relatively small number of outliers, keeping them well-distanced from the clusters to evaluate the detection of points that are clearly anomalous and relevant to report. In the end, each scatterplot was automatically annotated for clusters and outliers after converting the respective bounding box and point coordinates to screen coordinates (pixels).

The benchmark was run on a stratified sample of 1,725 scatterplots and for 5 tasks, each defined by a prompt composed of an instruction and a response format:

• Cluster counting for the number of clusters.
• Cluster detection for the bounding boxes of each cluster.
• Cluster identification for the point coordinates of each cluster center.
• Outlier counting for the number of outliers.
• Outlier identification for the point coordinates of each outlier.

In addition to the different tasks, 10 proprietary models from Google and OpenAI were evaluated, along with 3 different prompting strategies: zero-shot, one-shot (prompt + 1 example), and few-shot (prompt + 6 examples).

For the counting tasks, two performance metrics were computed: Accuracy and Mean Absolute Error (MAE). For the remaining tasks, Precision and Recall were considered with specific thresholds: an Intersection over Union (IoU) of 0.75 for bounding boxes and a Euclidean distance of 10px for point coordinates.

Results

The overall results for each task are summarized in the charts below. Each is accompanied by its main highlight. Feel free to explore each chart or jump straight to the next section for the key takeaways.

Takeaways

Based on the results, the main considerations when combining scatterplot images and AI models are as follows:

1. Give priority to few-shot prompting. This prompting strategy consistently outperformed zero-shot prompting across all models and tasks (top models achieved over 90% Accuracy in counting tasks). It is also useful for handling zero-answer scatterplots.
2. Avoid localization tasks. OpenAI and low-cost Google models prompted with strategies similar to those evaluated are unreliable for localization tasks (e.g., detecting clusters) involving scatterplots.
3. Invest in other components first, not chart design (page 4 for more details). Chart design is fundamental for humans, but it’s a secondary factor when fed into AI models. Nevertheless, it can be beneficial to avoid chart designs with wide aspect ratios (16:9 and 21:9) or seemingly random colors.

Further Reading

Since this blog post doesn’t cover all the relevant aspects of the dataset and benchmark, feel free to read the paper, check out the associated GitHub repository, or watch a short presentation about it.

If you have any questions or feedback, let us know in the comments section.

Diogo Duarte, Pedro Bizarro, Rita Costa, and Sanjay Salomon: thank you so much for your thoughtful feedback that helped me shape this blog post!

BIY: Preparing a Dataset and Benchmarking AI Models for Scatterplot-Related Tasks was originally published in Feedzai Techblog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Moving beyond binary classification provides novel insights.

In the real world, scams rarely present themselves in black and white. Fraudsters exploit nuance, impersonate legitimate brands, and mask malicious intent with seemingly ordinary behavior. That’s why Feedzai has launched ScamAlert (patent pending), a Generative AI-based system innovating on the current paradigm of scam prevention, in response to this growing challenge.

Traditional detection systems treat the problem as a binary choice: scam or not a scam, often outputting an estimated “scam likelihood” measure. This value, even if accurate, doesn’t tell users why something is risky or what they should watch out for, leaving them with little guidance on how to stay safe.

The binary approach can often suffer from a lack of context. While a text message may look suspicious in a vacuum (e.g., a payment request via a less safe method) the user may have other reasons to believe in its legitimacy, such as a past history of such requests. Consequently, an incorrect risk estimate based on missing context may lead users to distrust the system’s abilities.

ScamAlert, on the other hand, makes judgements on what it knows. Users submit a screenshot of the suspected scam, and ScamAlert identifies observable red flags, patterns or behaviors that are often associated with fraud, such as suspicious links or spelling errors. This approach empowers the user with interpretable insights into the detected risk signals, instead of a vague numeric value. This places the user in the driver’s seat, by presenting them with the facts and enhancing their awareness and judgment.

To fully understand a systems’ ability to perform this task, we pair this labelling approach with a rigorous evaluation and benchmarking protocol. We test the consistency of model outputs for the same input; the model’s ability to justify its decisions and its overall performance, embodying the Robust, Transparent, and Tested pillars of Feedzai’s TRUST Framework.

ScamAlert is a good example of an application of GenAI for a purpose other than increasing productivity, focusing on improving fraud prevention. We will show how a systematic evaluation and benchmarking framework is crucial to faithfully measure the performance of the full system, mitigate known GenAI limitations (such as hallucinations) and increase the trust in AI-powered workflows.

In this post, we’ll walk you through:

• Why binary scam detection fails in ambiguous or unverifiable cases.
• How a red flag-based multi-label classification system works.
• How we create a thorough benchmark to reliably evaluate ScamAlert.
• How we evaluate ScamAlert and multimodal models using red flag recall, precision, and instruction adherence.
• Practical trade-offs between accuracy, cost, and latency in scalable deployments

Let’s explore how a more nuanced, interpretable system can raise the bar for scam prevention.

Red Flags

Rather than determining the likelihood of a message or an online listing being a scam, ScamAlert focuses on identifying which specific red flags are present. This shift leads to more interpretable outputs, helping users understand why something appears suspicious instead of collapsing everything into a binary decision or a score. It also introduces a more flexible framework, allowing domain experts to take control over what ScamAlert has detected.

This structure also transforms how we evaluate ScamAlert’s accuracy. By breaking predictions down into individual red flags, we gain visibility into which behavioral patterns (e.g., urgency, impersonation, or financial requests) are being consistently recognized, and which ones are being missed. This kind of transparency enables more focused analysis, helping teams identify specific areas for improvement.

Just as importantly, it supports ongoing auditing of ScamAlert as fraud tactics shift. As new scam patterns emerge, analysts can evaluate whether ScamAlert’s current red flag coverage is sufficient, and introduce new flags as needed. This modular evaluation strategy ensures ScamAlert remains aligned with a constantly evolving threat landscape, without requiring a full reset every time scammers change tactics.

To show how this works in practice, let’s look at a fictitious example used for evaluation purposes with a few red flags:

In this case, four key behaviors may be identified that are often linked to scam attempts:

• Unusual Channel: The sender claims to be a colleague but reaches out via text message. This is unusual, as formal internal communication typically happens through company email or approved platforms.
• New Phone Excuse: The unfamiliar phone number is explained with the excuse of using a “new” phone. This is a common tactic used to lower suspicion and discourage questions, masking the fact that in reality an attacker device is being used.
• External Transfer: The sender asks for a significant money transfer to an external bank account. This is a strong indicator of a potential scam.
• Heightened Urgency: The message stresses urgency, framing the request as time-sensitive and business-critical. Scammers often rely on this pressure to get quick, unquestioned responses.

To formalize these observations, we could codify the identified behaviors using the following labels: Unusual Communication Methods, Unknown Sender, Requests for Money, and Urgency Tactics and Pressure. Other common indicators, not used in this example, include, Suspicious URL Shortening, frequently used in phishing attacks to obscure malicious domains, and Suspicious Attachments, which may contain malware capable of compromising the recipient’s device.

Evaluating System-level Performance

However, to systematically evaluate the performance of ScamAlert as a versatile system, we must test it under a wide variety of possible scam patterns and mediums, such as emails, listings, phishing websites, etc. Furthermore, since ScamAlert can be powered by different multimodal models, we also need a way to evaluate how the system performs under different models, and whether these meet our needs and limitations in regards to cost and/or latency.

Therefore, designing a comprehensive benchmark is crucial: one that includes a wide and diverse set of red flags reflecting real-world variation. With a standardized benchmark in place, we can evaluate how the system’s performance varies when changing not only the underlying AI model, but also its parameters, and other elements within the system.

A reliable benchmark also allows us to keep up with the rapid pace of new multimodal model releases. Maintaining a well curated dataset allows us to quickly determine whether a new model can contribute to a better red flag detection performance, making it possible to iterate quickly and ensure ScamAlert evolves alongside the ever expanding field of GenAI, while mitigating known limitations like hallucinations.

To tackle this challenge, we developed a benchmark dataset composed of a large and diverse collection of screenshots, including product listings, emails, and text message conversations. These span multiple language and include attacks such as images unrelated to the use case. Each example in the dataset was manually annotated to indicate the presence or absence of specific scam-related red flags. As we created these annotations, we constructed a curated taxonomy of red flags, which together define the label space for our multi-label classification task.

Identifying Red Flags with ScamAlert

Using ScamAlert involves inputting a screenshot into the system, which has been set up to identify a wide variety of flags. Armed with expert-level knowledge on current scam tactics and how to identify them, ScamAlert begins by verifying the submitted user screenshot, employing a multimodal model to analyze the image and extract key information. The model response is then thoroughly validated by ScamAlert to ensure that the delivered insights are high-confidence and well-founded.

ScamAlert outputs a structured response with three parts: (1) a list of the detected red flags, using our predefined nomenclature, (2) a short explanation for why each red flag was identified in the given screenshot, and (3) a list of recommendations of next steps based on those detections.

The explanations serve two key purposes. As these are generated by a Large Language Model (LLM), having the model explain its reasoning, similarly to Chain-of-Thought prompting, can improve the system’s accuracy. Second, the explanations provide a layer of interpretability, helping us determine whether the predictions are based on actual, observable features in the screenshot.

The recommendations provide the user with safe courses of action, focusing on guiding the user in how to avoid falling victim to a potential scam. These often include suggestions not to click any links or attachments, or blocking further communications from a given source.

To produce a highly informative output, ScamAlert must balance two key goals: capturing all the red flags that are actually present, while minimizing the inclusion of incorrect or irrelevant ones. We can quantify these principles under our labeling framework by using red flag recall, the percentage of true red flags that ScamAlert successfully identifies, and red flag precision, the percentage of predicted red flags that are actually correct.

To measure performance across both dimensions, we then compute the red flag F1 score, which is the harmonic mean of precision and recall. This approach rewards models performing well on both metrics.

Evaluating System-level Reliability

Our evaluation looks beyond just ScamAlert’s ability to detect relevant red flags. We also assess how reliable the underlying multimodal model is at following explicit instructions. This is a critical requirement for an AI model intended to operate in structured or automated workflows. Specifically, we treat failures to follow the expected output format as errors. We focus on two types of mistakes:

1. Formatting errors, where the model’s output is not valid and cannot be parsed; and
2. Invalid predictions (hallucinations), where the model includes red flags that aren’t part of the predefined list it was given.

By including these criteria, we aim to evaluate not only what the model predicts, but how consistently and correctly it communicates those predictions.

Evaluating Operational Costs

Beyond detection accuracy, it’s important to account for practical considerations that would impact real-world deployment of the ScamAlert system, especially when operating at scale for a large client base. In these scenarios, both cost and latency of model queries become critical performance factors. A model that delivers similar accuracy but with faster response times or lower inference costs is clearly more suitable for production use. Evaluating these trade-offs ensures that our system is not only effective, but also efficient and scalable in real-world environments.

In summary, our evaluation considers four key dimensions: (1) the system’s ability to detect red flags accurately, (2) how the underlying model adheres to the specified output format and label set, (3) the monetary cost associated with each query, and (4) the latency of its responses.

Benchmark Results

To evaluate how different multimodal models impact ScamAlert’s red flag detection capabilities, we tested a variety of such models on our benchmark dataset. Each model was evaluated by sending several screenshots, one at a time, through the ScamAlert pipeline, allowing us to observe performance under realistic usage conditions. For each screenshot, we repeated the evaluation three times to account for the variability inherent to generative models.

Here, we report the results for a selection of commercially available multimodal models (as of November 2025) in terms of average F1 score across the dataset.

DISCLAIMER: These results are only valid for the tested prompt and are specific to the task at hand. Model rankings vary significantly across benchmarks and should not be interpreted as absolute evaluations of each model’s image processing ability.

Overall Results

In the following plot, we display the results for ScamAlert’s performance and operational costs when using each of the multimodal models being tested. To calculate these results, we assume that each instance for which the model failed to output a valid response corresponds to an empty prediction (i.e., no red flags). If a model hallucinates red flags which are not present in our curated list, these are ignored.

Several recent models (Gemini 3 Pro, Gemini 2.5 Pro, GPT-5, Claude 4, Claude 3.7) offer “hybrid” reasoning capabilities. These models allow users to set a “thinking budget” in which the model can generate intermediate reasoning steps to solve a problem, usually boosting performance at a far greater cost and latency. To keep comparisons balanced, we set the thinking budget of all models to 0, as speed is an important aspect of this task.

However, Gemini 2.5 Pro, Gemini 3 Pro, and GPT-5 do not allow for completely disabling thinking, allowing only for limitations on the reasoning effort: Gemini 2.5 Pro lets users define maximum reasoning tokens, while 3 Pro and GPT-5 allow for the selection of pre-defined reasoning levels. We set these models at their minimum allowed thinking budget (128 tokens for 2.5 Pro, “Low” for 3 Pro, and “Minimum” for GPT-5), and differentiate them in the following plots by including a box around the model. We also highlight the models in the pareto front, that is, models that dominate others in terms of cost-performance tradeoffs.

For a reference on how higher thinking budgets may impact these models, we run the 4 GPT-5 reasoning settings: Minimum, Low, Medium (Default), and High; and the 2 Gemini 3 Pro reasoning settings: Low and High. We display the values for the default setting (“Medium”) for both GPT-5 nano and GPT-5 mini.

*Note:

• Gemini 3 Pro corresponds to its November preview.
• Gemini 2.5 Flash corresponds to its May version.
• Gemini 2.5 Pro corresponds to its May version.
• These perform similarly on visual tasks to the latest stable versions.
• Gemini 2.5 Flash Lite corresponds to its June 5th preview — just before its release on the 22nd.

We highlight the following findings (note that the x-axis is logarithmic):

• GPT-5 provides a significant performance over competitors, but only if expending effort equal to or above the “Low” setting, incurring significant cost increases.
• Gemini 3 Pro at its lowest reasoning budget performs better than GPT-5 at its lowest reasoning budget, while being significantly cheaper.
• Notably, all of the Claude Sonnet versions do not match the performance of similarly priced OpenAI or Gemini models.
• Gemini “Flash” and “Flash Lite” versions dominate the competing GPT mini and GPT nano offerings.

Plotting the models’ performance versus their latency, again on a logarithmic x-axis, only heightens these differences:

• Higher reasoning levels produce substantial increases in latency for Gemini 3 Pro and GPT-5.
• Notably, at their lowest budget, Gemini 2.5 Pro is significantly faster than Gemini 3 Pro and GPT-5.
• While GPT-5 mini and nano provide significant latency gains over the main variant, at the default effort, they are still slower than all other models we tested.
• Surprisingly, Gemini 2.0 Flash Lite and 2.5 Flash Lite versions take approximately the same amount of time to provide answers as their Flash counterparts.

Detailed Analysis: Instruction Following Impacts on Performance

In the following plot, we display the results for all reasoning levels for the 3 variants of GPT-5: main, mini, and nano. At a fifth of the token cost, nano is expected to perform worse than mini, but we observe the opposite.

This strange pattern is compounded by the fact that, as seen previously, both GPT-5 mini and nano perform worse than their equivalent 4.1 counterparts.

This discrepancy is explained by the fact that both GPT-5 nano and GPT-5 mini have a tendency to generate red flags which are not part of the input list, with the latter doing so at a much higher rate than the former.

Many times, these are semantically equivalent to the correct option, such as “Suspicious Shortened Link” instead of “Suspicious URL Shortening.” However, as we wish to prioritize not only image processing abilities, but also the model’s instruction following, these predictions are ignored, and only case-insensitive matches are accepted.

Other models exhibit the same pattern seen previously, albeit at lower rates. In the following plot, we show the 8 models with the highest rate of unknown flag generation. This phenomenon is possibly responsible for the lower performance of GPT-4.1 nano when compared to Claude 3 Haiku, for example.

Detailed Analysis: Robustness of Results

In order to assess the consistency of these rankings, that is, whether the performance significantly changed across different runs, we ran the entirety of the benchmark three times. In the following plot, we demonstrate that considering either the worst or best trial for each model would not result in a significant re-ordering of the results.

The Importance of Benchmarking

These results show the importance of having a consistent benchmark and the capacity to systematically evaluate the models for the task at hand.

The results we presented above may not be aligned with general public benchmarks, emphasizing the necessity of a rigorous and systematic evaluation for the specific task. At Feedzai Research this task is a key step in our projects, as we have shown in our public benchmarks and multiple datasets.

It is not our intent to generalize any conclusion to other use cases, as these results show the performance of the models for a very specific task, with the same prompt, for a highly specialized dataset. Different tasks and datasets, even if similar on a surface level, require a specific evaluation, nwhich may offer completely different results.

Conclusion

As scam tactics evolve to bypass increasingly sophisticated spam filters and exploit new communication channels, systems that rely on rigid definitions or static rules quickly fall behind. ScamAlert is designed to meet this challenge head-on, offering a flexible, interpretable framework that can evolve alongside the threat landscape.

By focusing on red flags rather than binary judgments, ScamAlert provides more transparency and control. It allows domain experts to define what suspicious behavior looks like, and gives analysts the tools to track exactly which patterns are being recognized and which are being neglected.

Tracking performance in this context is a multifaceted challenge. We need to know whether the system can detect red flags, but also whether the underlying multimodal model can follow instructions, produce valid outputs, and operate efficiently at scale. Evaluation, therefore, needs to cover both detection accuracy and operational reliability.

Our benchmark is designed with this in mind. It enables fast, consistent evaluation of new LLMs as soon as they are released, ensuring ScamAlert can quickly adopt improvements in model capabilities while maintaining a responsible and disciplined approach to system updates.

Update: This post was updated on the 26th of November to include the results relating to Gemini 3 Pro, currently in preview.

Benchmarking LLMs in Real-World Applications: Pitfalls and Surprises was originally published in Feedzai Techblog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction

Over the years, we have evolved from using simple, often rule-based algorithms to sophisticated machine learning models. These models are incredibly good at finding patterns in large datasets, but due to their complexity it is frequently challenging for a human to understand why a certain input leads to its respective output. This is especially problematic in areas where high-stakes decisions are being made and where human-AI collaboration is critical.

This is why model explainability has gained traction in recent years. The aim of explainability methods is to shed light on what properties of the data contribute to a machine learning model’s output.

Ideally, such explanations should be similar to how a human would explain its decisions to a peer. In particular, humans make use of high-level concepts that are easy to grasp for other people. For example, a human would explain, “there was a sudden burst of transactions in a short time” as opposed to, “the average delta time feature is much smaller in a recent short time-window compared to a long time-window, and the count of transactions feature increased substantially in the same recent time-window.”

Moreover, when explaining choices and decisions, humans are free to reflect on these decisions by reasoning about hypothetical alternatives. For example, we could ask, “if this email address would be considered suspicious, would I trust this request?” Current explainability methods fail to incorporate both properties: the explanations are often much more complex than typical concepts humans would use; and they don’t allow for reasoning. As a result, these limitations impede the usefulness of current explainability methods in many practical applications.

In this blog post, we will describe a new explainability method that addresses these issues. We’ll try to refrain from discussing too many technical details and focus on the intuition behind the method, but readers interested in the technical justifications are referred to our publication of this work at the 2024 CLeaR conference.

Background

Feature-based explanations

The vast majority of explainability methods can be grouped under the “feature attribution” umbrella. Feature attribution techniques assign an importance score to each feature in the input, where a higher score typically reflects a feature having a large contribution to the model output. In this way, human analysts can gain insight into the model decision-making process. We previously wrote about the application of these methods at Feedzai in an earlier blog post.

However, sometimes the feature attribution methods themselves are not very helpful. Especially when the number of features is large and there is little knowledge on their connection to higher level concepts, attributions may be spread over a large number of such features and it becomes difficult for a human to meaningfully understand and correct model decisions.

A motivating example

Consider a hypothetical machine learning model that is tasked to predict the probability of a person having a heart attack in the following year. The model considers many features, such as blood exam data, tracking data from a health app, etc. An explainability method based on feature attributions, such as SHAP (Lundberg and Lee, NeurIPS, 2017), would produce results as shown in Figure 1. In this example, levels of LDL cholesterol, BMI, and blood glucose levels are seen as the most important features for the model. But many other features contribute with slightly lower scores. The more features there are, the less clear it is for a human how to interpret their impact.

Especially when human-AI collaboration is time sensitive, it is important to provide more interpretable explanations. One step in that direction is to offer explanations based on human-understandable, high-level concepts instead of on individual features.

Concept-based explanations

As discussed in the previous section, explainability methods that assign importance to individual features can be opaque themselves. What if, instead of basing explanations on features, we directly assign attributions to higher-level concepts? In other words, we are interested in developing a method that assigns importance to human-defined concepts, where higher importances indicates a stronger contribution to the model output. We therefore move from feature-based explanations to concept-based explanations.

While concept-based explanations address some feature-based method issues, new problems emerge. First of all, we need to define the concepts, which is typically a task for domain experts but may be automated eventually when concept extraction methods become more powerful. Secondly, we need to connect the inputs, concepts, and model outputs in our explainer.

One recent approach achieves this by designing a specific neural network architecture, known as the Concept Bottleneck Model (CBM, Koh et al, ICML, 2020). The CBM essentially connects the inputs to an intermediate layer where each unit is forced to represent a concept (the bottleneck layer), from which connections flow to the outputs. Since information has to flow through the bottleneck layer representing the concepts by construction, one can simply read out the activation of each unit of this layer to know how much a concept is ‘active’ for a certain input. Returning to our hypothetical example of the model to predict cardiac arrest, such a CBM could be schematically depicted as in Figure 2. In this network, the bottleneck layer represents concepts such as “smoking,” “drinking, etc.

However, there are still issues with this method. Firstly, since the concepts may not be perfect predictors of the model’s objective, there is typically a trade-off between the accuracy on the original task and the accuracy on the concept predictions. In other words, a CBM that is better at predicting concept labels will be worse at predicting cardiac arrest, and vice versa.

Secondly, because the concepts may not be independent of each other, it is not possible to reason about alternative outcomes by simply “intervening” in the bottleneck layer. For example, we may be tempted to activate the “Exercise” neuron maximally in the bottleneck layer to answer the question, “How would my likelihood of cardiac arrest be impacted if I exercised more?” Doing so, however, fails to take into account that exercise may also affect the “Weight” and “Cholesterol” concepts.

To solve the first problem, we will explain what we mean by post-hoc explanations. After that, we will talk about the causality aspect.

Post-hoc explanations

As we saw in the previous section, the CBM learns two tasks simultaneously: predicting concepts from inputs and predicting outputs from concepts.

This typically incurs a trade-off in performance between both tasks. Instead of this self-explanatory property, one can also develop post-hoc (Latin for “after the event”) methods, which are applied after the model is trained. In other words, we have a first model to learn the mapping from inputs to outputs, and after that model is trained, we construct a second model to explain the first.

In this way, we do not interfere with the performance of the first model. We typically do not require any specific knowledge of how the first model is constructed, as long as we can pass it an input and receive the respective output. The first model is therefore usually referred to as the black-box model.

One way to achieve this is to train the explainability model to mimic the black-box model’s input-output relationship. We can then impose any constraint on the explainability model, without affecting the performance of the original black-box model. The technique of using a new model to learn from the behavior of a black-box model is known under the name of “model distillation” Importantly, to distill a black-box model, we only need access to input-output pairs, but no further details of the black-box are needed. The explainer is therefore free to use any other algorithm or architecture.

Now that you have learned about post hoc methods and model distillation, let’s look into why causality is important when we want to reason about our model predictions.

Causal explanations

As explored in the previous sections, post-hoc, concept-based explanations can yield more interpretable yet highly performing models. However, we’d like to add one more property to our explainer: the ability to reason about alternate situations.

For example, a model could predict that a patient has a high probability of a cardiac arrest because of high cholesterol, increased weight, and high alcohol consumption. We could ask the question: what would the model predict if we lowered the alcohol consumption data? In a CBM model, all concepts are assumed to be independent; and hence, if we manually lower the alcohol consumption concept we obtain output that ignores the interactions between alcohol consumption and other concepts such as weight. This type of reasoning about alternate situations is called “counterfactual reasoning.”

The solution to this is to learn a Structural Causal Model (SCM) of the concepts, which learns how much each concept causally depends on another. In the language of SCMs, a causal dependency of B on A is denoted as

A → B

When we connect multiple concepts through their causal dependencies, we must adhere to the following properties. First, since cause and effect are directed, there is always a single direction to move between two concepts that depend on each other. Second, since one concept can never be a cause of itself (even through intermediate concepts), following the directions in the graph, one can never return to its starting point. The first property of a graph is called “directed,” and the second is called “acyclic” (no cycles). Hence, an SCM has a Directed Acyclic Graph (DAG) at its heart.

Given the DAG encoding the causal dependencies between concepts, we can train a model to learn the complete SCM, extending the DAG with concept attributions (how much each concept is present for each input), and attributions for the connections (how strong the concepts depend on each other). Without going into too many details, the training involves casting the SCM into a neural network language, after which these attributions are learned from a training dataset. The SCM then allows us to perform actual counterfactual reasoning. Returning to our example above, let’s consider the SCM in Figure 3.

Here, one can see how, for example, alcohol consumption causes both higher cholesterol and higher weight. If we want to test the counterfactual statement “what if we lower our alcohol consumption,” we would manually lower the concept attribution for “drinking,” which in turn would affect the “weight” and “cholesterol” concepts before changing our prediction of “cardiac arrest.” This reasoning, which takes into account the dependencies between concepts, is completely lost in the previously described bottleneck models.

DiConStruct Explainer

In the previous sections, we discussed the properties that an ideal explainer should possess. We would like it to be:

1. concept-based, to provide better interpretability to humans;
2. post-hoc, to not affect the black-box model performance. As discussed, we will use model distillation to train our explainer;
3. causal, to allow us to reason about counterfactual situations (e.g., alternatives to what we observed). This will take the form of a Structural Causal Model (SCM) within our explainer.

From these three properties, it also becomes clear why our method is named DiConStruct (Distillation, Concept-Based, Structural Causal Model).

On a high level, the DiConStruct explainer is organized as depicted in Figure 4.

The inputs are the data (X) and a DAG of the concepts (which we assume to be created by domain experts and/or extracted from data using specific methods). The DiConStruct explainer then contains two components. The first component, the Exogenous Model, is a neural network that was trained to predict concept-specific weights from the inputs. These weights encode the extent to which certain concepts are present, without considering the causal contributions from other concepts.

They are then combined with the DAG into the second component, the Concept Distillation SCM, to incorporate the causal interactions between concepts. Given the SCM, we can extract causal explanations in the form of a causal graph and concept attributions. It is important to note that the mapping from inputs to concepts is learned in a supervised manner, meaning that data annotated with concept labels is necessary.

Finally, the inputs will also be ingested by the black-box model and give rise to the outputs (Yᵦ). The SCM from our DiConStruct model also contains the prediction Ŷᵦ, which is trained to mimic the black-box output Yᵦ.

Results/Examples

We tested the DiConStruct explainer on two real-world datasets. One is a publicly available dataset for classifying bird images (CUB-200–2011), the other is an in-house fraud detection dataset (Merchant Fraud).

On both datasets, we train feedforward neural networks as our black-box models. In Table 1, we report the performance of multiple variations of DiConStruct on both datasets, compared to multiple baselines. We report the main classification performance (which we chose to be recall at a 5% false positive rate), the concept performance, i.e. how accurately are we predicting the concepts for each instance (quantified by the average accuracy over the concepts) and the fidelity, i.e. how good is DiConStruct mimicking the black-box model decisions (using 1-MAE, the mean absolute error).

Since DiConStruct methods are not affecting the black-box model, we can see that the task performance is equal to the black-box performance. Moreover, the fidelity of DiConStruct methods is always very high, meaning that it learned very similar input-output relations as the black-box model. Finally, the concept performance of DiConStruct is on par with the state-of-the-art baselines, but of course with the added advantage that our method provides causal explanations.

In Figure 5, we show one example of a causal explanation from our DiConStruct method; for an instance in the Merchant Fraud dataset that was predicted to be suspicious by the model. We can see that Suspicious Device is the concept that is deemed most important for the decision. We can also observe that Good Customer History has a very low likelihood and therefore increases the likelihood of downstream concepts related to fraud. This is indeed expected, since Good Customer History is a concept related to legitimate events. With these causal explanations, one can not only understand which concepts are most relevant but also how they causally relate and interact with each other.

Conclusions

In summary, we introduced a novel method for model explainability that addresses some limitations of current approaches, namely, providing explanations in the form of human-conceptual terms and incorporating causal principles to enable counterfactual reasoning based on the provided explanations. With our method, we aim to improve human-AI interactions, by providing explanations that are more aligned to how humans would explain decisions to each other.

CAUSAL CONCEPT-BASED EXPLANATIONS was originally published in Feedzai Techblog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Detecting financial fraud is like finding a moving needle in a shifting haystack. Fraud accounts for a tiny fraction of financial transactions, often less than 0.1%. At the same time, fraudsters are constantly adapting their tactics to evade detection. And this happens within a live and dynamic environment, where financial behaviors and technologies are changing over time. In short, this is an exceptionally difficult problem for financial institutions.

With the rise of digital banking and new technologies like GenAI, this problem is becoming even more challenging. In fact, fraud schemes are spreading faster, growing more sophisticated, and becoming increasingly coordinated across geographies. Meanwhile, many financial institutions still rely on detection systems that are either too rigid (e.g., relying on handcrafted rules) or too narrow (e.g., dependent on custom AI models), and neither option can keep up with the pace of change.

At Feedzai, we’ve developed a new approach. In this blog post, we introduce Feedzai TrustScore, part of the Feedzai IQ™ solution. This is a state-of-the-art AI solution that combines the aggregated knowledge from our network of $8.02T yearly processed events to detect threats earlier, adapt continuously, and safeguard financial systems with speed and precision.

Traditional Fraud Detection: Catching a Moving Target With a Fixed Net

Every year, millions of people fall victim to financial fraud or scams, with a recent report revealing an average loss of over $2,000 per victim. To protect their customers, banks and other financial institutions have made great efforts towards detecting these suspicious transactions, sometimes temporarily blocking them, conducting internal reviews, and contacting the account owner to validate the activity.

However, this is an inherently adversarial task, as malicious actors adapt to whatever detection system the banks have in place. These players are always searching for “cracks in the system” or leveraging new tools such as GenAI to develop more sophisticated attacks.

While fraudsters are quick to incorporate new technologies in their attacks, most traditional fraud detection systems still rely on either rule-based approaches or institution-specific custom AI models. Rule-based systems typically consist of a set of manually defined conditions that describe known fraud patterns. Custom AI models, on the other hand, are trained on historical data from that specific institution only.

While these approaches can be useful, both present several shortcomings:

• Slow to deploy: Both rule-based systems and custom AI models require substantial time and effort to design, tune, and validate before they can be deployed. This often involves months of work by analysts, data scientists, and domain experts.
• High maintenance: These systems demand constant manual updates and oversight to remain effective, especially as fraudsters adapt their tactics. This creates a continuous operational burden on fraud teams.
• Reactive and narrow in scope: Whether rule-based or AI-driven, conventional detection systems are developed using knowledge from a single institution, offering a narrow and siloed view of fraud. This makes them inherently reactive (learning only after fraud has occurred) and blind to emerging fraud patterns or schemes that haven’t yet appeared in their own environment.

These constraints are especially problematic given the nature of modern financial crime: fraudsters operate across borders and institutions, sharing techniques and exploiting gaps in visibility. It raises the question: if attackers are collaborating, why aren’t defenders doing the same?

Introducing: Feedzai TrustScore

Feedzai TrustScore, part of Feedzai IQ™, addresses these limitations by relying on pre-trained AI experts, which encode the collective knowledge from Feedzai’s broad network of partners. Unlike traditional detection systems, this solution is ready-to-use, doesn’t require months of historical data collection, has built-in processes for continuous refreshing, and can leverage shared intelligence to prevent fraud attacks sooner, all while guaranteeing strict data privacy standards.

How does it work?

Feedzai TrustScore is built on a Mixture of Experts (MoE) architecture¹, a modular approach where multiple expert models are developed on different environments or fraud scenarios, and then are combined to produce the final risk decision.

A real-world analogy to this would be to diagnose a disease by consulting a panel of medical specialists (e.g., a cardiologist, a neurologist, a nutritionist, and a general practitioner) rather than choosing a single doctor. Each specialist would conduct their analysis from their specialized field, and then they would all discuss their findings to provide the most accurate diagnosis and treatment plan.

In the same way, Feedzai TrustScore aggregates the fraud knowledge from across the Feedzai community using a federated learning framework². Each expert model is developed to become a “specialist” in a specific geography and use case (e.g., banking, payment processing, or anti-money laundering). Then, to deploy the solution, a mixture of experts (the “panel of specialists”) is assembled by combining a set of relevant pre-trained models, which is immediately available to start making predictions.

One important remark is that, throughout the entire process, data never leaves the client’s secure environment. Only a high-level encoding of the fraud patterns, represented in the form of machine learning models, is shared across institutions. This ensures full regulatory compliance and protects our customers’ sensitive data.

What are the benefits?

• Zero-day Solution: Feedzai TrustScore is a ready-to-use fraud detection tool. New clients benefit from pre-learned fraud patterns, eliminating the time needed for data collection, rules creation, or model training.
• Continuous Refreshing: Feedzai TrustScore is a dynamic solution, actively maintained and updated in order to continuously integrate both newly found patterns of fraud and the latest machine learning techniques.
• Improved fraud detection: Feedzai TrustScore significantly outperforms traditional out-of-the-box rule systems by combining the power of AI with the aggregate fraud knowledge of Feedzai’s network.
• Responsible by design: Feedzai TrustScore is developed with responsibility at its core, guided by Feedzai’s TRUST Framework. Besides providing strict privacy guarantees by design, this approach ensures transparency, fairness, and auditability, making it compliant with the most demanding regulatory environments.

Technical Considerations

Building a fraud detection system that depends on the collective intelligence of a large network of financial institutions comes with several technical and operational challenges. We will go through some of them:

Data Standardization

To develop a unified AI solution, applicable to multiple institutions, the format and the meaning of the data must be standardized, such that the patterns that the experts learned can be seamlessly integrated into new financial institutions. This process includes several procedures, for example:

• Schema Alignment: Financial data is usually tabular, with rows as events and columns as information dimensions. We define a standard schema to unify table structure across institutions, allowing each to populate it with available data. The schema supports incomplete tables, so not all columns need to be filled.
• Categorical Consistency: Different institutions may use different encodings to represent the same categorical information, such as “merchant type.” We use mapping and harmonization techniques to ensure the representations of categorical features are consistent across environments.
• Currency Normalization: The difference between normal and abnormal spending behavior depends on the context into which it is inserted. In order to standardize some of these differences, we use currency conversions, cost-of-living adjustments, and percentile-based features.
• Time Zones and Derived Features: Transaction time is a critical signal, and with Feedzai’s global reach, this means combining insights from all across the world simultaneously. As such, we normalize across time zones and engineer derived features (e.g., daytime vs. nighttime spending) that remain meaningful across institutions.

Expert Calibration

In a MoE solution such as Feedzai TrustScore, all experts should effectively contribute to the final risk score. But this is a delicate balance, since each expert is trained independently, without context from the other experts and their environments. We use calibration techniques to ensure that experts yield scores that represent fraud risk homogeneously.

Monitoring and Refreshing

Feedzai TrustScore is monitored and tuned regularly at both the expert level and the MoE aggregation level. This ensures robustness and allows us to detect model drift early. Moreover, individual expert models can be added, removed, or updated whenever we detect performance drops or want to integrate the latest fraud patterns in the Feedzai TrustScore system.

Stable and Interpretable Risk Score

As fraud patterns evolve and expert models are updated, the risk score must remain consistent and reliable over time. To ensure this, we apply techniques that keep the score distribution stable, even as the underlying system changes. This facilitates the integration with downstream systems, and ensures that each score consistently reflects the same level of transaction risk, making it more interpretable.

Personalization and Augmentation

Feedzai TrustScore can be fine-tuned and optimized for individual financial institutions as soon as enough of their own data has been collected, which further improves its predictive performance. Furthermore, this risk score can be seamlessly combined with other solutions, such as rules or custom AI models, to augment their performance. This is an example of how Feedzai TrustScore can provide value not only when activating a new customer, but in a long-term setting.

Conclusions

In this blog post, we introduced Feedzai TrustScore, an AI-powered fraud risk score designed to detect fraud as a zero-day solution, without relying on historical data or complex model setups.

Feedzai TrustScore combines insights from a global community of financial institutions using a Mixture of Experts architecture and federated learning principles. This enables the detection of emerging fraud patterns that may be invisible to any single institution, while maintaining strict data privacy and compliance standards. Real-world results show a boost in fraud detection, a reduction in false alerts, and a faster time to market, proving that collective intelligence can drive real business value.

Feedzai TrustScore is not just an incremental improvement. It represents a completely different approach to tackling the problem of fraud detection, allowing our customers to stay ahead of the criminals, to better protect their clients.

If you would like to know more about Feedzai TrustScore and other Feedzai IQ™ initiatives, feel free to reach out to the Feedzai Product team: product@feedzai.com.

If you are interested in exciting AI projects to combat financial crime, get in touch with the Feedzai Research team: research@feedzai.com.

[1] Mixture of Experts (MoE) is a machine learning approach that divides an artificial intelligence (AI) model into separate sub-models (or “experts”), whose outputs are then combined with some gating/aggregation method [source]. Feedzai TrustScore’s gating and aggregation mechanisms are confidential.

[2] Federated Learning is a machine learning paradigm where multiple “data silos” collaborate to build an ML model, without sharing their private data [source].

Feedzai TrustScore: Enabling Network Intelligence to Fight Financial Crime was originally published in Feedzai Techblog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Data scientists use different Jupyter notebooks every day — ranging from disposable ones for quick tasks to those shareable with clients. Over time, more and more notebooks accumulate, making it increasingly difficult to reuse them in whole or in part. To mitigate this problem and make the most relevant pieces of code quickly accessible to every data scientist, we developed JupyterLab Snippets at Feedzai — our take on leveraging code snippets directly on JupyterLab.

JupyterLab is a computational notebook platform that enables us to carry on data science work (and beyond) via notebooks. These notebooks, where code, text, and images come together, allow us to complete all kinds of tasks, keeping each input close to each output. At Feedzai, data scientists have access to different JupyterLab environments packed with custom notebooks and Python packages. Here they go from analyzing data to training models, from preparing reports to debugging the system — a “lab of all trades”, we could say.

Given the importance of JupyterLab and notebooks in the daily work of our data scientists, we started a research project that culminated in JupyterLab Snippets. First, we collected statistics from internal notebook repositories across teams and conducted user interviews with junior and senior data scientists. We needed to know more about how data scientists actually use JupyterLab and notebooks, and what their ideas are for a better platform.

After compiling the insights, several aspects became clear:

• JupyterLab and notebooks are heavily used for all sorts of data science and ad-hoc tasks (typically one per notebook). There is no single type of task (e.g., exploratory data analysis) that is more commonly addressed with notebooks than others.
• While file structures may look similar at first glance (each environment has at least a model training notebook, for example), data scientists have different and personal workflows for coding notebooks.
• Duplicating past notebooks available in the environment or getting them from repositories is a very common practice.
• Notebooks composed of code snippets is also an identified practice. These notebooks are not intended to be run, and contain code and text for future reference (imagine a notepad in notebook format). This case and the previous one imply removal of unnecessary parts and parameterization.
• Data scientists regularly communicate within teams and individually. Sharing notebooks/snippets is a common practice.
• No significant issues were identified with the JupyterLab/notebook interface.

It is true that data scientists have their own ways of finding whatever they need for their next notebook, and AI coding assistants are proliferating. Even so, would it be beneficial to improve the experience of reusing code in JupyterLab? After analyzing all the insights, we believe so. We believe in an interface that allows every data scientist to easily manage and use “their snippets” now and in one year, while also facilitating their sharing with other data scientists. JupyterLab Snippets aims to improve the developer experience, focusing on productivity and satisfaction, while having a low maintenance cost. Here is JupyterLab Snippets in its essence.

Introducing JupyterLab Snippets

JupyterLab Snippets is a JupyterLab extension for data scientists to create, manage, and use code snippets directly on JupyterLab, facilitating code reuse in their notebooks. To be more precise, the interface is a JupyterLab extension and the backend, for managing the snippet data, is a Jupyter Server one. Both communicate via a REST API.

The interface, a part of JupyterLab like notebooks and the like, is divided into three main components:

• Snippets Sidebar: The central hub for JupyterLab Snippets, available as a new tab in the right sidebar of JupyterLab. It allows the data scientist to manage and utilize the code snippets. Each snippet is available on a Snippet Card.
• Snippet Editor: The form-like interface for creating new snippets and editing existing ones. When opened, it is available as a tab in the main work area of JupyterLab.
• Shortcuts: Options for creating snippets from notebook cells. These options are available from the context menu after right-clicking on a cell, and the option to start a snippet from a cell is also available from the cell toolbar.

In the Snippets Sidebar, in addition to the Personal collection, data scientists will find a set of pre-made snippets: the Feedzai collection. They can switch between both (or view them all at once) by selecting the desired collection in the toolbar just above the list of available snippets. The Feedzai collection is a set of snippets for common actions performed in notebooks, prepared with the help of our data scientists. This collection is specially designed for newcomers who can take advantage of JupyterLab Snippets from day one. Additionally, it is available in a dedicated repository so that anyone can easily contribute to this collection and enrich it for everyone.

From the Snippets Sidebar, data scientists can export all of their snippets in JSON format (each snippet is exportable individually as well). This file makes it easy to share snippets among data scientists, as well as maintain them in repositories for reference. Each data scientist can then import one of these files into their environment, from the dropdown menu shown in the first screenshot, and have access to new snippets.

Usage

JupyterLab Snippets is designed to be a flexible tool that data scientists can integrate into their workflows in different ways and use as much or as little as they need. There is more than one way to create snippets, and each data scientist may have as few as five or as many as 50 snippets (or even more) at their disposal. Let’s look at a possible simple workflow:

1. After launching JupyterLab, the data scientist starts by opening the notebook they are working on.
2. Instead of copying and pasting code from a given source to the notebook directly, they open the Snippets Sidebar on the right side of JupyterLab and then the Snippet Editor to create a new snippet.
3. Since the data scientist can imagine reusing this piece of code in the future, they create a new snippet with it, including a name, a brief description, and two tags that describe it appropriately.
4. Now they insert the new snippet into the notebook and continue working from there.
5. Finishing the current notebook, the data scientist clears all the output. Then, when they review the notebook and check that everything is okay, they notice a cell that would also make a useful snippet for the future.
6. Since not all the cell content is relevant for a reusable snippet, the data scientist selects only what they want and starts a new snippet from there via the cell context menu.
7. Similar to the first snippet, they assign a name and a tag.
8. After a while, in a new notebook, the data scientist opens the Snippets Sidebar and quickly inserts both previously created snippets, as they will be useful in this new notebook as well.

What’s Next

JupyterLab Snippets is now available for data scientists to use across Feedzai. Our current focus is on helping data scientists incorporate JupyterLab Snippets into their daily workflow, addressing any issues that arise, and collecting feedback for future improvements.

If you have any questions or feedback, let us know in the comments section.

Beatriz Feliciano, Diogo Duarte, Ferran Pla Fernández, Iker Perez Lopez, João Bernardo Narciso, Rita Costa, and Sanjay Salomon: thank you so much for your thoughtful feedback that helped me shape this blog post!

Here and Now: Reusing Code at Feedzai with JupyterLab Snippets was originally published in Feedzai Techblog on Medium, where people are continuing the conversation by highlighting and responding to this story.

However, the impacts of this issue stretch beyond someone’s finances. It can also impact a victim’s life in many dimensions. Detecting and quickly acting upon suspicious transactions is essential to tackle this problem.

Finding Fraud Through Data Tables

To review the data of alerted transactions, analysts look at information in tabular format (similar to what is presented in Figure 1), scrolling through it to assess past activity patterns of the alerted person and comparing those with the alerted event. “How much money was spent on average on past transactions?” or “Is that significantly different from the amount on the current alert?” are some questions they might try to answer during their review.

The issue with this approach is that finding groups of patterns and anomalies in tabular data can be overwhelming since it requires an increased cognitive load from analysts to interpret the data effectively. This becomes even more complex since these professionals must review and classify the alerted transaction in a short time — between 1 and 5 minutes.

Revamping the analysis

To solve this problem, we present a tool that combines charts and text to guide the analysis of financial transactions.

As presented in Figure 2, the tool (populated with synthetic data) is divided into three regions that provide different levels of information detail — from the most high-level to the most detailed. The goal is that the analyst can scan the charts and prioritize their review towards specific areas of the alert.

Identifying Investigation Areas

To assess suspicious areas of the alert and gain a general understanding of the data, analysts first look at the Knowledge Area Console (A), where they see all the areas that compose an alert — which are dynamic and use case dependent. For the considered use case, the analyst is presented with the alerted person demographics (A.1), transaction location (A.2), alerted person’s incoming and outgoing transactions (A.3), card used (A.4), counterpart (A.5), and alerted person’s activity (A.6). They are also pointed to the areas that have suspicious information and thus that might require more attention (in this case, A.5, the counterpart).

To gather more details about a specific alert area, analysts can click on its corresponding icon. This selection will be reflected in the other regions of the tool (B and C, as presented in Figure 3), which will then present insights about the data of the area. In the example illustrated in Figure 2, the analyst is interested in knowing more details about the alerted person’s balance between incoming and outgoing transactions (A.3) and thus selects that area for further investigation.

Narrowing the Investigation Focus

After selecting an area, analysts can understand more details about it in the Knowledge Area Text Summary (B). This is an LLM-generated summary of the most relevant insights of the data where relevant and suspicious information is pointed, giving analysts a broad understanding of the selection data. Through the summary of area A.3, analysts can quickly assess how much money the alerted person sent and received in the past three months and how many counterparts were involved in those transactions.

Digging Deeper into the Data

Upon reading the text summary, analysts might still feel like they need more information to understand the data. For that, they can look at the Knowledge Area Graphical Representation (C). This region is composed of one or more graphs tailored to the data and analysis needs of the selection. Here, all the data points of the selected area are represented, allowing analysts to perform an exhaustive evaluation of the data and to confirm the insights that were given in the other regions of the tool.

By looking at the graphical representations designed for area A.3, the analyst is able to gather insights about the entities the alerted person sent to or received money from. They can also see how those transactions occurred through time. As confirmed in the summary, they verify that no data regarding this area seems to be suspicious or out of the ordinary.

User feedback on this tool indicates that it could transform the way analysts perform their reviews. They mentioned that it improves their efficiency and “enables the most basic review to be almost automatic, allowing … time and effort to [be invested only in] more advanced cases.” Analysts also mentioned that the tool makes it easier to “get an overview of the behaviors of the alerted person” and thus “to identify what is wrong or what is not common to the person’s activity,” facilitating the identification of risky analysis areas and information.

For more details about this work, refer to our paper and video.

If you have any questions or feedback, feel free to reach out to data-viz@feedzai.com.

“Show Me What’s Wrong!”: Enhancing Fraud Detection Analysis by Combining Charts and Text was originally published in Feedzai Techblog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Banks are required to monitor for money laundering activities and issue alerts when suspicious transactions are detected. Typically, monitoring is performed by rules-based legacy systems. A better approach would be to use Machine Learning models, but these usually require labeled data to train, which are mostly unavailable in this use case.

To tackle this problem, we employ advanced Generative AI (GenAI) techniques to generate synthetic data that simulates realistic money laundering activities. These synthetic examples help us identify vulnerabilities and strengthen the defense mechanisms used by banks and other financial institutions

In this blog post, we will explore the method developed by Feedzai, which leverages GenAI to tackle the challenges of detecting and preventing money laundering in today’s digital landscape. This blog post is the first of a series dedicated to the work done on GenAI by Feedzai Research in the last few years.

Problem Statement

First, let’s briefly introduce the concepts behind money laundering and the difficulties that banks face when trying to prevent it.

Money laundering is the process of concealing the origins of illegally obtained funds. Criminals cannot directly spend “dirty” money without risking exposure of their illegal activities. Therefore, they want to disguise the origins of funds before using them.

Money laundering typically involves three stages:

1. Placement: the money is introduced into the financial system, often in small amounts spread across various banks.
2. Layering: the money launderer moves the funds through a series of transactions, typically across multiple financial institutions and jurisdictions, to obscure the money’s origin.
3. Integration: the “cleaned” money is reintroduced into the legitimate economy, where it can be safely used by criminals.

Our work focuses on the layering stage.

Detecting money laundering is particularly challenging because each bank has a limited view of the entire financial system (see figure below). Banks can only monitor transactions in which at least one of the accounts involved is an internal account (green edges). Money launderers exploit this limitation by moving funds between different banks, ensuring each institution has minimal information. As such, the transactions most indicative of the layering process often occur between accounts of different institutions (bold green edges).

We can represent these in-and-out transactions from a single bank’s perspective as a directed tripartite graph. In this graph, external source accounts transfer money to internal middle accounts, which then pass the funds to external destination accounts, creating a flow of money through the bank.

Banks are required to monitor for money laundering activities and issue alerts when suspicious transactions are detected. If they don’t comply, they can receive substantial fines from regulatory agencies.

Typically, monitoring is done by encoding the domain knowledge of experts in the form of rules that capture known patterns of money laundering. These rules often focus on individual accounts and trigger when certain thresholds are exceeded within a specific time frame, such as “total amount sent in a month” or “number of transactions in a day”, or based on location information. However, this approach often results in low detection rates and a high number of false positives.

Machine Learning models offer a different option, but these usually require labeled data to train, which is usually unavailable, incomplete, or very expensive.

The GANfather

To overcome this limitation, we leveraged GenAI to develop “The GANfather”, a method to generate examples of illicit activity and train effective detection systems without the need for labeled data. Additionally, if an existing detection system is already in place, our method can identify its weaknesses while simultaneously training a complementary detection system to protect against such attacks.

We build upon a Generative Adversarial Network (GAN) by incorporating an optimisation objective and, optionally, a pre-existing detection system. The generator creates synthetic examples of suspicious financial activity. These examples are then used to train the discriminator to identify patterns of money laundering, even without labeled datasets.

Data representation

To effectively generate and detect suspicious money flows, we first need to represent the transactional data in a structured format.

Transactional data is usually represented as a table where each row corresponds to a transaction with several features. However, for the purpose of detecting money flows, we conceptualize them as a directed tripartite graph. This graph can be represented as a 3D tensor: the first dimension corresponds to internal accounts, the second to external accounts, and the third to the time window of the transactions, discretized into time units. Each cell in this tensor contains the sum of amounts transferred between the corresponding pair of accounts, during the corresponding time window.

Due to the nature of transactions, most cells in the tensor will be empty, which is not very efficient from a computational point of view. However, this representation offers a fixed-size input and output for our models, allowing us to use dense or convolutional layers in our neural networks, avoiding the complexity of recurrent layers.

Generator

With the data representation established, the next step is to generate synthetic transactional data.

This process is similar to the original GAN framework, in which a deep neural network receives a random noise vector as input and produces data in the specified format. However, unlike traditional GANs, our generator is guided by feedback from three distinct components, as shown in the figure below:

• Discriminator: makes the generated data more realistic, closer to real data.
• Optimisation objective: encourages the generator to produce patterns that mimic money laundering behavior.
• Alert system (optional): helps the generator avoid creating patterns that would trigger an alert.

We will now describe each of these components in more detail.

Optimisation objective

Using the generator described above, we can create data in the intended format. But how do we teach the generator to create examples that mimic money flow patterns? To achieve this, we fall back on domain knowledge. We know that money laundering flows are typically characterized by large and similar amounts of money going in and out of the internal accounts.

To describe this behavior, we define the objective function as the geometric mean of the total amount of incoming and outgoing money per generated account. This simple formula naturally encourages the generator to increase the volumes of money being transferred, while maintaining a balance between incoming and outgoing totals.

Discriminator

A potential issue with the aforementioned objective is that it is unbounded, allowing the generator to increase amounts indefinitely, resulting in unrealistic data. To prevent this, we incorporate the feedback from the discriminator.

The discriminator is another deep neural network, similar to the generator, that evaluates examples and produces a score indicating the likelihood of each being real or synthetic. This component not only refines the training of the generator, making the synthetic data more realistic, but it is also useful itself. Since the real data primarily consists of legitimate activity and the synthetic data mimics money laundering behavior, the discriminator can be used as a detection system for illicit activity.

Alert System

Financial institutions often have systems in place to flag some suspicious patterns of money laundering. Usually this alert system is based on rules, like “every transaction above ten thousand dollars needs to be reviewed”.

If we pass the feedback of the alert system to the generator, it can learn to create examples that bypass the existing system. This approach helps identify vulnerabilities in the current systems and generates examples of money-flow behaviors that go undetected. Furthermore, since the discriminator model learns to detect these synthetic examples, it can serve as a complement to the existing alert system, improving overall detection.

Complete architecture

To summarize, the GANfather architecture consists of:

• a generator that produces synthetic examples mimicking money laundering activity;
• a money flow objective that guides the generator to create realistic money flows;
• a discriminator that distinguishes between real and synthetic data, forming the basis of a new detection system;
• (optionally) an alert system that ensures the generated examples bypass existing detection rules, helping to identify potential gaps in current systems

Experiments and Results

Dataset

We use a real-world dataset of financial transactions, containing approximately 200,000 transactions between 100,000 unique accounts over 10 months. Some accounts are labeled as suspicious of money laundering. We built a real test set of 5,000 accounts, 184 of which are labeled positive.

The dataset includes a limited set of features: source account, target account, transferred amount, and timestamp of the transaction.

Comparison between real and generated data

First, we compare the distributions of real and generated data. Because we include the money flow objective in the loss of the generator, we expect a larger volume of money being transferred in the synthetic examples. The following figure shows the distributions of different volume-related metrics.

Looking at the distribution of the total amount of money flowing through the internal accounts (left panel), we see that generated accounts move much larger volumes of money than real ones. However, the center panel shows that the generator is approximating the range of the real distribution of amounts per transaction quite well. This is probably to avoid triggering rules that capture large amount transactions. Instead, the generated accounts are able to transfer more money by increasing the number of transactions significantly, when compared to the real data (right panel).

Detection performance

We generate a dataset of synthetic transactions using different pre-trained generators to increase variety. Then, we train a new discriminator to distinguish between real (unlabeled) data and synthetic examples of suspicious activity. Finally, we evaluate this discriminator using the test set with real transactions and real labels.

We compare the performance of a set of standard anti-money laundering rules against this discriminator. For a fair comparison, we adjust the model’s threshold to match the alert rate of the rules, ensuring both systems predict the same number of positive cases. We see that the model outperforms the rules in detecting suspicious transactions, even though it was trained using only generated data as positive examples.

Next, we simulate a combined detection system that triggers an alert if either the rules or the model detects suspicious activity. The results show minimal overlap between the alerts and true positives identified by the two methods, suggesting that the model captures different patterns of suspicious behavior compared to the rules. This is expected, given that the generator was trained specifically to create examples that evade the rule-based system, leading the discriminator to identify distinct patterns.

In conclusion, the discriminator effectively complements the rule-based system, resulting in a combined approach that significantly improves the detection of money laundering activities.

Conclusion

In this blog post, we introduced a method leveraging GenAI to generate synthetic data that simulates realistic money laundering activities. This data can be used to train Machine Learning models to detect money laundering without requiring labeled data.

Our approach involves training a generator to produce examples that mimic money laundering behavior, guided by an optimization function integrated into its loss. This synthetic data is then used to train a discriminator, which learns to distinguish between real (mostly legitimate) behavior and synthetic suspicious behavior.

Our results demonstrate that, when tested on a real test set with real labels, the discriminator outperforms traditional rule-based systems in predictive accuracy and can also serve as an effective complement to them. For a more detailed explanation about our method or our experiments, please refer to the full paper.

The GANfather: Using Malicious GenAI Agents to Combat Money Laundering was originally published in Feedzai Techblog on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this blog post we will visit Aequitas Flow, an Open-Source framework designed to run complete and standardized experiments of Fair ML algorithms. We encourage you to try Aequitas Flow with the Google Colab Notebooks, which are available in the project’s GitHub repository.

This blog post is based on the paper by Sérgio Jesus, Pedro Saleiro, Inês Silva, Beatriz M. Jorge, Rita P. Ribeiro, João Gama, Pedro Bizarro, and Rayid Ghani.

Table of Contents:

1. What is Aequitas Flow?
- 1.1. For Practitioners selecting a model
- 1.2. For Researchers running a benchmark
2. Install Aequitas Flow
3. The components of Aequitas Flow
- 3.1. Experiment
- 3.2. Optimizer
- 3.3. Datasets
- 3.4. Methods
- 3.5. Audit
4. Conclusion

What is Aequitas Flow?

Aequitas Flow is the codename for the latest version of Aequitas, a well-established package for fairness auditing in the ML community. This version extends the package to include experimentation with Fair ML algorithms.

Aequitas started as a software to diagnose and alert for disparities in ML models’ decisions depending on sensitive attributes, such as race, gender, or age. To achieve this, the package runs a Bias Audit, in which it calculates several metrics across all data groups, determined by the sensitive attributes, and compares them to identify any gap in performance.

While some other packages already implement Fair ML methods, they also introduce an overhead of technical knowledge to configure, evaluate, and deploy these models. Because of this, we extended Aequitas to enable users to conduct experiments using a wide variety of fair ML methods from the literature in an intuitive user experience. Aequitas Flow was built on the principles of extensibility and reproducibility: it allows users to incorporate their own datasets and methods in the framework using familiar interfaces of sci-kit-learn and pandas. It ensures their work can be replicated by performing an extensive collection of configurations and information.

The framework is designed for two different experiences, depending on the user’s end goal. It provides the means for:

• Practitioners — to select a model for a given application or dataset;
• Researchers — to run a benchmark, or check if a given method is significantly better than others.

For Practitioners selecting a model

A Practitioner can use Aequitas Flow to select a model, for example, to go to a production environment. To help in this task, Aequitas Flow creates an interactive plot to compare models on a given dataset. This provides an intuitive way to view the achieved performance and fairness of the trained models.

This plot shows all the models of an experiment drawn in a two-axis grid, where the X-axis has the performance metric (e.g., it can be Accuracy, TPR, Precision, etc.) and the Y-axis the fairness metric (e.g., Demographic Parity, Equal Opportunity, etc., more about fairness metrics here). Generally, we aim to maximize both these metrics, and as such, the best models are in the top right corner.

The plot highlights the model with the best combination of the selected performance and fairness metrics, being marked as “Recommended” (with a star). This best combination is, by default, given by the model with the highest combination of performance and fairness. The weight of each metric can be adjusted to focus on more performing or fairer models, with an alpha parameter in the plotting method.

Additionally, the Pareto frontier is highlighted in blue. This frontier is composed of the models that present a dominant tradeoff (i.e., no model can obtain better performance without losing fairness and vice versa). The plot lets the user interactively click on any models and see how they compare to the “Recommended” model. The comparison includes a comprehensive list of metrics of fairness and performance, as well as the hyperparameters of the model. In the provided example, we compare the “Recommended” model with the one that achieved the best predictive performance (+1.9 p.p. in Accuracy). We notice, however, that it has a much lower value of fairness (-36.9 p.p. in Equal Opportunity).

For Researchers running a benchmark

A common objective among researchers is to run a benchmark, i.e., compare a new method with other methods established in the literature for a wide array of tasks or datasets. Using Aequitas Flow, it is possible to run the necessary experiments and analyze the results quickly and straightforwardly.

This plot has each method (represented by a different line) drawn within all the possible tradeoffs between fairness and performance. The X-axis determines this tradeoff, and is what we call the alpha parameter. To the left of the X-axis, the value plotted in the Y-axis is more influenced by the fairness metric (in this case, Equal Opportunity), while to the right, it is more influenced by the performance metric (Accuracy). Methods that are above the others in certain regions are considered dominant. For example, FairGBM (in orange) is dominant in the region of fairer methods.

The shaded regions between each method are estimated through a bootstrap of controllable size. This emulates the expected result and confidence interval for a certain number of trained models for each method. This allows researchers to identify both the methods that are expected to obtain the best results (either in fairness, performance, or a combination of both) and methods that are more or less stable in training.

The Aequitas Flow framework provides the necessary tools to easily conduct and visualize these experiments while allowing for flexibility in the chosen metrics, datasets, and sensitive attributes being analyzed.

Install Aequitas Flow

Whether you are a practitioner, a researcher, or are just interested in the package, you can easily try it out for yourself! We provide resources to enable anyone to quickly start using the Aequitas Flow framework.

Aequitas Flow is the latest version of Aequitas, and therefore, the first step is as simple as installing the current version of Aequitas via pip, using:

To facilitate understanding how to configure an experiment and obtain results using Aequitas Flow, we have curated a series of example notebooks, which you are free to adapt as you follow along.

Across these notebooks, we explain the multiple components of the package and provide examples on running different pipelines, from processing raw public data to training Fair ML models and generating the resulting plots.

The available Google Colab Notebooks are the following:

• Audit a Model’s Predictions — Check how to do an in-depth bias audit with the COMPAS example notebook (or use your own data);
• Correct a Model’s Predictions — Create a dataframe to audit a specific model and correct the predictions with group-specific thresholds in the Model correction notebook;
• Train a Model with Fairness considerations — Experiment with your own dataset or methods and check the results of a Fair ML experiment;
• Add your method to Aequitas Flow — Learn how to add your own method to the Aequitas Flow toolkit.

The components of Aequitas Flow

Now that you know what Aequitas Flow is and how to use it, we will explore its package contents in more detail.

Aequitas Flow is designed to offer an intuitive user experience while still being flexible enough for more experienced users to extend its components to meet their unique requirements. We finish this blog post by checking the architecture that makes Aequitas Flow a versatile and empowering tool.

Experiment

The Experiment is the main orchestrator of the workflow within the package.

It processes configurations — either in the form of files or Python dictionaries — specifying the methods, datasets, and optimization parameters to be used in the experimental process. The Experiment then handles the initialization and population of the necessary classes, ensuring they interact deterministically throughout the execution process. When an experiment is completed, the results are readily available to be analyzed.

This component can be instantiated to simplify the experimental process to only require the dataset and can execute an experiment using default settings for methods and optimization. This feature is intentionally designed to streamline initial experiments and reduce configurations.

Optimizer

The Optimizer component manages hyperparameter selection and model evaluation.

Having the hyperparameter search space of the methods and a split dataset, it handles the hyperparameter tuning, evaluating the performance of models, and storing the resulting objects, scores, and predictions. The Optimizer component leverages the Optuna framework for hyperparameter selection and employs the Aequitas package for fairness and performance evaluation of the models.

Datasets

This component has two primary functions:

• loading the data;
• generating splits according to user-defined configurations.

It maintains details on target attributes, sensitive features, and categorical variables, presenting the data in an extension of the pandas dataframe format.

The framework initially encompasses eleven datasets, selected for their use in research, including those from the BankAccountFraud (created by Feedzai) and Folktables collections. The Dataset component allows users to supply their own datasets, supporting both CSV and parquet formats.

Methods

These components are dedicated to data processing and creation and adjustment of predictions for validation and test sets.

Aequitas Flow provides interfaces for three types of Fair ML methods:

• Pre-processing methods, which modify the input data;
• In-processing methods, which aim to enforce fairness during model training;
• Post-processing methods, which adjust the resulting scores or decisions.

Additionally, classical ML methods are included in the “base estimators” category function similarly to in-processing methods. These methods adhere to standardized interfaces to ensure seamless operation and facilitate function calls within the experiment class.

Currently, 15 methods are supported, including pre-processing techniques such as undersampling and oversampling, label massaging and suppression, and label flipping. Regarding in-processing techniques, the package includes FairGBM, a gradient boosting machine algorithm with fairness constraints developed by Feedzai, and the methods of Exponentiated Gradient and Grid Search for transforming fairness constraints into cost-sensitive classification. For post-processing, the framework includes different implementations of group-wise thresholding.

Audit

The Audit component simplifies the process of calculating and analyzing any disparities in performance between different groups. The Aequitas toolkit offers a suite of confusion matrix-based metrics for auditing the existence of bias.

Users can specify a group as a reference for the disparity comparison and select the appropriate fairness metric for their analysis. Aequitas Flow then leverages the Audit class to create a dataframe of metrics and disparities for each group in the dataset, allowing for a comprehensive analysis of the predictions that a method has produced for a given dataset.

Aequitas Flow further provides tools for visualizing the results of the Bias Audit, as shown below in Figures 5 and 6.

In Figures 5 and 6, we are able to view the results of the bias audit. Figure 5 presents a summary plot of the bias audit. It identifies the groups that have significant differences from the metrics of the reference groups and highlights them as red. We can get more information by hovering over these groups, such as the group’s name, size, and metric value.

Figure 6 shows the relative differences in metrics between groups. The examples illustrate two error rates: FPR, which is the percentage of negative labels incorrectly labeled as positive, and FDR, which is the percentage of positive labeled instances which are negative. The user can select the metrics of these plots.

Conclusion

As more people navigate the complex landscape of fairness in machine learning, Aequitas Flow stands as an effort to drive ethical open-source innovation. We invite you to explore Aequitas Flow and contribute to its development by visiting our GitHub repository. To contribute to the package’s development, feel free to open an issue in the repository or create a merge request regarding one of the open issues.

Aequitas Flow step-by-step: a Fair ML optimization framework was originally published in Feedzai Techblog on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the world of financial services, the bank or financial institution’s relationship with the customer relies on digital trust, which is anchored in two fundamental principles. First, it must ensure the person engaging through digital banking channels is genuinely the individual they claim to be. Second, it must confirm that this person is authorized to complete the intended financial transaction.

Addressing these crucial requirements is the core mission of Feedzai’s Digital Trust solution. The solution collects and analyzes comprehensive user behavioral data, scrutinizes device information for potential threats, such as malware attacks, and evaluates contextual factors like network, operating system, or browser information to gain a complete understanding of the user’s environment. However, the high volume and heterogeneous nature of the collected data, among other challenges, makes detecting potential fraudulent sessions with high accuracy a formidable endeavor.

In this blog post we explore how a new machine learning (ML) model that performs a continuous evaluation of collected data and leverages insights from previous frauds to vastly improve Digital Trust’s fraud prevention capabilities. We will start with an introduction to technical details behind our Digital Trust solution, going into the challenges of fraud detection and prevention. We continue by explaining how we can apply ML to boost fraud detection and how we deployed the new Fraud model to dozens of Feedzai customers.

Table of Contents

1. Digital Trust data collection
- 1.1 The user journey
- 1.2 Behavioral biometrics data
- 1.3 User’s behavior
- 1.4 Device and network data
2. Challenges to detect fraud in Digital Trust
3. Machine Learning for Digital Trust
- 3.1 The holistic approach
- 3.2 New Fraud Model
4. Deploying the model
5. In summary

Digital Trust data collection

To better identify the challenges that are typically faced when designing a fraud prevention system based on Digital Trust, first we need to understand the user’s journey and the data that the system is able to collect.

The user journey

The user’s journey commences the moment they register on the bank’s website or application. During this registration phase, the user enters their data, triggering the initiation of Digital Trust’s protective measures, even if the user isn’t fully registered yet.

At this instant, the Digital Trust system can already:

• Detect whether the device used is associated with previous frauds;
• Identify if the network originates from a location with elevated fraud rates;
• Notice any deviations in the user’s behavior, such as pasting their name instead of typing it.

Based on these illustrative examples, we can promptly inform the financial institution and issue an alert regarding the creation of a new account if malicious intent is suspected.

Likewise, when a user accesses either the website or the mobile application, they undergo a login procedure. During this phase, we can analyze the user’s typing patterns and how they compare to previous sessions. We can also determine if the device used by the current user has been shared by previous users. As the user progresses through various activities, such as reviewing past transfers and initiating new transactions, Digital Trust continuously monitors their actions, proactively identifying and reporting any suspicious behavior.

To perform the analyses and detections, the Digital Trust system collects different types of data.

Behavioral biometrics data

Regarding biometric data, Digital Trust can handle various types of data depending on the device. For desktop-like devices, the system collects biometric events, including keystrokes, which involve monitoring the duration of key presses, the specific type of key (e.g., a number, letter, or special character), and the typing speed. The system also tracks mouse-related events, encompassing mouse movements and mouse clicks. These biometric events allow the Digital Trust system to verify user identity by comparing current patterns with previous ones, detect the use of Remote Access Trojans (RATs), identify bot usage or behaviors that are not humanly possible, among other unusual behaviors.

In the case of mobile-like devices, the interaction differs, and consequently, so does the biometric data collected. On these devices, primary interaction occurs on the device’s screen. The Digital Trust system captures touch events, recording position and pressure strength, as well as typing on the virtual keyboard and screen gestures like strokes or pinch movements. Additionally, the mobile devices usually have other sensors, such as orientation of the screen or gyroscope movements, providing more usage information. Once more, this serves as valuable data for confirming user identity and behavior verification.

User’s behavior

More information is derived from user operations on the bank’s digital platform. Specific sets of views within the platform may be linked to critical actions, such as initiating a transaction or altering the contact information needed for two-factor authentication.

Conversely, actions like adding a new frequent beneficiary or adjusting particular settings may signify an atypical user journey. These signals must not only be reported to the bank or financial institution analysts but also incorporated as features within the Digital Trust detection systems. This information is harnessed by Digital Trust to proactively mitigate and prevent malicious attacks.

Device and network data

Another source of information involves data derived from the user’s device and connection. On the one hand, in the case of accessing the bank’s website, Digital Trust gathers the information related to the browser and its configuration. On the other hand, in the case of using the bank or financial institution’s application, the Digital Trust integration extends this data collection with software details like the operating system version and default language, as well as physical data such as battery availability or the current telephone line status (e.g., if the user is making a call simultaneously).

Regarding network information, we can deduce specific details from the user’s connection, such as the current Internet Service Provider (ISP), network type, or the user’s approximate location. All this information empowers our detection mechanisms to identify both unusual behaviors or configurations and establish typical fraudulent patterns.

In conclusion, Digital Trust seamlessly integrates with financial institutions’ digital platforms, continuously monitoring user behavior and digital environments upon login to detect anomalies and suspicious activities. It gathers diverse data, including biometric data from keystrokes and mouse movements, and leverages this information to verify user identity and identify unusual behavior. User operations on the platform, such as critical actions or atypical user journeys, provide additional signals for the system to proactively prevent malicious attacks. Data derived from the user’s device and connection further aids in recognizing unusual behavior or configurations and establishing typical fraudulent patterns.

Challenges to detect fraud in Digital Trust

Several challenges related to the data and other details exist when faced with the task of developing a fraud detection system in Digital Trust.

First and foremost, minimizing potential user friction is paramount. On the device side, information collection should not impact the user experience. Simultaneously, device resources such as CPU time, bandwidth, or battery usage should be minimally affected. On the detection side, non-fraudulent users should operate without impediment, therefore keeping false positives to a minimum, while detecting as many fraudulent cases as possible.

Another significant challenge is the volume and diversity of information. As explored before, data sources encompass static user information (e.g., the current device), dynamic information (e.g., network connectivity or available device battery), biometric data (e.g., keystrokes, mouse movements, or mobile gestures), and behavioral data (e.g., time spent on each view and the sequence of user actions).

This heterogeneous nature of the data, coupled with varying data scales (for example, a user may have a single device but generate thousands of mouse events), creates a complex scenario. This is where data feature engineering assumes a pivotal role. The primary objectives are twofold: maximize detection capabilities while minimizing processing, networking, and user interference costs.

Another challenge is the requirement of continuous evaluation. When dealing with transactional fraud, the precise moment for making a prediction is clear: it must occur when the user initiates the payment, at which point the available information is leveraged to produce a prediction. However, Digital Trust is designed to protect both the user and the financial institution throughout the entirety of the user’s session. This necessitates the evaluation of the session at each stage of the user’s journey, striking a balance between alerting as early as possible to preempt potential malicious actions and the risk of alerting with incomplete session information.

Finally, there is the issue of class imbalance. Our detection system must deal with millions of instances in the legitimate class, as opposed to just hundreds or a few thousands of attacks. This places substantial pressure on the detection models: both during the inference phase and during the training period. To address this issue, our Data Scientists apply different advanced mitigation techniques.

Machine Learning for Digital Trust

The holistic approach

As we’ve discussed in previous sections, the identification of fraudulent and high-risk activities poses a formidable challenge. The volume of data, coupled with pronounced class imbalances, with varying time resolutions and data modalities, requires employing advanced techniques.

It’s clear that there is no one-size-fits-all solution to these complex issues. The strength of the Digital Trust solution lies in its holistic combination of diverse feature sets, combined to enhance detection efficacy. As an example, when detecting Remote Access Trojans, the system combines behavioral biometric data alongside the ability to identify the installation of malicious software. The combination of these features ensures a comprehensive security framework that adapts to the specific detection needs.

Traditionally, the solutions in this space are focused only on very basic and simple rules for each of the detection signals. The problem of this approach, even if it initially offers simple explainability, is its limited capacity. The solution needs to be deployed on different geographies with their own particularities, it has to cover multiple use cases, and it has to deal with the evolution of the fraud. All of these issues create the need for more complex rules. At that point, any benefit of the rule system starts to crumble: rules become too hard to maintain, too complicated to understand, and even its computational performance may be affected.

In our case, Digital Trust leverages a wide spectrum of techniques: from expert defined rules, basic yet effective heuristics, to state-of-the-art ML models. The rules encapsulate the expert knowledge of fraud detection; heuristics allow simple and agile solutions for simple cases; and ML models are the key for the detection of more complex and data-intensive scenarios. This multifaceted approach enables us to address the complexity of the threat landscape.

Upon the completion of individual detections, this information has to be indicated in the risk associated with the session. To facilitate this, the Digital Trust system offers the capability to formulate a customized risk strategy that aligns with the specific needs and preferences of each institution. Banks and financial institutions can establish their own ruleset, building upon the default rule set provided by Digital Trust experts. This dynamic adaptability ensures that the solution remains agile in addressing evolving threats and regulatory requirements while maintaining a strong foundation of security.

New Fraud Model

In advancing our custom risk strategy, we at Feedzai have successfully developed and seamlessly integrated a new Fraud ML Model for Digital Trust. This latest model utilizes the comprehensive and heterogeneous array of signals and data from Digital Trust, combined with several advanced techniques developed over the years at Feedzai, to detect and alert potential fraudulent sessions.

The model is able to use combinations of the multiple signals available, which can be more informative than looking at each signal separately. For example, we can process the IP information to detect the origin of the network requests, understanding the spatial location of that user; this information can be combined with other risk indicators, such as Account Take Over (ATO) indicator; in this case, a connection from an unusual country and an ATO indicator is potentially riskier than each of them separately.

Besides the different types of signals leveraged by the model, we use advanced sampling techniques to deal with the high volume and extreme class imbalance, as well as lightweight and efficient machine learning algorithms to ensure both the high detection performance and the low latencies required to make multiple predictions for tens of millions of Digital Trust sessions per day. Our model continuously evaluates the current users’ sessions and, once it detects a potential fraudulent session, it promptly reports this information.

The reporting of this detection is done through a risk indicator called “Potential Fraud Risk”. This indicator may be combined with other custom detections specified by the financial institutions to not only improve the detection efficiency but also to tailor it to their unique business scenarios. The new Fraud Model fuels the Potential Fraud Risk indicator that integrates seamlessly with other existing detection systems.

This new model is another example of Feedzai’s all-encompassing and holistic ML methodology that effectively utilizes heterogeneous Digital Trust data and complements other existing risk indicators. Since this model was deployed, we have seen a significant uplift in fraud detection performance across a diverse set of financial institutions.

Deploying the model

Creating and validating the new Fraud Model is only the first part of Feedzai’s Research work. Deploying it and ensuring that it satisfies the strict latency requirements is, in itself, an often underlooked task. This section describes the major challenges of serving the new Fraud Model and our solutions.

As previously mentioned, the Fraud Model must continuously evaluate every session for each user of our Digital Trust customers. This results in an enormous volume of evaluations. Unlike typical transactional fraud detection models, which assess transactions individually, Feedzai Digital Trust continuously evaluates the potential risk of every session, significantly increasing the number of requests to our models. The new Fraud Model reviews nearly ten thousand requests per second.

Furthermore, the inference process must be swift: if a session appears suspicious, the fraud indicator must be communicated to the bank immediately. This requirement places significant demand on our system to minimize latency and overhead.

To meet these demands for high throughput and low latency, we developed a completely new ML Infrastructure that embraces cloud technology and is capable of managing this load with ease. Our new system is designed to scale horizontally and to serve the model and adjust resource consumption as needed. This new infrastructure enabled the deployment of the new Fraud Model, ensuring the high throughput and low latency required for continuous fraud risk assessment.

Our new ML Infrastructure leverages Kubernetes to orchestrate our services more effectively, ensuring that the Fraud Model is always available, even under varying loads. Kubernetes facilitates seamless scaling, allowing us to dynamically adjust the number of instances based on real-time demand, thus optimizing resource utilization. Moreover, its self-healing features automatically restart failed containers, replace them, and reschedule them to new hosts if needed, ensuring high availability and reliability. This integration not only streamlines deployment processes but also significantly enhances the performance and resilience of our fraud detection services, enabling us to maintain low latency and high throughput, critical for real-time fraud risk assessment.

Alongside Kubernetes, our new ML Infrastructure enables on-demand, independent deployment of models. This modular strategy greatly enhances our system’s adaptability and speeds up the development cycle. When a new model iteration is ready, it can be deployed without affecting the operation of existing models, minimizing potential disruptions.

From the instrumentation point of view, for real-time monitoring and logging, ML Infrastructure integrates with standard open-source tools such as Prometheus for metrics collection and Grafana for data visualization, alongside centralized logging solutions. These tools provide us with granular insights into system performance and behavior, enabling proactive issue resolution and optimization of the experience.

In addition to these monitoring and visualization tools, our infrastructure includes a comprehensive Event Collection system designed to capture and store all interactions within our platform. This system logs every request and response, encompassing both the incoming features and the resulting inferences. The stored data becomes a valuable asset for ongoing model monitoring, offering a view of model performance in real time.

Furthermore, this repository of interaction data is key for future model retraining efforts. By analyzing historical interactions, we can identify patterns, anomalies, and areas for improvement, ensuring that our models evolve in line with changing patterns and emerging threats. This capability not only enhances model accuracy over time but also contributes to a continuous cycle of improvement and adaptation, keeping our systems at the forefront of fraud detection technology.

Together, these technologies form a robust infrastructure that supports our Fraud Model’s high-performance requirements, ensuring that our Digital Trust solution is both efficient and reliable.

In summary

In this blog post, we have explored the intricate landscape of Digital Trust and its role in ensuring secure online financial transactions and how Feedzai’s new Fraud Model further enhances its fraud detection capabilities.

Our solution stands out for its holistic and adaptable approach. It combines various and diverse data sources, including biometric and behavioral data, device and connection information, and user interactions, with advanced machine learning techniques. This multifaceted strategy not only aids in the robust detection but also enhances the overall security of the digital banking experience. Moreover, Digital Trust’s capability to create customized risk strategies allows financial institutions to tailor their security measures, ensuring a dynamic and responsive defense against evolving threats.

Building Trust in a Digital World: The Role of Machine Learning in Behavioral Biometrics was originally published in Feedzai Techblog on Medium, where people are continuing the conversation by highlighting and responding to this story.