Open source transaction monitoring for BSA SAR filing

Open source transaction monitoring for BSA SAR obligations: the short answer

A US bank or fintech that wants self-hosted control over suspicious activity monitoring can run Jube as the detection and case engine, but the suspicious activity decision, the filing and the retention duties stay with the institution. Jube can score transactions, apply rules and models, route alerts into investigation queues and hold the working file for each case. It does not decide whether activity is suspicious, it does not file a SAR for you, and it does not make your program compliant. Those responsibilities sit with your BSA officer, your investigators and your counsel, and the design of the system should reflect that split from the start. The Bank Secrecy Act program your examiner will review expects a documented risk assessment, monitoring that fits your products and customers, investigation of alerts with recorded reasoning, and a clear path from an alert to a filing decision. In practice, examiners ask how each rule or model maps to a typology you have identified, who approved it, how it was tested and how alerts were dispositioned. Confirm the exact expectations for your charter, size and products with counsel and your examiner, because they depend on your institution rather than on any software choice. DeployOpen prepares the system, configuration records and evidence for that review, but it does not issue examination results, certifications or attestations.

The two timing and records duties in this topic need explicit confirmation before design work begins. The topic requirements we track are a 30-day clock for filing after the institution identifies a suspicious activity, and five-year retention of SARs and supporting documents. Ask counsel how the clock starts for your case types, whether it can be extended in any circumstance, and which supporting documents must be kept with the filing, then ask your examiner whether those expectations match their reading. Those answers determine case aging alerts, escalation roles, document stores and backup scope in Jube's surrounding infrastructure. Ask an implementation partner to show how a case file, its alerts, rule versions and analyst notes can be exported and retained for the full period, and how access to them is logged.

Which SAR program requirements the monitoring function must meet

This table maps each SAR program requirement area to what the monitoring function must do and how to configure Jube, yente and the case data store. Read it as a checklist for scoping: each row names the evidence an examiner or independent reviewer will expect to see, and where implementations usually fall short. The main takeaway is that detection quality, triage speed and governance evidence are separate deliverables and each needs its own configuration and records.

Requirement area	What the function must do	Configuration in Jube, yente and case data
Detection and typology coverage	Map each documented money laundering typology to at least one rule or model and show which typologies are not covered	Maintain a scenario library per typology in Jube with a named owner, test data and a coverage matrix kept under version control
Threshold and model change control	Record why each threshold or model version changed, who approved it and what alert volume it produced	Store rule and threshold changes as reviewed commits, require a second approver, and retain pre and post change backtest results
Separation of duties for rules	Keep rule authors separate from the staff who approve production changes and from the staff who close alerts	Use distinct Jube roles for authoring, approval and case disposition, and log every role assignment change
Alert triage and case files	Group related alerts into cases, capture analyst reasoning and link supporting transaction and customer records	Configure case records with mandatory disposition fields, timestamps and links to the originating alert and rule version
Sanctions and PEP hits in the same workflow	Show how yente matches were cleared, escalated or blocked, and which list version was used	Log yente query inputs, match scores, list dataset version and reviewer decision in the case file, not only the final outcome
SAR timing and filing clock	Track the date a suspicion was identified and the deadline for filing, and escalate cases approaching it	Add case aging fields and alerts for open escalations in the case store, and confirm the filing deadline rule with your BSA officer and counsel
Five-year retention of SARs and support	Keep SARs, supporting documents and alert history for the required retention period and make them retrievable	Set retention policies in the case store and archive storage, and test restores of closed case files on a schedule
Access control and activity logging	Restrict access to SAR information, log user activity and enforce multi-factor authentication for all users of the system	Enable MFA for every account, forward Jube and case store audit logs to central storage, and review privileged access on a set cycle (FTC Safeguards Rule, 16 CFR 314.4, applies only where the institution is under FTC jurisdiction)

Which self-hosted platforms fit a SAR monitoring stack

A SAR workflow depends on several systems working together: a monitoring engine that scores activity, a screening layer that matches parties to watchlists, and the ledgers and payment systems that produce the transactions being monitored. The cards below cover each component and what to confirm before selecting it.

Jube for monitoring and alerts

Jube is the monitoring engine that scores transactions against rules and models, either in real time within the payment flow or in batch over historical data, and raises alerts for triage. For SAR purposes, the key questions are whether it supports the scenarios your typologies require, how rule and model changes are versioned and approved, and whether every alert keeps the inputs and score that produced it. Confirm its current version, license terms and support model directly with the vendor before selection, since this page does not state them.

yente for list screening

yente matches customers, beneficial owners and counterparties against sanctions and PEP lists using OpenSanctions data. Its match results feed alert triage, so check how match thresholds are set, how false positives are recorded, and how each list version is retained so an examiner can see what was checked on a given date. Confirm the yente release, the OpenSanctions data license for internal commercial use, and the list refresh schedule with the vendor before you rely on them.

Apache Fineract for loan and deposit records

Where the institution runs lending or deposit products, Apache Fineract is the core banking system of record, licensed under Apache-2.0. The monitoring engine needs its transaction events, account identifiers and customer links, so the integration should be designed before go-live. Check whether events arrive in near real time or in periodic extracts, how reversals and corrections appear, and which fields carry the identifiers that the SAR narrative will rely on. Fineract repository

Hyperswitch for payment flows

Hyperswitch is an Apache-2.0 composable payments platform that routes payments across processors, payouts, fraud and vault providers, with SaaS and self-hosted options. It matters for SAR monitoring because it sees payment attempts, declines and retries that a ledger may not show. Confirm which processors feed the monitoring engine, whether declined and retried attempts are exported with their reason codes, and how card data stays within the cardholder data environment. Hyperswitch repository

Case management and record store

Alerts become SAR decisions in a case system, which needs its own access controls, audit log and retention settings. The monitoring platform should pass alert IDs, scores and analyst actions into that case system without manual re-keying. Confirm which system is the system of record for the SAR decision, who can edit closed cases, and how supporting documents are stored, indexed and retrieved on request.

How the stack changes for a bank, a fintech or a payments firm

A bank with an established case manager usually treats Jube as a detection layer that feeds alerts into systems its investigators already use. The main design question is how Jube's output fits the workflow investigators already follow, including who acknowledges an alert, who opens a case and where the SAR decision is recorded.

Alert routing: confirm whether Jube alerts can reach the existing case manager through an API or message queue, and who owns the mapping between alert fields and case fields.
Decision trail: keep the disposition of every alert, including alerts closed without a case, in the system of record so examiners can trace why a SAR was or was not filed.
Change control: route rule and model changes through the bank's existing model risk and change management process, with documented testing before promotion.
Access and logging: the cluster runs inside the bank's network, so identity, privileged access and log retention should follow the bank's current security controls.
Duplicate records: avoid holding the same facts in two case stores, and decide which system is authoritative for SAR narrative drafts.

Confirm with your BSA officer and case manager vendor which system holds the authoritative case file and how the 30-day filing clock is tracked across both.

How typologies become rules and models Jube can document

Every rule and model should trace back to a named typology, a documented reason for existing, and a named approver. Start by writing down the typologies your program is designed to catch, such as structuring below reporting thresholds, rapid movement of funds through newly opened accounts, or transfers to high-risk jurisdictions. For each one, record the data fields Jube needs to see, the business owner, the customer segments in scope, and the expected evidence an analyst would look for in a case file. In Jube, that typology becomes a set of rules (deterministic conditions on fields such as amount, counterparty, channel and velocity) and, where history supports it, one or more models that score transactions against learned patterns. Keep the typology register as a controlled document, versioned alongside the rule and model configuration it drives.

Before any change goes live, run it against historical transactions and review what it would have alerted on. Back-testing shows alert volume, the share of alerts that analysts would have worked, and which known suspicious cases the change would or would not have surfaced. Set thresholds from that evidence, then record the rationale, the data window used, the reviewer, and the approver in your change log. Confirm with your partner how Jube versions rule definitions and model artifacts, and whether that history can be exported in a form your model risk and BSA teams can read without engineering help. Ask your partner to demonstrate a full change cycle, from proposal through back-test to a reproducible production deployment, before you rely on it.

An examiner will ask how each rule was chosen, who approved it, and how alert volumes were reviewed after go-live. Have answers ready for each rule, including the back-test results, the trend of alerts and closures over time, and any decision to lower sensitivity. Tuning is ongoing work owned by your institution, with your partner providing engineering and documentation support. Agree in writing who performs periodic reviews, how often they occur, who signs off on threshold changes, and how emerging typologies are added. Budget for that recurring effort as part of the operating model rather than treating the initial deployment as the finish line.

What the 30-day clock and five-year retention mean for the system

What timestamps should each alert and SAR case record?

Each alert and case should carry immutable timestamps for creation, first review, every disposition decision, every escalation, and the filing or no-filing decision. Store these as system-generated values in UTC with the source event time kept separately, so the record shows when the system knew about activity and when staff acted on it. Time stamps are the evidence that a clock was managed, so the design should prevent edits to them and log any correction as a new entry with the user, reason and time. Confirm with your compliance counsel exactly which event starts the filing clock, because the timestamp you must capture depends on that answer.

How should case status history be kept for examiners?

Keep an append-only status history for every case, recording each transition between states such as new, under review, escalated, pending information, filed and closed, along with the actor, the time and the reason. Examiners usually ask how a case moved and who approved each step, so a current status field alone is not enough. Link each transition to the supporting evidence, such as the rule or model score, the analyst notes and any requested customer documents. The history should be exportable for a single case and for a population of cases over a period, and the export should be tested before go-live.

How do escalation paths map to alert and case ownership?

Define escalation paths in writing before configuring queues: who triages alerts, who investigates, who may recommend filing and who makes the final filing decision. Each step should map to a role in your identity system, with segregation so that the person who closes an alert cannot also approve the SAR. Set up time-based escalation that fires when a case sits in one state too long, and record each automatic escalation as its own event. Test the paths with sample cases, including weekends, staff absence and a case that reaches the filing decision late in the clock. Document the paths as part of the procedures your examiners will review.

How long should SAR files and supporting documents be kept?

The retention period for SARs and their supporting documents is set in the BSA framework, and this page works from the five-year period named in its scope. Build the retention policy around the record classes, not a single folder: the SAR itself, the alert and case history, analyst notes, the customer documents that supported the decision, and the rule or model version that generated the alert. Each class needs its own retention date, a legal hold capability that suspends deletion, and a deletion log. Confirm with counsel whether any class must be kept longer, and whether the retention clock starts at filing, at case closure or at another date.

Who confirms the 30-day filing trigger and how it is counted?

Your compliance counsel and your BSA officer should confirm the filing trigger, the start date and the method for counting days, including how weekends, holidays and extensions are treated. The system cannot decide that legal question for you, so it should accept those rules as configuration that is versioned and approved. Once the rules are confirmed, compute due dates from the recorded trigger timestamp, display the countdown in the case queue, and raise an alert before the deadline. Keep the computation logic, its version and the approval record, so an examiner can see how a due date was produced for any case.

Does broker-dealer record retention under Rule 17a-4 apply here?

It applies only if your entity is a broker-dealer subject to SEC recordkeeping rules, and it is a separate obligation from BSA retention. Rule 17a-4(b) requires broker-dealers to preserve certain records, including bills receivable or payable, bank statements and originals of business communications, for not less than three years, with the first two in an easily accessible place. Do not assume the BSA retention period covers this rule or the reverse. Map each record class to every applicable rule, and let the longer period govern where both apply. Read the 17 CFR 240.17a-4 text and confirm its scope with counsel.

Can DeployOpen configure these retention and audit controls for us?

DeployOpen plans, implements, customizes, hardens, backs up and documents self-hosted open-source platforms in your own infrastructure, so it can configure timestamps, status history, escalation queues, retention classes and legal holds as part of a written scope. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or attestations, and examiners or independent auditors make those judgments. Your compliance team still owns the filing decision, the trigger rules and the retention periods. Ask any partner to show a test export of case history and a restore of a deleted-then-held record before accepting the design.

What does retention design add to the cost of the system?

Retention adds cost in three places: storage that grows with every alert, case and attached document; configuration and testing of retention, legal hold and export logic; and ongoing operation, including backups, restore tests and periodic reviews of retention rules. Storage cost recurs and rises with alert volume and document size, so set the attachment policy early. Configuration and testing are one-time work, though rule changes will recur. When you request a quote, ask the partner to separate these items, state the assumed alert volume and retention classes, and list which tests are included. The fixed scope should name every record class it covers.

What monitoring software alone does not satisfy

Jube can score alerts, route them to cases and keep a record of what the system did, but the filing decision, the people who make it and the documents that prove the program works sit with the institution. The cards below name each gap and the owner that must be assigned before examiners arrive, so the self-hosted stack is backed by accountable decisions rather than configuration alone.

The SAR filing decision

Software can flag and prioritize activity, but a named BSA officer or delegate must decide whether a suspicious activity report is filed, and record the reasoning for decisions to file and decisions not to file. The owner is the BSA officer. Check that case closure in Jube requires a documented disposition, that the decision timestamp is captured, and that the 30-day filing clock is tracked by someone who receives escalations when it is at risk. *Illustrative:* an alert closed as a false positive without a written rationale creates an undocumented decision that examiners will question.

Analyst staffing and training

Alert volume, queue depth and investigation quality depend on people, and the institution must staff investigators with enough time and skill to review what the models and rules produce. The owner is the BSA or compliance manager with HR support for hiring and training records. Confirm that training covers each typology in scope, that training completion is recorded, and that staffing plans are tied to alert volumes measured from the live system rather than estimates made before launch.

Independent model and rule validation

Rules and models that drive alerts need validation by someone who did not build or tune them. The owner is a model risk or internal audit function independent of the development team. Validation should test whether alerts match the typologies they target, measure false positive and false negative behavior on known cases, and check that thresholds were changed only through approved change control. Ask the implementation partner how validation evidence is packaged, but note that DeployOpen prepares evidence and does not issue validation opinions.

Written policies and procedures

Examiners expect a written AML program that describes how monitoring, alert handling, escalation, SAR decisions and recordkeeping work in practice, not only how the software is configured. The owner is the BSA officer, approved by senior management. Check that procedures name each role, define the handoff from Jube case queues to the filing team, and are reviewed on a set cycle and after material system changes. A procedure that describes a workflow the system no longer follows is a finding in its own right.

Board and senior management reporting

The board or a committee needs regular, understandable reporting on monitoring coverage, alert volumes, backlog age, filing timeliness, open model issues and significant rule changes. The owner is the BSA officer, who reports to the board. Confirm which metrics Jube can produce directly, which need a reporting layer, and who signs off on the figures. Minutes that record discussion and decisions are part of the evidence an examiner will ask to see.

Sanctions decisions beyond screening

A screening match is not a decision. Potential true matches require review, and confirmed matches may require blocking, rejection and reporting to the Office of Foreign Assets Control. These decisions are separate from SAR filing and need their own owner, usually the sanctions compliance officer. Confirm that the case workflow distinguishes sanctions hits from suspicious activity alerts, that blocking and rejection records are kept, and that escalation paths are tested before go-live.

Vendor and data source governance

Open-source software and watchlist data each carry licensing, update and continuity obligations that the institution must govern. The owner is the vendor risk or third-party management lead, working with legal for data licenses. Record which list sources feed yente, confirm the license terms allow your intended internal commercial use, and keep an exit plan for the platform and its data. Where an implementation partner supports the stack, the contract should state the locations where data is processed and the support terms.

What do buyers ask before hiring a partner for SAR monitoring?

What should a fixed-scope quote for SAR monitoring include?

A fixed-scope quote should list every deliverable, assumption and exclusion in writing before work starts. Most engagements are fixed-scope, so the agreed scope, deliverables and timeline form the basis of the price. Expect the quote to cover planning, deployment of self-hosted Jube in your environment, data feeds, rule and model tuning against agreed typologies, case workflow setup, testing, documentation and handover. The main cost components are the implementation work paid to the partner, your internal staff time, the infrastructure you run in your own cloud accounts or data centers, and any data or licenses you buy. Ask which costs are one-time and which recur, such as support retainers or upgrades. DeployOpen does not publish a price list, so the quote follows from the written scope. Ask the partner to state the volume, number of typologies and number of data sources it assumed.

How long does a self-hosted SAR monitoring build usually take?

The duration depends on the number of typologies, data sources and how much historical data must be replayed during tuning. No duration figure is supplied for this engagement, so ask partners for a phased plan with clear exit criteria rather than a single go-live date. A typical plan covers requirements, data mapping, build and integration, tuning on historical data, a parallel run beside your current monitoring, validation and go-live. The parallel run is often the longest phase because it depends on how much alert activity your institution produces and how many review cycles you want to observe. Ask the partner which phases depend on your staff or data owners, and what happens to the schedule if a data feed arrives late.

What must our staff provide before a partner starts the work?

Your staff must supply the business knowledge, data access and review time that no outside team can supply on its own. Before the build starts, confirm that you can provide:

Typology owners who can describe the behaviors to detect, the reasons they matter and the thresholds your analysts already use
Data mapping support from source system owners who can explain fields, transaction codes, customer identifiers and known data quality gaps
Analyst time to review alerts during tuning, testing and the parallel run
A named compliance approver for rules, thresholds and model changes
Access to environments, change approval windows and a point of contact for security reviews

Ask the partner to convert these into a responsibility matrix with named roles and expected hours per phase, so that a slow data owner or unavailable analyst is visible early.

Can our own team run Jube for SAR monitoring without a partner?

Your team can run self-hosted Jube without a partner if it has the skills and capacity to cover the full cycle. Those skills include platform operations, data engineering, rule and model tuning, change control, case handling and documentation that an examiner can follow. Many institutions with small compliance and engineering teams use a partner for the initial build and then keep ongoing support, upgrades and testing under a retainer. Ask the partner what the handover includes, such as runbooks, configuration documentation, training for analysts and administrators, and a named support path. Also ask which tasks remain with your staff after go-live, including alert review, rule approval and periodic model review. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, and the handover scope should be written into the statement of work.

How is model validation and examiner documentation scoped?

Scope validation by naming the artifacts it must produce and who signs off on each one. Typical artifacts include the rule inventory, the typology rationale for each rule and model, data lineage, tuning and test results, a change log, approval records and a plan for ongoing performance monitoring. Ask whether validation is performed by people independent of the build team, and how independence is documented. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors, examiners and your own model risk function make those determinations. Ask the partner how rule versions are kept, how each change links to an approval and how the documentation package will be organized for an examination.

Who decides whether a suspicious activity report is filed?

Your institution decides, through its BSA officer and legal counsel, whether to file a suspicious activity report. The partner builds the detection, case handling and evidence tooling that supports that decision, but it does not make filing determinations or act as your reporting authority. Ask the partner to show a responsibility matrix that separates system build, rule decisions, alert disposition, filing decisions and filing submission. Also confirm which records the case file must hold so that analysts and the BSA officer can reconstruct how a case was handled. The clearer this split is in the statement of work, the easier it is to show an examiner who was accountable for each step.

How do data location and security requirements change the engagement?

Self-hosting moves hosting, access control, logging and encryption decisions into your environment, and those decisions add to the scope. Confirm where transaction and customer data will be stored, who can administer the platform and how administrator activity is logged. If your institution is a non-bank financial institution under FTC jurisdiction, the FTC Safeguards Rule at 16 CFR 314.4 requires encryption of customer information in transit over external networks and at rest, multi-factor authentication for anyone accessing an information system unless a written equivalent control is approved, change management procedures and logging of authorized user activity. Ask the partner how each requirement will be met, which items you must provide, and which items need a separate quote, such as an independent penetration test.

How a self-hosted Jube rollout typically proceeds

The sequence moves from agreed requirements and typologies to a deployed, tested and documented monitoring system that your own compliance and records teams can run after handover. Each phase ends with a written output that examiners and internal audit can review.

Define requirements and typologies
DeployOpen works with your BSA officer, compliance leads and transaction monitoring analysts to write down the products, channels, customer segments and typologies in scope, the data sources feeding monitoring, and the alert and SAR decision points the system must support. The scope, deliverables and timeline are agreed in writing before this work begins. The step closes with a signed requirements and typology register that becomes the baseline for every later test. Ask whether the register maps each typology to a rule, a model or a documented gap.
Map transaction and customer data
The team traces where transaction, account, customer and counterparty data originate in your core systems and payment platforms, then defines field-level mappings, data quality checks and refresh frequency for each feed into the self-hosted Jube environment. Your data owners confirm lineage and any personal data handling rules before extraction begins. The step ends with an approved data mapping specification and a list of known gaps with owners. Confirm early whether any feed requires masking or residency controls under your own policies.
Deploy inside your environment
DeployOpen installs Jube and its supporting services in your cloud accounts, data center or air-gapped network, configures identity and access controls, encryption in transit and at rest, logging and backups, and separates development, test and production environments. Your infrastructure and security teams review the architecture and hardening baseline before any production data is loaded. The step closes with a deployment record, access matrix and a tested restore of the backup set. Confirm who holds administrative keys and where logs are retained.
Build rules and models
Analysts and engineers translate each agreed typology into detection rules, thresholds and, where appropriate, statistical models, with the rationale for each parameter written alongside it. Changes are tracked through a documented change process so that every rule version can be traced to an approver and a date. The step produces a rule and model inventory with the typology each one addresses and its owner. Ask how the team separates rule tuning decisions from model development and who has authority to approve each.
Back-test and validate
The rules and models are run against historical transactions with known outcomes, such as previously filed SARs, closed alerts and confirmed false positives, to measure alert volumes, hit quality and coverage gaps. DeployOpen supports your independent validation team by preparing test plans, reproducible test datasets and result summaries, while your model risk function makes the acceptance decisions. The step ends with a validation report that records findings, tuning changes and open issues. Ask your validator which evidence format they expect before testing begins.
Integrate case and records workflows
Alerts are connected to case management so that analysts can review, escalate and document decisions, and so that SAR preparation draws on a complete case file with its supporting transactions and rationale. The team configures the retention and access controls needed for SAR records and supporting documents, and connects the 30-day filing clock tracking to your existing workflow. The step closes with an end-to-end test in which a sample alert moves from detection through case closure or SAR preparation with a complete audit trail. Confirm which filing and retention obligations your counsel wants reflected in the configuration.
Hand over with runbooks
DeployOpen delivers operating runbooks, administrator and analyst guides, rule change procedures, model documentation for examiners, backup and restore instructions, and an incident response procedure, then trains the staff who will run the system. Your team operates the system under observation for an agreed period before the handover is accepted. The step closes with signed acceptance of the deliverables and a documented support model, whether internal, retained or both. Ask what the handover package contains and whether it covers model documentation in the form your examiners expect.

How DeployOpen scopes, delivers and supports SAR monitoring

DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including the Jube-based monitoring that feeds SAR decisions. Engagements start with a written scope that fixes deliverables and timelines before any build work begins.

How we scope

Written scope lists the transaction sources, typologies and rules that Jube will cover in the first phase.
Scope defines the case file contents, retention settings and SAR workflow hand-offs to your filing team.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

Deployment runs in your cloud account, data center or air-gapped network, so transaction data stays under your control.
Rules and models are configured against documented typologies, with each tuning change recorded for review.
Testing covers alert generation, case routing, access controls and audit logging before anything goes live.

How we hand over

Handover includes rule and model documentation written so examiners can trace each detection logic to its rationale.
Runbooks cover alert triage, case escalation, SAR timing checkpoints and backup and restore procedures.
Evidence packs record configuration baselines and test results so your compliance team can present them to auditors.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainers can cover Jube version upgrades, rule and model reviews and periodic security testing of the platform.
Ask any partner to confirm response expectations, change control and who signs off on tuning changes in writing.

Open source transaction monitoring for BSA suspicious activity reporting