Your fraud model catches a suspicious transaction. The compliance officer asks: "Why was this flagged?" If your answer is "the model gave it a score of 0.87," you have a problem. Regulators do not accept scores. They accept reasons. Specific, auditable, documented reasons.
This guide covers which fraud detection tools actually provide explainability that compliance teams can use, and which ones leave you reverse-engineering a black box at 2 AM before an audit.
The question is not whether your model is accurate. The question is whether you can stand in front of a regulator, point to a flagged transaction, and explain exactly why the model flagged it using data the regulator can look up and verify. If you cannot do that today, this guide will show you which tools make it possible and which ones never will.
Why compliance needs explainability (not just accuracy)
A fraud model with 99% accuracy and zero explainability is a liability, not an asset. Regulators across the globe have made it clear: if you cannot explain why a decision was made, you cannot make that decision using AI. This is not a philosophical position. It is codified in law.
regulatory_explainability_requirements
| regulation | what_it_requires | penalty_for_non-compliance |
|---|---|---|
| ECOA (Equal Credit Opportunity Act) | Specific reasons for adverse actions. Must be understandable to the consumer. 'The model flagged it' is not a reason. | Civil penalties, enforcement actions, private lawsuits. CFPB has increased scrutiny of algorithmic decision-making since 2022. |
| FCRA (Fair Credit Reporting Act) | If a fraud flag leads to adverse action (account closure, transaction decline), the consumer must receive specific reasons. | Statutory damages of $100-$1,000 per violation. Class action exposure. FTC and CFPB enforcement. |
| GDPR Article 22 | Right to obtain meaningful information about the logic involved in automated decision-making. Right to contest the decision. | Fines up to 4% of global annual turnover or 20 million euros, whichever is higher. |
| BSA/AML (Bank Secrecy Act) | Institutions must understand their transaction monitoring systems. SAR narratives must explain why activity is suspicious with specific facts. | Consent orders, civil money penalties. FinCEN has imposed penalties exceeding $100M for monitoring failures. |
| EU AI Act (effective 2025-2026) | High-risk AI systems must be transparent, allow human oversight, and provide explanations of output. Fraud detection is classified as high-risk. | Fines up to 3% of global annual turnover for deploying non-compliant high-risk systems. |
Every major regulatory framework now requires some form of explainability for automated fraud decisions. The trend is toward more requirements, not fewer.
The real cost goes beyond fines. A consent order from the OCC or FDIC is public. It tells every prospective customer, partner, and investor that your institution failed a basic governance test. In 2023, a major bank received a consent order citing inadequate model risk management for transaction monitoring. The direct penalty was significant. The reputational damage was worse.
Here is what "explainable" actually means to a regulator. It does not mean feature importance charts. It does not mean SHAP waterfall plots. It means: here is why THIS specific alert was flagged, using data the customer or examiner could look up and verify. "Transaction amount was 8x the customer average" is explainable. "Feature 47 had a high attribution score" is not.
The 4 levels of explainability (not all tools offer all levels)
Not all explanations are created equal. A global feature importance chart and a cell-level attribution that points to a specific row in a specific table serve fundamentally different purposes. Understanding these levels is critical because the level you need depends on who is asking and why.
four_levels_of_explainability
| level | what_it_provides | example | who_needs_it |
|---|---|---|---|
| 1. Global feature importance | Top features in the model overall: transaction amount, time, location | Model developers use this for model validation and debugging | Data science team |
| 2. Local feature importance (SHAP) | Per-alert explanation: this transaction was flagged because amount was 8x average (+0.31), new beneficiary (+0.22) | Compliance analysts review individual alerts with feature-level reasons | Compliance analysts, case managers |
| 3. Path-based attribution | This account connects to 3 known fraud accounts through shared devices and intermediate transfers | Investigators and regulators trace fraud networks and money flows | Investigators, regulators, SAR narratives |
| 4. Cell-level attribution | The value $47,832 in TRANSACTIONS row 89201, column amount was the #1 driver (31% attribution) | Auditors verify exact data points. Legal teams build evidence chains. | Auditors, legal, examiners |
Most fraud tools stop at Level 2 (SHAP). Levels 3 and 4 require graph-based architectures that model relationships between entities, not just attributes of individual transactions.
The gap between Level 2 and Level 3 is where most compliance headaches live. SHAP tells you what attributes of a transaction mattered. Path-based attribution tells you what connections between entities mattered. For isolated transaction fraud (stolen credit card, account takeover), SHAP is often sufficient. For network fraud (money laundering, fraud rings, synthetic identity), you need path-based attribution because the fraud signal is in the relationships, not the transaction attributes.
Cell-level attribution is the gold standard for auditability. When an examiner asks "show me exactly what data drove this alert," you can point to specific values in specific tables. Not "transaction amount was important." Rather: "the value $47,832 in the TRANSACTIONS table, row 89201, column amount, contributed 31% of the fraud score." That is verifiable. That is auditable. That is what survives an exam.
Tool comparison by explainability (the table you came here for)
This is the comparison that matters. Most vendor websites bury explainability behind vague language like "transparent AI" or "interpretable models." This table maps each tool to what it actually provides at each level.
fraud_tools_explainability_comparison
| tool | detection_method | global | local_(SHAP) | path-based | cell-level | audit_trail | best_for |
|---|---|---|---|---|---|---|---|
| Rules engines (custom) | Rules | Yes (rules are transparent) | N/A | N/A | N/A | Manual | Simple compliance, clear audit trail |
| NICE Actimize | Rules + ML hybrid | Yes | Partial | No | No | Yes (built-in) | Large banks, AML compliance |
| Featurespace (ARIC) | Adaptive behavioral | Yes | Yes | No | No | Yes | Payment fraud, behavioral patterns |
| DataVisor | Unsupervised ML | Yes | Partial | Partial | No | Partial | Account fraud, clustering |
| Sardine | Device + behavioral | Yes | Partial | No | No | Yes | Fintech, device fingerprinting |
| Alloy | Decisioning platform | Yes | Yes (Actionable AI) | No | No | Yes | Identity verification, onboarding |
| DataRobot | AutoML | Yes | Yes (SHAP) | No | No | Partial | General ML with model monitoring |
| AWS (SageMaker + Neptune) | Custom GNN | Yes | Configurable | Configurable | No | Manual | Build-your-own with ML team |
| Kumo.ai | Graph neural networks | Yes | Yes | Yes (graph paths) | Yes (cell-level) | Automatic | Multi-table fraud with full explainability |
Highlighted: Kumo.ai is the only tool offering all 4 levels of explainability including cell-level attribution. Most tools stop at global and partial local explanations.
A few things stand out. Rules engines win on transparency but lose on accuracy. They catch the patterns you already know about and miss everything else. NICE Actimize and Featurespace occupy the compliance-first tier: strong audit workflows, decent ML, but limited to feature-level explanations. DataRobot provides solid SHAP-based explainability but operates on flat tables, so it cannot explain network patterns. AWS gives you the building blocks to construct path-based explanations with SageMaker and Neptune, but you are writing the explanation layer yourself.
Kumo is the only platform where all four levels are built in. Global importance, local SHAP, path-based attribution through the graph, and cell-level attribution that points to specific values in specific rows. The explanation is not bolted on after the fact. It is a native output of the prediction.
What "explainable" actually looks like in practice
Abstract comparisons only go so far. Here is the same fraud alert explained at each level so you can see exactly what your compliance team would receive.
The alert: Account A transferred $47,832 to Account B at 3:17 AM.
Rules explanation
"Flagged because: amount > $10,000 AND time between midnight-5AM AND new beneficiary."
This is perfectly transparent. A compliance officer can read it, verify each condition, and document the decision. The problem is that rules only catch patterns you already codified. A fraud ring operating at $9,500 transfers at 6 AM sails right through.
SHAP explanation
"Flagged because: amount was 8x customer average (+0.31), first transaction to this beneficiary (+0.22), occurred at 3:17 AM (+0.18), destination country = high-risk (+0.15)."
This is better. Each factor has a measurable contribution. The compliance officer can see not just that the alert fired, but which factors contributed most and by how much. They can document: "The primary driver was the transaction amount being 8 times the customer's historical average." This satisfies most regulatory requirements for individual alert review.
Path-based explanation
"Flagged because: beneficiary Account B shares a device fingerprint with Account C, which was confirmed fraudulent 30 days ago. Account B also received funds from Account D, which is under investigation for money laundering."
Now we are in a different league. The explanation is not about the transaction attributes. It is about the network. The compliance officer can see the connection chain: A sends money to B, B shares a device with confirmed fraud account C, B receives money from investigated account D. This is the kind of narrative that goes into a SAR filing. It tells a story that FinCEN reviewers can follow.
Cell-level explanation (Kumo)
"Flagged because: the value $47,832 in TRANSACTIONS row 89201 was the #1 driver (attribution: 31%). Account B's device_fingerprint DEV-X7K2 in DEVICES row 4401 connected to confirmed fraud account (attribution: 22%). The 3:17 AM timestamp pattern matched historical fraud cadence for this merchant category (attribution: 18%)."
Every claim maps to a specific table, row, and column. An auditor can open the database, navigate to TRANSACTIONS row 89201, verify the amount is $47,832, navigate to DEVICES row 4401, verify the fingerprint DEV-X7K2, and confirm the connection to the fraud account. Nothing is abstract. Nothing requires trusting the model. Everything is independently verifiable.
What most tools provide
- Global feature importance: 'amount, time, and location are the top features'
- Per-alert score: 'this transaction scored 0.87 out of 1.0'
- Partial SHAP: 'amount contributed +0.31 to the score'
- No network context: cannot explain why connected accounts matter
- No data traceability: cannot point to specific rows and values
What compliance actually needs
- Per-alert reasons: 'flagged because amount was 8x average AND new beneficiary AND shared device with fraud account'
- Network context: 'beneficiary shares a device with confirmed fraud, received funds from account under investigation'
- Data traceability: 'TRANSACTIONS row 89201, DEVICES row 4401, specific values verified'
- Audit trail: model version, data snapshot, threshold, reviewer decision
- SAR-ready narrative: connects facts into a story regulators can follow
How to evaluate explainability for your compliance needs
Not every organization needs cell-level attribution. A small fintech processing card-not-present transactions has different compliance obligations than a top-20 bank filing hundreds of SARs per month. Here is how to match the right tool to your situation.
If you are a small fintech with simple rules
Start with a rules engine for transaction monitoring and Alloy for identity verification at onboarding. Rules are perfectly transparent. Every alert has a clear, documented reason. The limitation is accuracy: you will catch known patterns and miss novel fraud. But if your transaction volume is low and your fraud patterns are well-understood, rules plus a manual review process satisfies most regulatory requirements. Add Sardine if device fingerprinting is important to your fraud profile.
If you are a mid-size bank with dedicated compliance staff
NICE Actimize or Featurespace. Both are purpose-built for financial institutions with serious compliance obligations. NICE Actimize has deep AML/BSA workflow integration and is used by most of the world's largest banks, which means examiners are familiar with it. Featurespace excels at adaptive behavioral analytics for payment fraud. Both provide compliance-grade audit trails. The trade-off is that their ML components offer limited explainability beyond feature importance. For network fraud patterns, you may need to supplement with additional investigation tools.
If you need ML accuracy plus compliance-grade explainability
Two options. DataRobot provides solid SHAP-based explainability on flat-table models with built-in model monitoring and governance. If your fraud detection operates on a single feature table and you need per-alert SHAP explanations, DataRobot is a strong choice. If your fraud data spans multiple tables (transactions, accounts, devices, addresses, beneficiaries) and you need to explain not just what attributes mattered but what connections between entities mattered, Kumo provides path-based and cell-level attribution that DataRobot cannot match because it operates on flat tables.
If you need to explain fraud networks to regulators
This is where the field narrows significantly. Money laundering, fraud rings, and synthetic identity fraud are network problems. The fraud signal is not in any single transaction. It is in the pattern of connections between accounts, devices, and beneficiaries. SHAP cannot explain network patterns because SHAP operates on feature vectors, not graph structures. AWS lets you build custom GNN solutions with SageMaker and Neptune, but you write the explanation layer yourself, which means months of engineering and no guarantee the output satisfies your compliance team. Kumo is the only platform that provides path-based and cell-level attribution on graph-structured data as a built-in capability.
explainability_decision_framework
| your_situation | recommended_approach | explainability_level | key_trade-off |
|---|---|---|---|
| Small fintech, simple fraud patterns, low volume | Rules engine + Alloy for onboarding | Level 1 (rules are fully transparent) | Perfect explainability, limited fraud detection accuracy |
| Mid-size bank, regulatory exams, AML/BSA focus | NICE Actimize or Featurespace | Level 1-2 (global + partial SHAP) | Strong compliance workflow, limited network fraud explanation |
| Enterprise needing ML accuracy + flat-table explainability | DataRobot with SHAP | Level 1-2 (global + full SHAP) | Strong per-alert explanations on flat data, no graph capability |
| Any institution with multi-table data or network fraud | Kumo.ai | Level 1-4 (all levels including cell-level) | Full explainability stack, requires relational data structure |
| Large ML team wanting full control, custom pipeline | AWS SageMaker + Neptune | Level 1-3 (configurable, requires custom build) | Maximum flexibility, significant engineering investment |
Highlighted: Kumo is the only option that provides all 4 levels of explainability as a built-in capability without custom engineering.
Frequently asked questions
What level of explainability do regulators actually require?
It depends on the regulation and the action taken. For adverse actions under ECOA and FCRA, you need specific reasons a consumer can understand: 'transaction flagged due to amount exceeding historical pattern and destination being a newly added beneficiary.' For BSA/AML suspicious activity reports, you need a narrative that connects observable facts to suspicious behavior. For the EU AI Act, high-risk AI systems (which includes most fraud detection) require transparency about the logic involved, the significance, and the envisaged consequences. In practice, regulators want to see that a human reviewed the alert, understood why the model flagged it, and made a documented decision. A score alone never satisfies any of these requirements.
Can deep learning models be made explainable for compliance?
Yes, but the approach matters. Post-hoc explanation methods like SHAP and LIME can approximate why a deep learning model made a specific prediction by measuring how much each input feature contributed to the output. These work for per-alert explanations. The limitation is that post-hoc methods approximate the model's reasoning rather than revealing it directly. Graph neural networks add a layer that most deep learning models lack: path-based attribution, which shows the actual connections between entities that influenced the prediction. Kumo's cell-level attribution goes further by tracing predictions back to specific values in specific rows of specific tables. The key question is not 'can deep learning be explained?' but 'can the explanation survive an audit?' SHAP values satisfy most regulators. Path-based and cell-level attribution satisfy all of them.
What is the difference between SHAP values and path-based explanations?
SHAP values tell you which features drove a prediction and by how much. For example: 'transaction amount contributed +0.31 to the fraud score, time of day contributed +0.18.' This is useful but operates at the feature level. Path-based explanations tell you which relationships between entities drove the prediction. For example: 'this account shares a device with an account that was confirmed fraudulent 30 days ago, and that account received funds from a third account under investigation.' SHAP answers 'what attributes matter?' Path-based answers 'what connections matter?' For network fraud, money laundering, and organized fraud rings, path-based explanations are far more informative because the fraud signal lives in the relationships, not in the individual transaction attributes.
Do we need different explainability for SAR filings vs internal audit?
Yes. SAR narratives require a story: who did what, when, why it is suspicious, and what patterns connect the activity to potential criminal behavior. Internal audit requires traceability: which model version produced this alert, what data it used, what threshold triggered the flag, and whether the model's logic is consistent with your risk appetite. For SARs, path-based explanations are extremely valuable because they connect accounts, transactions, and entities into a narrative that FinCEN reviewers can follow. For internal audit, you need model versioning, data lineage, and reproducibility. Some tools provide one but not the other. NICE Actimize and Featurespace are strong on SAR workflow. Kumo provides both the narrative (path-based attribution) and the traceability (cell-level attribution with exact data references).
Which tools meet EU AI Act requirements?
The EU AI Act classifies fraud detection as high-risk AI, which triggers requirements for transparency, human oversight, accuracy, and robustness. Article 13 requires that high-risk systems be designed to be sufficiently transparent to enable users to interpret the output and use it appropriately. Article 14 requires human oversight capabilities. As of early 2026, no tool has formal EU AI Act certification because the conformity assessment process is still being established. However, tools with built-in explainability (SHAP or better), audit trails, and human-in-the-loop workflows are best positioned. Rules engines are compliant by design. NICE Actimize and Featurespace have strong compliance frameworks. Kumo's cell-level attribution provides the most granular transparency available. Pure black-box models without post-hoc explanation will struggle to meet Article 13 requirements.
How do we explain graph-based fraud detection to non-technical regulators?
Drop the math. Use the analogy of a map. A graph-based fraud model works like a detective connecting pins on a map with string. Each pin is an account, device, or transaction. Each string is a relationship: 'sent money to,' 'shares a device with,' 'registered from the same IP.' When the model flags a transaction, you can show the regulator the map: 'Account A sent $47,832 to Account B. Account B shares a device with Account C, which was confirmed fraudulent. Account B also received funds from Account D, which is under investigation.' The regulator does not need to understand message-passing or embedding spaces. They need to see the connections, verify they are real, and decide whether they constitute suspicious activity. Path-based and cell-level attribution translate graph-model outputs into exactly this kind of narrative.
Can we use Kumo's cell-level attribution in court?
Cell-level attribution provides specific, verifiable data references: the exact table, row, column, and value that drove a prediction. This is the kind of evidence that expert witnesses can present because it is auditable and reproducible. An expert can testify: 'The model flagged this transaction because the value $47,832 in the TRANSACTIONS table, row 89201, was 8 standard deviations above the account average, and the destination account shared a device fingerprint with a confirmed fraud account.' Every claim maps to a specific data point that can be independently verified. Whether this meets the Daubert standard for admissibility depends on the jurisdiction and the specific case, but cell-level attribution provides a much stronger foundation than 'the model gave it a high score.' Consult with legal counsel for your specific jurisdiction.
What is the compliance risk of using unexplainable models?
The risks are concrete and escalating. Under ECOA, failing to provide specific reasons for adverse actions can result in enforcement actions and civil penalties. The CFPB has issued guidance that 'the algorithm said so' is not an acceptable reason. Under BSA/AML, regulators expect institutions to understand their monitoring systems well enough to explain why alerts fire and why they do not. The OCC's 2023 consent order against a major bank cited inadequate model risk management for transaction monitoring. Under the EU AI Act, deploying a non-compliant high-risk AI system can result in fines up to 3% of global annual turnover. Beyond fines, the reputational damage from a consent order or enforcement action can cost multiples of the direct penalty. The trend is clear: regulators are getting more sophisticated about AI, and 'we cannot explain it' is becoming an unacceptable answer.