Implementing Event + State Intelligence with Loci

Implementation overview

This brief describes how the recommended event stream plus state snapshot strategy is implemented in practice using Loci's composable infrastructure, and outlines an initial baseline control set suitable for regulatory-grade deployment. It translates the strategy into concrete implementation guidance, while remaining readable to senior technical, risk, and compliance leaders.

The objective is not maximum coverage on day one, but strong baseline controls, explainability and auditability, low operational overhead, and a foundation that can evolve.

Loci evaluates every transaction as the primary decision event. At decision time, the engine draws on four sources of intelligence: three data surfaces you maintain, and one the engine computes for you.

If a metric can be derived from transaction history, you do not build a table for it. All four sources are evaluated at transaction time, producing a single, explainable decision.

The data model: two tables plus your lists

Loci's implementation does not prescribe a rigid schema. Instead, it recommends a minimal, composable data model that supports regulatory-grade controls while keeping operational overhead low.

Every decision in Loci is anchored on a transaction event, enriched by the surfaces below. Each table declares its type and optimization posture; streams that opt into precomputed acceleration commit to being append-only.

entity_events · temporal reasoning and sequencing

Keep it high-signal (authentication and profile-change events), not clickstream telemetry.

entity_profile · baseline truth at decision time

One wide row per entity; every column reads as a scalar inside a control, for example comparing the transaction amount directly against entity_profile.daily_transfer_limit.

reference_list · institutional knowledge as data

List edits change detection coverage instantly, with every change on the record.

How FLM uses these surfaces

Every FLM control may read events for recent behavior and sequences, read state for eligibility, limits and lifecycle, and read lists for membership and screening, and use live computation for velocity, baselines, deviation and first-time patterns.

All at transaction time, compiled into a single deterministic evaluation. Every score decomposes into named signals; every alert carries the exact logic and values that produced it.

Baseline composable set: the initial 12 controls

The following controls provide broad regulatory coverage while remaining operationally lightweight.

The full baseline requires exactly two custom tables plus your reference lists. Every velocity, deviation, structuring, and pass-through number is computed live by the engine from the history it will defend in an audit.

Control categories

Operational implications

• For compliance teams: clear logic, clear intent, and regulator-friendly explanations, with every alert decomposing into named signals and the values that fired them.
• For engineering teams: two tables and a set of lists to maintain, every rolling metric computed by the engine. Stable data models, predictable access patterns, and low change cost.
• For the business: faster time to coverage, lower operational burden, and confidence at scale.

Most importantly: new controls can be added without refactoring data models, existing controls remain stable as the system evolves, and nothing precomputed means nothing stale, so decisions and their evidence cannot drift apart.

Phased rollout guidance

Phase 1: foundational coverage (day 0-30)

Establish immediate regulatory-grade protection with low operational risk, high explainability, and minimal tuning. These controls are deterministic, easy to explain to regulators, low false-positive risk, and aligned with baseline AML and fraud expectations.

Phase 1 data footprint: the entity_profile state table, the entity_events stream, and your reference lists; every rolling aggregate is computed live. Outcome: strong baseline fraud and AML coverage, immediate regulator confidence, minimal tuning required.

Phase 2: behavioral and network intelligence (day 30-90)

Detect sophisticated, adaptive abuse patterns that emerge after baseline controls are in place. These controls use behavioral baselines the engine builds from accumulated history, and capture patterns missed by simple thresholds.

Phase 2 outcome: coverage of advanced fraud and AML typologies, reduced blind spots, improved detection of organized or evolving abuse.

Why phased deployment matters

This rollout strategy avoids early false-positive fatigue, allows behavioral history to accumulate naturally (statistical controls activate per entity only once sufficient history exists), gives teams time to build confidence, and aligns with how regulators expect controls to mature.

It also reinforces Loci's core principle: intelligence should grow with the organization.

Closing

This approach does not attempt to predict every fraud pattern. Instead, it provides a clean intelligence foundation, a regulator-aligned reasoning model, and a scalable path forward.

With Loci, fraud and AML controls become structured intelligence, not accumulated complexity.