A framing discussed at a recent industry AML technology panel, "Left of Bang" (LOB) and "Right of Bang" (ROB), distinguishes activity before a suspicious pattern is identified (LOB: oriented toward detection and prevention) from activity after (ROB: oriented toward investigation and case-building). The panel argued that detection, analysis and investigation are not the same discipline, and that blending LOB and ROB thinking within a single analytics process causes real problems, since building an evidential case is a different task with different rigour, timelines and standards of evidence from spotting a signal in real time. It was also noted that detection rules often do not evolve in step with what investigations actually learn, partly due to resourcing pressure and concern about false positives.
Why it matters
Treating detection and investigation as one undifferentiated process creates two different failure modes, and they aren't symmetric. Applying investigation-grade rigour too early is a timing and throughput problem: if a real-time screening system flags a pattern consistent with mule activity a new account receiving payments from several sources and rapidly forwarding them on that moment calls for a fast, provisional judgement (hold the transaction, or escalate for review), not full beneficial-ownership verification and a documented evidential chain before any action is taken. Requiring that level of certainty before acting means funds move before the threshold is met, and alert backlogs build as analysts either take too long per alert or quietly under-escalate to keep pace. Applying detection-grade speed too late is a different, evidential problem: rushing a case that actually needed sequential, careful work risks missing what a proper investigation would have found. The first costs speed and throughput; the second costs the quality of the case itself. Firms that don't feed investigation findings back into detection risk repeating the same blind spots case after case, rather than compounding what they learn.
Who this affects
Financial crime teams where the same analysts or workflow handle both initial detection and full investigation without a clear handoff point
Teams under resourcing pressure that default to keeping detection thresholds static rather than evolving them based on investigation findings
Firms assessing whether their escalation process distinguishes "flag for review" from "build an evidential case" as genuinely different work
MLROs and heads of financial crime reviewing whether lessons from closed investigations are structurally fed back into monitoring logic
What firms should do
Map your process end-to-end and mark clearly where detection (left of bang) ends and investigation (right of bang) begins if there's no clear line, that's worth addressing directly
Assess whether detection rules and thresholds have been updated to reflect patterns learned from closed investigations, or have stayed largely static
Where resourcing pressure has led to dialling back detection sensitivity, document that decision and its rationale explicitly, rather than letting it happen informally
Build an explicit feedback loop from investigation findings back into detection logic, so lessons compound rather than reset with each case
FINTRAIL's view
Treating detection and investigation as a single, undifferentiated process is a common and understandable scenario under resourcing pressure, but it tends to produce systems that are reactive by design. Firms getting more value from their analytics are the ones explicitly building the loop back from what investigations find to what detection logic looks for next, rather than treating both as the same job done at the same speed.
Sources
Practitioner commentary shared at an industry, AML technology panel discussion (notes on file not independently published)