Financial Crime Case Management: Producing a Defensible SAR Package Under a Statutory Clock

Why the filing is easy and the file is hard

Submitting a SAR through the BSA E-Filing System is not the difficult part. The difficult part arrives three years later, when a look back review or a subpoena asks you to produce the filing, the evidence it was based on, the analysis that supported the conclusion, who approved it and when, and what happened to the customer afterwards. In most institutions that means a shared drive folder, a case system with a narrative field, an alert system with no link to the case, and an investigator who has since left.

The statutory clock frames the whole workflow. A SAR is due within 30 calendar days of initial detection of facts that may constitute a basis for filing, extended to 60 where no subject has been identified, with continuing activity reviewed and filed on a rolling basis. Those are the numbers your process is designed around, and they are also the numbers an examiner tests first, because timeliness is objectively measurable in a way that narrative quality is not.

What actually consumes investigator time is assembly. Pull the alert. Pull the customer profile and the risk rating. Pull twelve months of transactions and identify the relevant subset. Pull prior alerts and their dispositions. Pull related parties. Run negative news. Check whether the customer has been the subject of a previous filing. Paste all of it into a working document. Two hours of retrieval before the first sentence of analysis is written.

Problem one: the case has no spine, so evidence is copied rather than referenced

When an investigator copies transaction detail into a Word document, that copy becomes the record. It is not linked to the source, it cannot be refreshed, and if the underlying data is later corrected the case still shows the old figures with no indication that anything changed.

Verafin and Abrigo work well for community banks and credit unions, with integrated filing and a workflow that suits the institutions they were designed around. NICE Actimize brings enterprise breadth with the configuration effort that accompanies it. Unit21 and Hummingbird are genuinely well built modern case tools with an investigator experience that is far ahead of the older generation. In each case, the constraint is the same: they impose a case model and a set of assumptions about your data, and connecting your own sources, the core, the card platform, the lending system, the support desk, the wire application, remains your work and your cost. That connection is where most of the two hours goes.

What a custom build does: reference rather than copy. The case holds pointers to alerts, transactions, customers and related parties in your own systems, renders them into the working view, and snapshots the rendered evidence at the moment of filing so the filed package is frozen while the live links remain. You get both: a reproducible package and a case that can be refreshed when the investigation is still open.

Problem two: narrative quality is a standard nobody encodes

Every experienced BSA officer has a view on what a good narrative contains: who, what, when, where, why and how, the specific transactions with dates and amounts, why the activity is suspicious in the context of that customer's expected behaviour, and what the institution did. Most institutions hold that view as a training document and a review habit.

What a custom build does: encode the standard as a structured narrative with required sections tied to case type, so the investigator is prompted for the elements that must be present and the reviewer sees what is missing before approval rather than after. Pull the objective facts in automatically: the transaction table with dates, amounts, counterparties and channels formatted the way your policy wants it, the customer's expected activity as captured at onboarding, the prior filing history.

Large language models help here in exactly one supervised way: drafting the factual sections from the structured evidence so the investigator edits rather than types, and checking a completed narrative for missing required elements before it goes to a reviewer. What they should not do is form the suspicion or decide to file. That judgement belongs to a named person, it is what your policy says, and a filing that cannot be attributed to a human decision maker is a problem you do not want to explain.

Problem three: continuing activity falls through the gaps

After a filing, the customer keeps transacting. Policy typically requires review of continuing activity on a rolling cycle and a further filing where it continues. This is where backlogs form, because the trigger for that review is usually a date in someone's calendar and the person who set it has moved teams.

What a custom build does: continuing activity is a scheduled object created automatically at filing, owned, dated and monitored, with the transactions since the last filing pre assembled when the review opens. It also carries forward the prior narrative so the reviewer is writing a delta rather than starting again. Institutions that get this right stop discovering missed continuing filings during examinations.

Problem four: confidentiality is a control the software must enforce

SAR confidentiality is not a convention. Disclosure of the existence of a filing to the subject is prohibited, and the practical consequence is that your case system has to enforce access boundaries that most internal tools do not. A relationship manager should not be able to see that their client is under investigation. A branch employee resolving a service issue should not encounter a flag whose meaning is obvious.

What a custom build does: role based access at the case level with a full access log, deliberate design of what any indicator visible outside the financial crime team can and cannot imply, and audit reporting on who viewed which case. This is one of the strongest reasons to keep case management out of a general purpose ticketing tool where visibility defaults are permissive and change with an upgrade.

Problem five: quality assurance happens after filing or not at all

Examiners sample filings. If the first serious quality review of your filings is the one an examiner performs, you learn about your standard from a finding.

What a custom build does: sampling as a native function. A configurable proportion of closed cases, including cases closed without filing, which are the ones institutions review least and examiners look at most, routes to a QA reviewer with a scored checklist. The scores aggregate by investigator and by case type, feeding training rather than blame. Cases closed with no filing deserve particular attention, because a pattern of no filing decisions on a specific typology is precisely what a look back review is designed to surface.

What it costs and how long it takes

A first release, meaning case creation from your alert sources, automated evidence assembly from core and transaction systems, structured narrative with approval workflow, and filing record keeping with frozen packages, runs $80,000 to $180,000 and ships in 12 to 16 weeks. A full platform adding continuing activity scheduling, QA sampling, subpoena and information sharing request handling, link analysis across related subjects and full reproducibility tooling runs $220,000 to $500,000 across 7 to 14 months.

What pushes cost up in this category: the number of internal source systems, since every one is a separate integration and a separate data quality conversation. Multi entity or multi jurisdiction filing, because a group filing in more than one regime needs different packages from the same evidence. Batch filing integration with the electronic filing system, which is straightforward but exacting. Link analysis across subjects, which is valuable and is a genuine piece of engineering rather than a screen. And historical case migration, which we generally advise against beyond the retention window you are obliged to keep accessible.

Build versus buy for financial crime case management

Buy if you are a community bank or credit union filing a modest number of SARs with a conventional product set. Verafin and Abrigo cover this well and integrated filing is worth a lot. Your effort belongs in narrative standards and evidence templates inside the tool you already pay for.

Build when two or more of these are true. Your investigators lose more than an hour per case to retrieval across systems no vendor will integrate with on your timeline. Your case types include things vendor models handle poorly, such as sub merchant activity, digital asset flows or partner banking programmes where the customer of your customer matters. You have had a finding on timeliness or on continuing activity. You file across more than one jurisdiction. Or a look back review has shown you cannot reproduce filings and their supporting evidence reliably.

How to choose a developer for investigation tooling

Ask them how they will reproduce a filing from three years ago exactly as it was filed, including the evidence as it appeared then. If the design does not snapshot and freeze the package at filing while keeping live references for open cases, the system will fail the only test that really counts.

Ask how they will keep a relationship manager from learning that their client is under investigation. A team that answers with case level access control and an access log understands the confidentiality obligation. A team that offers a permissions tab does not.

Ask what they will do with cases closed without filing. If those are not sampled and reviewed, you have built a system that documents your filings and hides your decisions not to file, which is exactly backwards from an examiner's perspective.

Ask who owns the code, the narrative templates, the case data and the cloud accounts, and put it in the contract before kickoff. Your case history is a regulatory record you are obliged to retain and produce. At Digital Heroes it belongs to the client from the first commit, and any arrangement where your filing history sits in a vendor tenancy you cannot fully export from should be refused.