Fraud case management software is where a bank's fraud team works its cases: it takes the alerts the detection engines raise, gathers the evidence, records the decision and who approved it, tracks what was lost and recovered, and hands suspicious activity to the BSA team. The quickest way to judge it is to ignore the feature list and open the case file it leaves behind. That file has to survive a supervisor's review, an internal audit, an examiner's sample and, when a SAR is filed, a request from law enforcement. The work is hard because the inputs are scattered: each engine raises its own alerts in its own queue, and the evidence sits in the core, the digital banking logs, the check archive and the call recordings. Botminds' Fraud Case Management exists to make that file the product: agents merge the alerts, gather the evidence and draft a cited memo, and named people decide and approve.
The examples on this page come from a fictional sample bank, Corvane National Bank, and its account-takeover case for a business customer, Ridgeline Auto Body LLC, as it runs through the solution. The bank, the customer, the people and every figure about them are invented sample data; figures marked as targets are design goals, not measured results.
Seven questions about the case file, and what a good answer shows
A weak answer: Each engine’s alert becomes its own case; duplicates are closed by hand.
A good answer: Alerts sharing a customer, device or payee become one case, and each dropped duplicate stays visible with its reason.
A weak answer: Screenshots and notes pasted into a free-text field.
A good answer: A tab per source, each saying what was taken from it, opening the original record.
A weak answer: A narrative typed from memory of five systems.
A good answer: Every sentence links to the passage it rests on; edits are marked with their author.
A weak answer: The investigator posts the reimbursement and the write-off.
A good answer: One person proposes, another approves, and nobody approves their own case.
A weak answer: Due dates in a spreadsheet, extended when the queue is long.
A good answer: Each clock starts from a named event and escalates on breach; nobody extends it quietly.
A weak answer: Into the same case notes the customer letter is written from.
A good answer: Into a restricted space; the fraud case keeps only a reference.
A weak answer: It goes live on Monday and the queue finds out.
A good answer: It is replayed on closed cases first, and a named officer approves it.
What is fraud case management software, and what should it produce?
Fraud case management software is the system of record for fraud decisions, and its product is the case file. A complete file holds the alerts that started the case, the evidence with where each piece came from, the classification of what happened, the decision and who made it, the money that moved because of it, any referral to the BSA team, and a trail of who did what and when. Everything else, from queues to dashboards, is a way of producing that file on time.
The volume is why this matters now. FinCEN data cited by the federal banking agencies in their 2025 request for information show that SARs filed on check, ACH and wire fraud rose 489 percent between 2014 and 2024. Each of those SARs started as a fraud case somewhere, and the case file is what the BSA team relies on when it decides to file. When a SAR is filed, the documents behind it become supporting documentation that a bank must keep for five years from the date of filing and produce to FinCEN, law enforcement or its examiners on request. A case file built from pasted screenshots is a weak thing to hand over.
Read a vendor's demonstration with that in mind. A clean queue view proves little. The question is whether a supervisor who never touched the case can open it a year later and see what happened, what the bank decided, why, and who signed.
Does it turn four alerts about one customer into one case?
It should, and it should show its working. One account takeover rarely arrives as one alert. On Corvane's sample case the payments fraud engine flagged a $48,600 wire to a new payee, flagged the same wire again from a velocity rule, and flagged a $9,800 ACH debit from an originator never seen on the account. Two days later the check and deposit engine flagged check #1182, returned counterfeit. Four alerts from two engines, one fraud.
In the solution, the intake agent joins alerts that share a customer, device or payee inside a 72-hour window. It merges on its own only at 0.90 confidence or above; between 0.75 and 0.90 it suggests, and a person accepts or keeps the alerts apart. The Ridgeline alerts joined at 0.97 on the same customer and the same device. The duplicate wire alert was dropped, but it stays on the case with its reason and a Restore button, so nobody wonders later where it went.
Alerts into cases: one customer, one case, the duplicate kept in view
Two rules matter more than the threshold. Two customers are never merged into one case; the same device on another customer's login is linked, not joined. On the sample case, device DV-8F21 also logged in to a second business customer's profile the day before, and the two cases stay separate and linked. And an investigator can split any alert back out with a reason code, which is how a wrong merge gets corrected without losing the trail.
Can every sentence of the decision memo be traced to its evidence?
A good system makes the memo checkable sentence by sentence; a weak one gives the supervisor a narrative and asks for trust. The difference is visible in a minute. Ask the vendor to click a sentence in a drafted memo and show you the record it came from.
On the Ridgeline case the evidence agent pulled nine sources into the binder: alerts, core transactions, the digital banking device log, the check image, the call transcript, prior cases, the payments hub's recovery records and the bank's own standard for new-payee holds. Each tab says in one line what the agent took from it. The drafting agent wrote a 17-sentence memo with all 17 cited, and writes no sentence it cannot cite. A sentence a person types is marked as theirs, and the agent's original wording is kept in the history.
Citations alone are not enough, because a sentence can cite a source that does not support it. That is the quality agent's job: before the supervisor sees the memo, it scores every sentence against its source and challenges any below a support score of 0.70. On the sample case it challenged the claim that the owner "clicked a phishing link", which rested only on the owner's own belief in a phone call. How that check works, and what it cannot catch, is set out in AI for fraud investigation.
Who can move money, and who checks them?
In a well-built system, no single person can move money on a fraud case, and the software, not a policy binder, enforces it. Freezes and unfreezes, reimbursements, charge-offs, general ledger entries, customer letters and referrals should all need a maker and a different checker. Self-approval should be impossible, not merely discouraged.
The sample bank's settings show what that looks like in practice. The investigator proposes; the fraud investigations supervisor approves up to $50,000 of net loss or reimbursement per case; the Chief Fraud Officer approves above that. Bulk approval is allowed only for closes with no loss and no customer letter. The Ridgeline close carried a $22,300 reimbursement and two general ledger entries to fraud losses, $19,500 and $2,800. The investigator made them, the supervisor checked them, and they posted only on his approval. The agents draft the entries and never post them.
Ask a vendor where the approval limit lives, who can change it, and whether the change is on the audit trail. On the sample bank, the administrator proposes changes to limits, clocks and thresholds and the Chief Fraud Officer approves them.
Does it run the clocks that law and policy set?
Fraud case management software should run every clock a case carries from the event that starts it, remind before the deadline and escalate on a breach. Some clocks come from law. A bank must file a SAR no later than 30 calendar days after it first detects facts that may justify one, or 60 if no suspect has been identified. For a consumer's notice of an unauthorized electronic transfer, Regulation E gives the bank 10 business days to decide, or up to 45 days with a provisional credit. Others are the bank's own: triage, decision, referral to BSA.
One sample bank's queue on one morning
1,146
open fraud cases across 38 investigators
23
past their decision clock
31
open cases per investigator, on average
24hours
triage clock from the alert
The test is what starts each clock and who can stop it. On the sample bank, a reminder goes out one business day before a deadline, a breach escalates to the supervisor, and three business days past it the case goes to the Chief Fraud Officer. The clock agent never extends a deadline. A system that lets an investigator push a due date without a reason on the trail is measuring the queue's patience, not its timeliness.
Can fraud case management software file SARs?
It should not, and you should be wary of one that does it from the fraud case. The decision to file belongs to the bank's BSA function, and the SAR and anything that would reveal it are confidential under 31 CFR 1020.320(e). What fraud case management software should do is recognize when a referral is due, draft it with the facts, and move it somewhere the fraud team, the customer letter and the fraud exports cannot see.
For a national bank, the fraud thresholds that make a SAR mandatory are in the OCC's rule: insider abuse of any amount, $5,000 or more where a suspect can be identified, and $25,000 or more regardless of a suspect. The Ridgeline case totalled $61,200, so the referral agent drafted a referral and moved it to a restricted BSA space. The fraud case keeps only the reference. Whether a report is filed, and the BSA officer's notes, never appear in the case, a customer letter, a customer view or a fraud export.
The referral sits with BSA; the fraud case holds a reference
If your bank has a separate AML case system, the referral has to land there in a usable form. The questions to put to that side, including how it protects SAR confidentiality, are in twelve questions to ask about an AML case management system.
How is fraud case management different from AML case management?
They answer different questions on different clocks. A fraud case asks whether money was taken by deception or without authority, who bears the loss and what can be recovered; it ends in a reimbursement or a denial, general ledger entries and a letter. An AML case asks whether activity is suspicious and ends in a decision to file or not file a SAR. They meet at the referral, and a bank needs both sides to work.
Fraud case management and AML case management, side by side
| Fraud case management | AML case management | |
|---|---|---|
| Starts from | An alert or a customer’s report of a loss or attempt | A monitoring alert, a referral or a law enforcement inquiry |
| The question | Was it fraud, who bears the loss, what can be recovered? | Is the activity suspicious enough to report? |
| Main clocks | Regulation E for consumer claims; the bank’s own triage and decision clocks | SAR filing: 30 days from initial detection, 60 with no suspect |
| Money moves | Reimbursements, charge-offs, recalls, returns, general ledger entries | Rarely; the output is a report |
| Customer contact | A letter with the outcome | None about the SAR, by law |
| Who signs | Investigator and supervisor; senior officer above a limit | The bank’s SAR decision maker, an individual or a committee |
Many banks run the two in separate teams, and examiners expect the lines between them to stay open. Where the file can be shared and where it must be sealed is the subject of fraud and AML convergence.
What happens when a rule or an agent changes?
A good system tests the change on cases already decided before it touches live ones, and it never uses that test to re-decide a closed case. Merge windows, clocks, approval limits and agent thresholds are all settings, and every change to them shifts how cases are built or decided. On the sample bank, a proposal to widen the merge window from 72 to 96 hours was replayed on 300 closed cases before it was approved, and every new agent version replays a golden set of 300 closed cases before the Chief Fraud Officer signs it off.
The line between a replay and a re-decision has a regulatory history. In its 2022 order against Bank of America over prepaid unemployment-benefit cards, the CFPB found the bank had engaged in abusive acts or practices "by retroactively applying its fraud filter to deny notices of error submitted by prepaid debit cardholders that it had previously investigated and paid". A replay should show what a new rule would have done, so a person can judge it; it should never reach back and reverse decisions already made.
Expect the model-risk question too. The April 2026 interagency guidance excludes deterministic rule-based processes from its definition of a model and puts generative and agentic AI outside its scope for now. That leaves the bank to govern the agents itself, which is why the version, prompt and threshold in force on each case should be on the record.
The audit trail, people and agents on one record
How long does fraud case management software take to implement, and what does it cost?
Both depend on how many systems a case reads from and how much of your policy has to be written down as settings, and any vendor that quotes either without seeing those is guessing. The connections are the bulk of the work: each detection engine, the core, the device and session logs, the check archive, the call recordings, the payments hub for recalls and returns, and the general ledger. The policy is the rest: clocks, merge rules, approval limits, reason codes and the decision codes your investigators use.
Two items deserve a line in any plan. Open cases have to move with their clocks intact: a case due on Thursday in the old system must still be due on Thursday in the new one, with its evidence and its history. Closed cases are worth bringing too, because prior cases are evidence; the sample bank carries its cases back to 2017 from its previous case system, which is how the Ridgeline binder could show no prior fraud on the customer.
On effort, the product team's own estimate for one multi-alert account-takeover case is about nine hours of investigator and supervisor time by hand and under two with the agents, deliberately kept modest. Treat that as an estimate to test, not a result. The way to test it is on your own material: the solution can be run on a sample of a bank's past alerts and closed cases before any decision to buy, and that run is the cheapest evidence you will get.
Where Botminds' Fraud Case Management fits, and where it does not
It fits a bank with more than one detection engine, investigators who copy evidence between systems, and supervisors who sign closes they cannot check line by line. It sits after detection and before the SAR decision: it does not score transactions, and it does not file SARs. Its agents never close a case, move money, post to the general ledger, contact a customer or another institution, or file a SAR; people do all of those, two at a time where money or letters are involved.
It is not the right purchase if the bank's problem is detection itself, if one engine and a small team already produce clean files, or if the bank wants software that makes fraud decisions without a person. The classification it uses can follow the Federal Reserve's FraudClassifier model, which sorts fraud by who initiated the payment and how, regardless of channel, so check, ACH and wire cases share one vocabulary. The whole case is shown screen by screen on the Fraud Case Management page.
Before you sign: eight things to see on your own closed cases
- Three of your multi-alert cases, merged
Including the duplicate it dropped and the reason it gives.
- A memo sentence, clicked
It should open the record it rests on, not a summary of it.
- A sentence that should fail
Plant one resting on hearsay and see whether the system challenges it before the supervisor does.
- The approval record for a reimbursement
Maker, checker, limit, time; and proof that self-approval is impossible.
- Every clock on one case
What started each, when it escalates, and who can extend it.
- A customer letter on a referred case
Nothing in it, or in the customer view, should hint at a referral.
- A rule change, replayed
Run on closed cases, shown to an approver, never re-deciding a paid claim.
- An examiner pack
Built from the cases, masked, with referral material left out.
Questions people ask
What is the best fraud case management software?
The one whose case files hold up on your own closed cases. We know of no independent government or academic ranking of these products, so the comparison has to be done on your material: run three or four of your past multi-alert cases through each candidate and compare the files. Judge the merge, the citations, the approvals and the sealing of referral material, not the queue screen.
Does fraud case management software replace the detection engine?
No. Detection engines score payments and logins and raise alerts; case management works those alerts into decisions. The sample bank keeps three engines, a payments fraud engine, a check and deposit engine and a digital banking session monitor, and the case software reads all three.
How do you migrate open fraud cases to new software?
Move each open case with its evidence, its history and its clocks as they stand, so no deadline restarts or vanishes in the move. Close the old system to new work on a fixed day, migrate open cases first, then closed ones as prior-case evidence. Check a sample of migrated cases against the old system before it is switched off.
Does fraud case management software need model validation?
The April 2026 interagency guidance does not treat deterministic rule-based processes as models, and it places generative and agentic AI outside its scope pending a promised request for information. The bank still owns the risk: keep each agent's version and thresholds on the record and test changes on closed cases before they go live.
Can one system handle check, ACH, wire and P2P fraud cases?
It should, because one fraud often crosses channels: the Ridgeline takeover involved a wire, an ACH debit and a counterfeit check. The Federal Reserve's FraudClassifier was built to classify fraud independently of payment type or channel, which makes a shared decision vocabulary possible across them.
Who should own the fraud case management system?
Fraud operations should own the cases and the settings, with the Chief Fraud Officer approving changes to limits, clocks and agent versions. The BSA officer should own the restricted referral space. Internal audit should be able to read everything and approve nothing.