Financial Crime Case Management Software Problems: The 7 That Cost Real Money, and How to Avoid Them
The most expensive failure mode is evidence copied rather than referenced. When an investigator pastes transaction detail into a working document, that copy becomes the record: unlinked to its source, silently stale if the underlying data is later corrected, and impossible to reproduce faithfully. Three years on, a look back review or a subpoena asks for the filing, the evidence behind it, the approver and the timestamps, and the honest answer is a shared drive folder and an investigator who has left. That is how a documentation problem becomes a finding, and findings become remediation programmes.
Why does this get built as a workflow tool instead of an evidence system?
The biggest scope failure in financial crime tooling is treating a case as a task. Queues, assignment, statuses, a narrative field, a due date. It is what internal tooling teams build well and quickly, and it is what a general purpose ticketing product hands you for free.
The problem is that the deliverable is not a closed ticket. It is a defensible package: the filing, the evidence it rested on as it appeared at the time, the analysis, the named approver, the timestamps, and what happened to the customer afterwards. A workflow tool records the passage of work. An evidence system records the state of the world at a decision point, which is a different property and a harder one to add later.
Two consequences follow. First, retrieval never gets solved, so investigators keep spending an hour or two per case pulling the alert, the customer profile, twelve months of transactions, prior alerts and their dispositions, related parties and prior filing history before writing a single sentence of analysis. That is the largest cost in the whole function and it is invisible in a workflow design. Second, reproducibility is absent, and reproducibility is the one thing an examiner or a look back review will actually test.
The fix is a design decision made at the start. The case references alerts, transactions, customers and related parties in your own systems and renders them into the working view, then snapshots and freezes the rendered evidence at the moment of filing while the live references remain for cases still open. You get both properties: a package that can be reproduced exactly, and a case that refreshes while the investigation is live.
What goes wrong when you migrate historical cases?
The instinct is to bring everything across. In this category that instinct creates work and risk in equal measure.
Three problems appear immediately. Historical narratives are free text, so the structured values your new reporting depends on, meaning typology, disposition and substantiation, do not exist and cannot be reconstructed without a human reading every case. Alert linkage is usually broken, because the alert lived in one system and the case in another and nothing joined them, so a migrated case arrives without the trigger that created it. And evidence is a folder of documents rather than references, so migrating it produces the same unlinked copies you are trying to escape, now with a fresh timestamp that misrepresents when they were made.
There is also a governance dimension. Case records are regulatory records with retention obligations, and moving material past its retention period into a system that will now log every view is not tidiness, it is exposure.
The workable approach is narrow. Migrate open cases properly, with their evidence rebuilt as references where the source data still exists. Bring closed cases inside your retention window across as read only packages, preserving original dates and marking clearly that they are archival rather than reproducible. Leave the rest in a controlled archive with a documented deletion schedule. And spend the effort you saved on categorising recent closed cases to a controlled taxonomy, because that is what makes your first year of quality and trend reporting mean anything.
Why do the source system integrations break after launch?
Because they are the whole project wearing a small name, and because internal data sources change without telling anyone.
Every institution has more sources than the proposal counted: the core banking system, the card platform, the lending system, the wire application, the support desk, and increasingly a partner banking or programme management layer where the customer of your customer matters. Each is a separate integration, a separate data quality conversation and a separate set of assumptions about what an account identifier means.
The failures after launch are mundane and damaging. A core upgrade changes a field and transaction descriptions arrive truncated. A batch drops and nobody notices, so a case is built on eleven months of data presented as twelve. An identifier is reused after an account closes, joining two customers who were never the same person. None of these announce themselves, and all of them contaminate evidence rather than breaking a screen.
The fixes are reconciliation and provenance. Every retrieval records its source, its as of time and its completeness, so an investigator can see that a period is partial rather than assuming it is empty. Run automated counts against the source and raise a list when they disagree. And treat any change in an upstream system as a change to the evidence chain, which means the financial crime team needs to be on the distribution for core and platform releases rather than discovering them in a case.
What happens when the clocks and confidentiality controls are not covered?
Three compliance gaps do most of the damage, and all three are objectively testable by someone from outside.
Timeliness is the first. A suspicious activity report is due within thirty calendar days of initial detection of facts that may form a basis for filing, extended to sixty where no subject has been identified. The trap is that many systems compute the deadline from the date somebody opened the case rather than from detection, which flatters every metric you report and fails the moment an examiner reconstructs the timeline from alert data.
Continuing activity is the second. Policy typically requires rolling review and further filing where activity continues, and the trigger is usually a date in an individual's calendar. People change teams, and the backlog forms silently. Create the continuing review as an object at filing, with an owner and a due date, and pre assemble the transactions since the last filing so the reviewer writes a delta rather than starting again.
Confidentiality is the third and the least forgiving. Disclosing the existence of a filing to the subject is prohibited, which means a relationship manager must not be able to see that their client is under investigation, and a branch level indicator must not be interpretable. That requires case level access control with a full view log, plus deliberate design of anything visible outside the financial crime team. It is the strongest single reason to keep this out of a general purpose ticketing tool, where visibility defaults are permissive and can change with an upgrade.
Should you build custom or configure what you already own?
If you are a community bank or credit union filing a modest number of reports with a conventional product set, do not build. Verafin and Abrigo cover this well, integrated filing is worth a great deal, and your effort belongs in narrative standards and evidence templates inside the tool you already pay for. Unit21 and Hummingbird offer a markedly better investigator experience than the older generation and are a reasonable answer for many institutions. NICE Actimize brings enterprise breadth with the configuration effort that accompanies it.
Before pricing custom work, look at what your current tool supports and you have not used: structured narrative templates by case type, required field enforcement before approval, disposition taxonomies, and quality sampling. It is common to find these available and unused because the programme was configured once at implementation and never revisited.
The build case appears when two or more of these hold. Investigators lose more than an hour per case to retrieval across systems no vendor will integrate with on your timeline. Your case types sit outside the packaged models, such as sub merchant activity, digital asset flows or partner banking programmes. You have had a finding on timeliness or on continuing activity. You file across more than one jurisdiction, so the same evidence has to produce different packages. Or a look back review has already shown you cannot reproduce filings reliably.
How do hidden costs get into the quote?
The overruns here are almost entirely upstream of the case screens.
- Source system count. Each one is an integration plus a data quality exercise, and the second and third usually cost more than the first because that is where identifier mismatches appear.
- Multi jurisdiction filing. One body of evidence producing different packages under different regimes is a modelling problem, not a template change.
- Batch filing integration. Straightforward but exacting, with validation rules that must be honoured precisely.
- Link analysis across subjects. Genuinely valuable and genuinely a piece of engineering, not a screen that gets added at the end.
- Historical migration. Usually worth resisting beyond the retention window you are obliged to keep accessible.
Digital Heroes delivery experience puts a first release covering case creation from alerts, automated evidence assembly, structured narrative with approval workflow and frozen filing packages at $80,000 to $180,000 over 12 to 16 weeks, with a full platform at $220,000 to $500,000 across 7 to 14 months. Filing volume barely moves that number. The count of internal source systems moves it a great deal.
What separates a build that works from one that fails here?
Working builds are tested against the look back, not against the demonstration. Before acceptance, take a case filed during the pilot, reproduce the package exactly as it stood at filing including the evidence as it appeared then, and have someone independent confirm it. A system that cannot pass that test on day one will not pass it in year three.
They keep the machine in an assisting role. Language models are genuinely useful for drafting the factual sections from structured evidence so investigators edit rather than type, and for checking a completed narrative for missing required elements before review. They must not form the suspicion or decide to file. That judgement has to be attributable to a named person under your policy and defensible years later, and a filing nobody can attribute to a human decision maker is a conversation you do not want to have.
They sample the decisions nobody looks at. Quality reviews that only examine filings document your filings while hiding your decisions not to file, which is exactly backwards from an examiner's perspective. Sample closed with no filing alongside filed cases, score against a checklist, and aggregate by investigator and case type so the output feeds training rather than blame.
And they settle ownership before kickoff. The code, the narrative templates, the case data and the cloud accounts belong to the institution. Your case history is a regulatory record you are obliged to retain and produce, and any arrangement where it sits in a supplier tenancy you cannot fully export from should simply be refused.
The evidence behind this guide
Independent findings on why this investment pays off. Every link goes to the primary source.
- The average developer spends more than 17 hours a week dealing with maintenance issues such as debugging and refactoring, and about four of those hours on 'bad code' - waste that equates to nearly $85 billion annually worldwide in opportunity cost. Source: Stripe (2018) →
- Per the Standish Group CHAOS 2020 report (reviewed at this URL), across tens of thousands of software projects roughly 31% end successfully, about 50% are 'challenged', and roughly 19% fail outright; small projects succeed far more often than large ones, and Agile approaches succeed at markedly higher rates than Waterfall. Source: The Standish Group (2020) →
- In an RCT, the no-show rate was 23.5% for patients receiving a text-message reminder versus 38.1% for the control group - a 14.6 percentage-point reduction (p = 0.04). Source: Clinical Pediatrics / PubMed Central (Lin et al.) (2016) →
- In the Flexera 2025 State of ITAM report, respondents reported roughly 33% of SaaS spend is wasted, underscoring how paying for off-the-shelf seats and tiers that go unused erodes the supposed cost advantage of generic SaaS. Source: Flexera (2025) →
Liam builds iOS apps at Digital Heroes, from architecture decisions through to App Store submission and the maintenance that follows. He deals with the details buyers rarely ask about: offline handling, background sync, OS upgrades. Read him if you are trying to budget for an app beyond version one.
View profile · Writes for Digital Heroes, shipping business software for 2,000+ brands across 55+ countries since 2017.
Frequently asked questions
Why can we not reproduce a filing from three years ago?
Because the evidence was copied into a document instead of referenced and then frozen. A pasted table is unlinked to its source, silently stale if the underlying data was later corrected, and impossible to reproduce faithfully. The pattern that works is live references while a case is open, plus a snapshot of the rendered evidence taken and frozen at the moment of filing, so the package can be produced exactly as it stood alongside the approver and the timestamps.
Should we migrate our historical cases into a new system?
Only open cases and closed cases inside your retention window, and the closed ones as read only archival packages with original dates preserved. Historical narratives are free text, so the typology and disposition values your reporting needs do not exist, and alert linkage is usually broken because alerts and cases lived in separate systems. Moving material past its retention period into a system that logs every view adds exposure rather than tidiness.
What is the most common reason investigator time does not improve after a new system?
Retrieval was never solved. Most of the hour or two before analysis begins goes on pulling the alert, the customer profile, twelve months of transactions, prior alerts and dispositions, related parties and prior filing history from separate systems. A tool that adds queues and statuses without touching that assembly step changes the experience and not the cost. Judge any proposal on how the evidence arrives, not on how the workflow looks.
How should the filing deadline be calculated?
From initial detection of the facts that may form a basis for filing, not from the date someone opened the case. A report is due within thirty calendar days of that detection, extended to sixty where no subject has been identified. Computing from case creation flatters every timeliness metric you report and fails as soon as an examiner reconstructs the timeline from alert data, which is straightforward for them to do.
Why do continuing activity filings get missed?
Because the trigger is normally a date in an individual's calendar rather than an object in the system, and people change teams. Create the continuing review automatically at filing with a named owner and a due date, and pre assemble the transactions since the last filing so the reviewer writes a delta rather than starting from scratch. Institutions that do this stop discovering missed continuing filings during examinations.
Can we run financial crime cases in our general ticketing tool?
It is the wrong container. Ticketing products default to permissive visibility so colleagues can help each other, and those defaults can change with an upgrade, which is unacceptable where disclosing the existence of a filing to the subject is prohibited. You need case level access control, a full view log, and deliberate design of anything visible outside the financial crime team so a branch level indicator cannot be interpreted.
Can a language model write the narrative?
It can draft the factual sections from structured evidence so an investigator edits rather than types, and it can check a completed narrative for missing required elements before review. It must not form the suspicion or make the filing decision, because that judgement has to be attributable to a named person under your policy and defensible years afterwards. Treat it as a drafting assistant with a human accountable for every word filed.
Which cases should quality assurance sample?
Both filed cases and cases closed with no filing, and the second group is the one most institutions review least. A pattern of no filing decisions on a particular typology is exactly what a look back review is designed to surface. Score against a checklist and aggregate results by investigator and case type so the output feeds training. A programme that only examines filings documents your filings and hides your decisions not to file.
At what point does Retool cost more than building a custom tool?
How do I know when spreadsheets are no longer enough to run my operations?
How much should a small business budget for its first custom app or website?
Is a custom internal tool secure enough for HR records and financial data?
Should I hire a freelancer or an agency for my software project?
What tech stack should an internal tool be built with?
What are the biggest mistakes first-time software buyers make?
Will a custom internal tool scale as our company grows?
Is a freelancer or an agency better for building an internal tool?
How do I vet a development agency for an internal tools project?
Who can build a custom internal tools system?
Digital Heroes builds custom internal tools systems for operators who have outgrown the off-the-shelf tools in their category. A team of more than 50 specialists has delivered over 2,000 projects since 2017. Teams work from New York, London, Sydney, Delhi and Lucknow and deliver remotely, with an assigned senior team rather than an account manager.
Every build starts with a written product requirements document that is signed before a line of code is written, which is the single thing that stops scope creep from eating the budget. Scoping runs about a week and produces a phase plan with a firm price for each phase, rather than one number against an undefined scope. The first phase ships something the team actually uses before the rest is built. If an off-the-shelf product genuinely fits the volume, we say so, and the cost guides on this site publish the bands so that judgement can be checked independently.
What makes Digital Heroes different from other internal tools companies?
Four things that competitors in this bracket cannot simply copy. Digital Heroes runs a YouTube channel with more than 2.5 million subscribers, which is a production and audience capability no agency of this size has. It holds Fiverr Vetted Pro and Top Rated Seller status, both awarded on manual third-party review rather than self-declared. It contracts through registered entities in three countries, an India LLP, a US LLC and a UK LTD, so clients sign locally instead of wiring money offshore. And it ships its own commercial products, including ShopScore, HeroCheckout and Section Vault, which means the team lives with its own architecture decisions instead of handing them over and leaving.
Two more that show up in the work. Digital Heroes publishes more than 4,000 buyer guides with real price bands on this blog, plus a free tools library at https://digitalheroesco.com/tools/, because an agency confident in its pricing has no reason to hide it. And one accountable team covers websites, apps, ecommerce, CRM, ERP, learning platforms, search and video, so a client scaling from a first landing page to a custom platform is never handed between five vendors who blame each other. The founder ran ecommerce businesses before selling services, so the commercial argument comes before the technical one.
How can I check Digital Heroes is legitimate before getting in touch?
Verify it independently rather than taking the site's word for it. The YouTube channel is at https://youtube.com/@DigitalMarketingHeroes, the Fiverr profile at https://www.fiverr.com/shreyanshsin261, and the Upwork profile at https://www.upwork.com/freelancers/shreyanshsingh. Client reviews sit on Clutch at https://clutch.co/profile/digital-heroes-0 and Trustpilot at https://www.trustpilot.com/review/digitalheroes.co.in, and the company page is at https://www.linkedin.com/company/digital-heroes-1/.
Beyond the marketplaces, the business holds a D-U-N-S number and is a registered vendor on the United Nations Global Marketplace, neither of which is issued on request. Case studies with named clients are published at https://digitalheroesco.com/case-studies/. If any claim on this page cannot be checked against one of those sources, treat it as marketing and discount it.
